Understanding Service Function Chain (SFC) and the OpenStack networking‑sfc Project

SFC (Service Function Chain) allows custom network function units and traffic paths, providing essential support for SDN networks; traditional networks rely on physical devices and complex routing, making horizontal scaling difficult.

Virtualization of compute resources demands network virtualization—virtual NICs, virtual switches, routers, and overlay topologies—rendering legacy methods for adding advanced services inadequate.

SFC, defined in RFC 7665, orders traffic through functions like firewall, NAT, IDS; the classifier identifies traffic for a chain, and packets are encapsulated (typically with RFC 8300 Network Service Header, NSH) carrying chain ID and position information.

The OpenStack project networking‑sfc implements SFC by linking Neutron ports into a port chain (port chain). It provides a Neutron extension API, a service plugin, and drivers (e.g., OVS driver) that communicate via RPC with the OVS agent.

Key concepts include:

Port pair : an ingress and egress port for a service function (may be the same port).

Port pair group : a set of port pairs for load‑balancing traffic across multiple instances of a service function.

Port chain : an ordered sequence of port pair groups plus a classifier that defines the traffic path.

Service graph : a composition of multiple chains forming complex, multi‑path traffic flows.

Three deployment modes are described:

Chain : a single linear path through service functions.

Tap : traffic is duplicated to a function (e.g., IDS) while the original flow continues.

Load‑Balancing (LB) : traffic is balanced between service functions using OpenFlow group tables based on packet fields. An example service graph combines four port chains, with each service function hosted on virtual machines across two physical hosts, using VXLAN tunnels for inter‑host communication; due to an OVS NSH bug, MPLS encapsulation is used instead.