What Is SFC?

Origin of SFC

On a traditional network, VAS devices (such as firewalls, load balancers, and IPS devices) are tightly coupled with the network topology and hardware. These devices are dedicated and complex to deploy. When the network capacity is expanded or changed, the network topology needs to be re-planned, which increases network deployment and maintenance costs.

With the development of Network Functions Virtualization (NFV) technology, network functions are decoupled from the hardware, and forwarding and control planes are separated, making network control more elastic and flexible for data centers. On an NFV network, SFC plays an important role in forwarding traffic to implement network services in a specified sequence. When a service needs to be adjusted, you only need to update the SFC sequence without changing the network configuration. In this way, network services can be provisioned agilely.

SFC Architecture

Network devices play different roles in an SFC architecture based on their functions. SFC roles are as follows:

• Service classifier (SC): An SC is located at the ingress of an SFC domain. After packets enter the SFC domain, the SC classifies the packets, sets service identifiers, and encapsulates the packets with service packet headers.
• Service function (SF): SFs are devices that provide value-added services, such as firewalls and load balancers. Depending on network service header (NSH) encapsulation awareness, SFs are classified into NSH-aware SFs and NSH-unaware SFs. NSH-aware SFs can identify and forward NSH packets, and NSH-unaware SFs cannot identify NSH packets and discard them.
• Service function forwarder (SFF): An SFF connects to an SF, identifies service flow information, and forwards packets based on SF service flow information.
• SFC proxy: An SFC proxy is located between an SFF and an NSH-unaware SF associated with the SFF. It deletes or adds NSH encapsulation information to packets exchanged with the NSH-unaware SF.

SFC Implementation

SFC can be implemented through NSH encapsulation. In this mode, NSHs are added to packets, and packets are forwarded in the SFC sequence based on information in the NSHs. NSH encapsulation enables nodes on a service function path (SFP) to transmit information to each other, helping users dynamically and flexibly process data.

NSH packets can be transmitted on various types of networks, such as VLAN and VXLAN networks.

The following figure shows the NSH packet format.

The following describes how SFC is implemented on a VXLAN network. Packets need to pass through SF1 (firewall) and SF2 (load balancer) in sequence, and SF2 does not identify NSH packets.

1. The SC classifies received user traffic and redirects the traffic to the SFP. The SC searches the NSH forwarding table based on the SPI or SI in the NSH to be added to packets. The next hop is the VTEP IP address of SFF1, and the outbound interface is a VXLAN tunnel. The SC removes the ETH header from a user packet, encapsulates the packet with NSH, ETH, and VXLAN headers. The SC searches the routing table based on the destination IP address in the VXLAN header to obtain the outbound interface.
2. Upon receiving the encapsulated packet, SFF1 removes the VXLAN and ETH headers from the packet, and searches the NSH forwarding table based on the SPI or SI in the NSH. The next hop is the interface IP address of SF1. SFF1 constructs a new ETH header based on the ARP information obtained using this IP address.
3. Upon receiving the packet, SF1 removes outer encapsulation, analyzes the packet, and decreases the SI by 1. SF1 then encapsulates the packet with NSH and ETH headers, and forwards the packet to SFF1.
4. Upon receiving the encapsulated packet, SFF1 removes the ETH header from the packet and searches the NSH forwarding table based on the SPI or SI in the NSH. The next hop is the VTEP IP address of SFF2. SFF1 then encapsulates the packet with NSH, ETH, and VXLAN headers.
5. Upon receiving the encapsulated packet, SFF2 removes the VXLAN and ETH headers from the packet, and searches the NSH forwarding table based on the SPI or SI in the NSH. The next hop is the interface IP address of Proxy. SFF2 constructs a new ETH header based on the ARP information obtained using this IP address.
6. Upon receiving the packet, Proxy removes outer encapsulation, analyzes the packet, and decreases the SI by 1. Proxy then removes the NSH from the packet and forwards the packet to SF2. A packet returned from SF2 is redirected to Proxy. Proxy encapsulates the packet with NSH and ETH headers, and forwards the packet to SFF2.
7. Upon receiving the encapsulated packet, SFF2 determines whether the SI is the same as the SI of the last hop. If so, SFF2 removes the NSH, encapsulates the packet with an ETH header, and forwards the packet out of the SFC domain. If not, SFF2 searches the NSH forwarding table to continue forwarding the packet in the SFC domain.

SFC Application

On a data center network, server leaf nodes usually function as SCs, VAS nodes function as SFs, and border leaf nodes and service leaf nodes function as SFFs.

• East-west traffic: When servers of different security levels access each other, east-west traffic can be flexibly defined to pass through SFs (SF1 and SF2) on the network in sequence based on user requirements for security protection. In this way, topology-independent, flexible, efficient, and secure service processing is implemented.
• North-south traffic: Security protection between the data center network and external networks is the core of network security. The external north-south access traffic can be flexibly orchestrated to an SF (SF4) based on the defined SFC to implement functions such as address translation and security filtering for internal and external networks.