这个用例专门讨论在 OpenStack 中部署 Metaswitch Networks 的 Perimeta 会话边界控制器 (SBC) 虚拟网络功能 (VNF)。
Perimeta 与其他 SBC 一样，位于服务提供商网络的边缘，并监控通过以下网络传输的 SIP 和 RTP（即 VoIP）控制和媒体流量：* 终端用户与核心网络之间的接入网络 * 核心网络与另一个服务提供商之间的干线网络。
接入 + SP A 核心 + 干线 + SP B 核心网络 | 网络 | 网络 | 网络
| || |
+——-+ +-+–+ +———+ +-+–+ +-+–+ +———+ |用户 | |SBC | |网络 | |SBC | |SBC | |网络 | |设备 |–| |—|功能 |–| |————| |—|功能 | +——-+ +-+–+ +———+ +-+–+ +-+–+ +———+
| |
请参阅词汇表以获取这些术语的描述。
为了实现其安全和准入控制功能（例如 DDoS 保护），Perimeta 必须对接收到的数据包进行线路速率处理。对于 RTP 流，这相当于每秒每核数百万个 VoIP 数据包（每个数据包的大小约为 64-220 字节，具体取决于编解码器）。Perimeta 必须能够保证这种性能并提供 SLA。
Perimeta 必须完全具有高可用性，没有单点故障，并且在软件和硬件故障（即所有 SIP 会话和 RTP 会话必须在软件或硬件故障时以最小的中断继续）的情况下保证服务连续性。
Perimeta 必须具有弹性可扩展性，使 NFV 编排器能够根据施加的负载添加和删除实例。
为了对来自不同客户的流量应用不同的策略，Perimeta 必须能够通过 VLAN 或类似机制区分和分离来自不同客户的流量。
Perimeta 必须将承载实时客户流量的网络与承载管理或其他内部数据的网络分离。
Perimeta 信号实例必须能够支持大量并发 TCP 连接（数十万个），以满足大量使用 TCP 的客户端的需求。
Perimeta 必须能够与不需要这些要求的 VM 在同一主机上共存，只要它可以提供足够的专用资源。例如，即使 Perimeta 可能不需要安全组功能，也不能在主机范围内禁用它，或者即使 Perimeta 使用 SR-IOV 或 DPDK，也不意味着该主机上的所有 VM 都必须这样做。
Metaswitch Networks 的 Perimeta 会话边界控制器是会话边界控制器的 Telco 级实现，旨在在通用 PC 硬件或虚拟化设备上运行，在 OpenStack 和其他云上运行，提供高可用性、高扩展性和高性能。
虽然这个用户故事专门针对 Perimeta，但它更普遍地代表了在 OpenStack 中部署任何使用快速数据平面或高扩展性 SIP 的 VNF 所涉及的问题。该用例侧重于这些元素，而不是更通用的问题，例如编排和高可用性 (HA)。
上述问题陈述导致以下需求。
实现每秒数据包目标 - 网络影响
标准的 OpenStack/OpenvSwitch 平台允许 VM 使用 Web 应用程序典型的较大数据包大小来驱动 NIC 到完全带宽。使 VoIP 不同的地方在于小数据包大小，这意味着数量级更多的包，并且每个包只允许几百个 CPU 指令 - 远远不足以将数据包从 VM 驱动到 NIC 通过标准的 OpenStack 网络堆栈。相反，这需要诸如 SR-IOV（https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov - 已于 2014.2 完成，但仍存在一些技术债务）或 DPDK 或类似轮询模式 vSwitch 在主机中。请注意，SR-IOV 特别施加了一些限制（例如，阻止实时迁移），因此对于某些 SP 来说可能不是理想的选择。
理想情况下，网络应该支持并尊重流量优先级和带宽限制的 QoS 规则。
安全 - 网络影响
对于完全绕过安全组的网络技术，必须禁用安全组。
网络应该防止来自其他 VM 的 ARP 欺骗攻击。
高扩展性 TCP - 网络影响
对于禁用安全组功能的端口，期望禁用主机连接跟踪功能，以避免大量 TCP 连接的性能和占用影响，以及避免不必要地调整主机参数。
实现每秒数据包目标 - 计算影响
HA
Perimeta 必须能够部署以提供 5 9’s 级别的可用性。如果部署在单个云实例中，则该实例本身必须比 5 9’s 更可用。由于当今的技术水平很难实现这一点，Perimeta 被设计为能够跨多个独立的云实例，以便任何一个云的故障都会产生轻微的影响。由此产生的要求仍在讨论中，将在未来的用例中解决。
在单个云实例中部署 Perimeta 时，Perimeta 使用主动/待机架构，并具有内部心跳机制，允许待机设备在主动设备发生故障后的几秒钟内接管，包括接管其 IP 地址。为了支持这些应用程序级别的 HA 机制，需要
前者通过标准反亲和性 nova 调度器规则支持，后者通过 neutron allowed-address-pairs 扩展支持。
如果使用 SR-IOV，Perimeta 不需要多个 SR-IOV 端口，因为应用程序级别的冗余可以应对单个 NIC 的故障。但是，它可以利用本地链路冗余使用多个 SR-IOV vNIC。要使这有任何好处，需要将形成冗余对的 SR-IOV VF 分配到不同的 PF 上。
此外，期望底层云实例尽可能可用，例如网络或存储基础设施中没有单点故障 (SPOF)。
弹性扩展
NFV 编排器必须能够根据施加的负载和服务响应能力快速启动或终止新的 Perimeta 实例。这是基本的 OpenStack nova 功能。
支持可扩展的机制来支持 VM 中的多个网络
必须有一种可扩展的机制向 Perimeta 呈现多个网络，数量级为数百或数千，远远超过可以附加的 vNIC 数量。有多种可能的机制；一种常见的方法，也是 Perimeta 支持的方法，是使用 VLAN 呈现不同的客户网络。这会产生对 VLAN 中继支持的客户要求。
在 OpenStack 中将网络映射到这些 VLAN 有多种可能的方法，例如，直接将外部 VLAN 网络中继到 VM，而无需 OpenStack 知识或配置（已在 Kilo 中支持），或者配置 OpenStack 网络和 VLAN 之间的映射，如 VLAN 感知 VM 中所述：https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
上述要求目前存在这些差距。
SR-IOV
已发布对此的初始支持，但仍存在在 https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough 跟踪的技术债务，这将提高基于 SR-IOV 的解决方案的可用性和稳健性。
使用多个绑定 SR-IOV VF 需要以下 bps
允许使用 SR-IOV 进行链路冗余需要以下 bp
其他有用的次要增强功能
安全保护
CPU 引脚
https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-thread-pinning
VLAN 感知虚拟机
以下尚未解决。
删除冗余桥
https://blueprints.launchpad.net/neutron/+spec/ovs-optimization-redundant-bridge
禁用主机中的连接跟踪
[当前没有蓝图]
HA
如上所述，为了提供 5 9’s 服务，Perimeta 预计将部署在多个云实例上，但如果部署在单个实例中，期望该云尽可能可用。
此用例还隐式地对 OpenStack 之外的元素提出要求，例如 DPDK OVS 机制驱动程序（https://github.com/stackforge/networking-ovs-dpdk）。
这取代了 TelcoWG vSBC 故事。
无。