Efficient Patterns for Service Function Chaining within Network Function Virtualization Infrastructure

The following sections describe design patterns for using SFC that we consider to be appropriate under the above NFV assumptions.

A common infrastructure model (e.g., OpenStack/Neutron) allows provisioning of virtual machines with interfaces on specified Ethernet segments. Although the physical implementation of an Ethernet segment is opaque to the tenants, all machines on a segment can send packets to one another by addressing the destination MAC address. Single-Root I/O Virtualization (SR-IOV) is a technology that allows a single physical interface on a compute host to be split into multiple virtual interfaces such that each guest has a hardware interface to the network. When so configured, the physical interface hardware sorts incoming packets into queues for the distinct emulated interfaces according to destination MAC addresses. This technology removes any need for a software module to sort packets received from the physical interfaces into virtual interfaces of the guests. Thus, an extra queuing stage is avoided and no CPU switching resources are required. The NVFI operator may choose to deploy simple switching, with hardware backplane and top-of-rack Ethernet/VLAN switches providing minimum latency. The operator may also deploy Ethernet-over-IP (e.g., VXLAN) when functions are remote. In any case, the virtual host is agnostic to the implementation. Thus, by using SR-IOV and efficient zero-copy drivers, functions naturally address one another by MAC address on the layer-2 segment. In the optimal NFV scenario, software in one function queues packets to an outbound SR-IOV queue, hardware sends the packet on the physical interface, backplane or top-of-rack switches deliver the packet to the physical destination and SR-IOV destination queue. There need not be any software between functions, only Ethernet switches. Note that to capture the benefit of using SR-IOV to avoid software switching, any L2-over-L3 (e.g., VXLAN) should be arranged for in hardware. The functions themselves can then behave the same whether virtual or physical network segments are used. We conclude that carrying NSH packets directly within Ethernet frames is an efficient and natural way to implement Service Function Chaining. The Ethernet encapsulation of NSH is documented in .

Service function chains are often drawn like this two-SF example in which a packet goes from ingress to Classifier, to SFF1, to SF1, back to SFF1, to SFF2, to SF2, back to SF2 and finally to egress:

Classifier --> SFF1 --> SFF2 --> Egress ^ ^ | | | | V V SF1 SF2 ]]> But in NFV infrastructure, if SFFs are considered distinct processing elements, the common reality is that each of the components are separated by Ethernet switching:

Classifier-->switch-->SFF1-->switch-->SFF2-->switch-->Egress ^ ^ | | | | V V switch switch ^ ^ | | | | V V SF1 SF2 ]]> In an NFV environment, the "switch" blocks in can be implemented by Ethernet backplane, top-of-rack switching or (for remotely separated virtual machines) VXLAN virtual layer-2 network. There is an optimization that can be made when all of the "switch" modules are the same Ethernet switching domain. In other words, when this is the logical topology of :

Notice that to implement the path of and , a packet must pass through the switch seven times. It must also pass through each SFF twice, limiting the capacity of an SFF. We can reduce the number of transits through the switch by placing SFF forwarding tables in the SF software module itself, like this:

In this case, a packet taking the path of only transits the switch three times. For minimal latency, an implementation can avoid queuing between the SF and attached SFF. Although keeping the SFFs distinct from the SFs has an architectural purity, the purity has a big cost in switching throughput and corresponding cost in money and latency. Since each packet enters and exits each SFF twice, there could also be contention on the SFF interfaces. There is additional control-plane burden to achieve this data-plane efficiency gain: SF software must implement SFF lookup functions. We feel this computation of next-hop and packet formatting can be done efficienty in software, but it does require support of the SFF feature in the software. There will be as many SFFs as SFs, each of which much have correct forwarding entries populated by the control plane during the orchestration of bringing an SF on line. There are many ways to physically realize the logical switch entities in and . The best case is a hardware Ethernet switch; considerations about how to optimally deploy functions are discussed elsewhere, e.g., in Network Function Virtualization Research Group (NFVRG). In any of these cases, reducing the number of passages though the switch will reduce latency and reduce operational cost.

The NSH draft defines two options for metadata, types 1 and 2. Type 2 is more efficient when there is no metadata, and is the only choice supporting more than 128 bits of metadata. Using the approaches described in and , NSH packets are transported from one MAC endpoint to another via standard Ethernet switches, so there are no requirements on the NFV Infrastructure to support NSH. Given that parsing the variable-length header poses no concerns for software, we feel these considerations make MD Type 2 the preferred choice for service chaining with NFV.