Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)
Extracted elements (25)
In SR-based SFC, SF vendors only need to support one unified SFC solution (NSH) and remain unaware of SR, making it economically sound. SFFs are simplified by nullifying the need for reclassification and SR proxies.
NSH was chosen as the SFC encapsulation scheme because it is transport-independent, avoiding the need to replicate specification effort per underlying transport. This design encourages consistent SFC-based service delivery across network segments that enable distinct transport protocols.
SR eliminates NSH forwarding state in SFFs because the SR segment list encodes the full service path, removing the need for per-SFP state on intermediate SFFs. This applies when strict or loose SFPs are in use and simplifies SFF operation.
The two integration scenarios (NSH-based SFC with SR transport, and SR-based SFC with NSH service plane) can be combined to support specific deployment requirements. This provides operators flexibility to use whichever transport technology makes sense in different parts of their network while maintaining an end-to-end NSH service plane.
Two complementary integration scenarios are defined: (1) NSH-based SFC with SR as the transport plane between SFFs, and (2) SR-based SFC where each service hop is a segment and NSH maintains the service plane and SFC instance context. Either SR-MPLS or SRv6 may be used for both.
For SRv6/IPv6, if a processing node does not recognize the NSH, it should follow the procedures in RFC 8200 Section 4 (IPv6 unknown next header handling). For SR-MPLS, unrecognized NSH should follow RFC 3031 Section 3.18 procedures.
The NSH-based SFC scenario is applicable across multiple domains or where traffic-engineered paths are needed between SFFs. It can also be implemented using end-to-end segment routing between SFFs, in which case intermediate DC-GW nodes forward based on SR instructions without examining the NSH header.
A classifier MUST use one NSH Service Path Identifier (SPI) for each SR policy so that different traffic flows can use the same NSH Service Function Path and different SR policies can coexist on the same SFP without conflict during SFF processing.
It is RECOMMENDED for network operators to increase the underlying MTU so that SR/NSH traffic is forwarded within an SR domain without fragmentation, aligned with RFC 8300 Section 5 and RFC 8754 Section 5.3.
The cache mechanism must remove cached entries at an appropriate time determined by the implementation; an implementation MAY allow network operators to configure the cache entry timeout value.
When a packet arriving from an SF does not have a matching cached SR entry, the SFF SHOULD log this event and MUST drop the packet.
When the CONTINUE operation (equivalent to MPLS UHP) is used for NSH over SR-MPLS, it is RECOMMENDED that a specific Prefix-SID be allocated at each node for SFC use, and the No Penultimate Hop Popping (No-PHP) flag MUST be set in the Prefix-SID Sub-TLV to prevent premature label pop.
If reclassification at an SF changes the NSH SPI and/or SI to values not present in the SFF cache, the SFF must generate an error and drop the packet. This handles the case where SF-based reclassification alters the service path context.
In SR-based SFC, the SFC context (NSH SPI) is used by an SFF to determine the SR segment list for forwarding to the next-hop SFF. The SFF performs a lookup on the SID associated with the SF — a Prefix-SID for SR-MPLS or an End.NSH SID for SRv6 — to retrieve next-hop context such as the destination MAC address.
In SR-based SFC with the integrated NSH service plane, each SF is represented as a segment of the SR segment list. The SFF strips SR information, forwards the packet to the SF, then caches the SR segment list indexed by NSH SPI and SI decremented by 1 for use when the SF returns the packet.
In the NSH-based SFC with SR transport scenario, SR-MPLS or SRv6 provides the transport encapsulation between SFFs while the NSH conveys and triggers SFC policies. The SFF performs NSH lookup to determine forwarding, then applies SR encapsulation for inter-domain traversal.
SR-MPLS packet processing at an SFF: when a packet is destined to a local Prefix-SID associated with an SF, the SFF strips the SR label stack, saves it to a cache indexed by NSH SPI and SI-1, and forwards the NSH packet to the SF.
The End.NSH behavior interrupts normal SRH packet processing (RFC 8754 Section 4.3.1.1) and does not continue to S16. When the packet returns from the SF, the SFF reattaches the cached IPv6 and SRH headers using the NSH SPI and SI, then resumes from S16.
The End.NSH SRv6 behavior extends the standard SRv6 processing (RFC 8754 Section 4.3.1.1 through S15) with two additional steps: S15.1 removes and stores IPv6 and SRH headers in a local cache indexed by <NSH: service-path-id, service-index-1>; S15.2 submits the packet to the NSH FIB lookup for the SF.
The SFF cache is indexed by NSH SPI and SI-1. When an SFF receives a packet destined for a local SF SID, it strips the SR segment list, saves it to the cache, and forwards the NSH packet to the SF. When the packet returns, the SFF retrieves the cached SR header using the NSH SPI and SI and re-encapsulates the packet.
IANA allocated value 84 (0x0054) for the End.NSH - NSH Segment endpoint behavior in the 'SRv6 Endpoint Behaviors' subregistry under the 'Segment Routing' registry, with IETF as the Change Controller.
IANA assigned protocol number 145 with keyword 'NSH' for the Network Service Header in the 'Assigned Internet Protocol Numbers' registry, enabling NSH to be encapsulated directly within an IP header.
Generic SFC-related security considerations are addressed in RFC 7665. NSH-specific security considerations are discussed in RFC 8300. Generic security considerations related to segment routing are covered in RFC 8754 Section 7 and RFC 8663 Section 5.
NSH over SR-MPLS encapsulation stacks: SR-MPLS Labels (variable), NSH Base Header, Service Path Header, and optional Metadata. The MPLS label stack acts as the SR segment list encapsulating the NSH payload.
NSH over SRv6 encapsulation: the Segment Routing Header (SRH) precedes the NSH. The NSH is indicated by the IP protocol number for NSH (145) in the SRH Next Header field. The SRH contains the standard fields (Next Header, Hdr Ext Len, Routing Type, Segments Left, Last Entry, Flags, Tag, Segment List) followed by the NSH Base Header, Service Path Header, and optional variable-length context headers.