Service function chain (SFC) is used to provide ordered services for the application layer. With these ordered services, SFC logically connects services on network devices. These services can be L4-7 like firewalls, network address translation [NAT], intrusion protection, antivirus etc. SFC allows network administrators want to define the path for service processing. This Service Function Path (SFP) information is added into the packet.
Note that SFC can also be implemented using policy-based routing (PBR) but it will add another level of complexity to the network. Better option may be usage of network service header (NSH) modes. Future implementations also may use SRv6 data plane for SFC. Using SFC with overlay solutions like VxLAN allows independent deployment from network topology. Topology changes of the underlying physical network don’t affect Service Function deployment.
Here are some definitions to understand SFC logic;
Service Function: A function may be firewalls (FWs), load balancers (LBs), application accelerators, and network address translation (NAT) devices etc. Service function may be NSH-aware of NSH-unaware. In case of using NSH-unaware service functions a proxy can be used for service chaining.
Service Function Path: This is the path which defines the location of each SF. There may be more than one path definition for different services or tenants.
Service Classifier: It is located at the ingress of an SFC domain and classifies incoming traffic. This classification is usually determined by SFC policy. AS an example, all packets on a port match an SFC rule and are forwarded along one SFP or packets matching with a specific ip destination can forwarded along another SFP.
Service Function Forwarder: An SFF forwards received packets to specific service function which is encoded into NSH (Network Service Header). Service Functions process the packets and return them to the associated SFF.
SFC Proxy: An SFC proxy is located between an SFF and NSH-unaware Service function which is defined in the header and associated with the SFF. Basically SFC proxy, deletes NSH encapsulation information, sends packets to NSH-unaware. When receiving packets from NSH-unaware SFs, it adds NSH encapsulation information back into the packets and sends the packets to the SFF. From the SFF point of view the SFC-Proxy is a NSH-aware Service Function.
In the Network Service Header (NSH) we have Service Path Identifier (SPI) and Service Index (SI).
SPI Uniquely identifies a Service Function Path (SFP). All participating nodes use this identifier for SFP selection. Service classifier is responsible of setting the appropriate SPI according to classification result.
Service Index is responsible of providing location within the SFP. If there are several service functions in the path, each one is defined with different Service Index value. According to RFC it should start from 255 and decrement by a value of 1 by Service Functions. The new decremented Service Index value will be used in the egress packet’s Network Service Header.
The Service Index is used together with the Service Path Identifier for SFP selection. It is also used to determine the next Service Function Forwarder in the path.
NSH-aware nodes and SFC Proxies can take several action with NSH.
Insert or remove NSH: Service classifier is responsible for inserting NSH. At the end of the service function path SFF is responsible of removing the header.
Select Service Path: The Service Path Header is used by SFF. SFFs uses this header to select next Service Function or next SFF in the service path.
Update The NSH: SFFs updates NSH by decrementing the SI but this is also done by SFC Proxy. When an SFC Proxy receives an NSH-encapsulated packet, it remove the NSH and forwards towards to NSH-unaware SF. When the packet returns back SFC Proxy re-encapsulate it with the correct NSH, and it decrements the Service Index by one.
Service Policy Selection: It is done by Service Functions. A Service function can take action such as permit or deny according to meta-data shared in the NSH.
