Hierarchical Service Function Chaining with Segment Routing

Introduction Service Function Chaining (SFC) defines an ordered set of service functions and subsequent "steering" of traffic through them. The architecture of SFC is defined in . To ease the problem of implementing SFC across a large, geographically dispersed network, hSFC is proposed to decomposing a large domain to multiple SFC-enabled sub-domains. The topmost level domain encompasses the entire network domain to be managed, and each sub-domain may support a subset of the Service Functions (SFs). Such hierarchical approach can reduce SFC's management complexity and improve the scalability. A simple example to deploy hSFC is where data centers with scattered locations host different types of service functions on a range of hardware and services are provided by SFCs spanning multiple data centers with each as an independent SFC sub-domain . SFC can be implemented based on Network Service Header (NSH) , which requires a mapping between both Service Path Identifier (SPI) and Service Index (SI) to next-hop forwarding. SFC can also be instantiated based on SR, where service SIDs can be combined in a SID-list explicitly indicated by the source SR node to represent an SFC. proposes the hSFC data plane solution based on the assumption of NSH. As a supplement, this document is also based on hierarchical SFC but utilizes SR-based service programming instead. This document follows the same concept of Internal Boundary Node (IBN) defined in to act as a gateway between upper-level domain and lower-level sub-domain. This document mainly describes possible interactions of the upper and lower domains at the IBN using taxonomy and appends SR-specific support in constructing hSFC. This document assumes IBN is SR-aware and follows similar endpoint behavior in . provides another SR-based method (i.e., SR-based SFC with integrated NSH service plane) to implement SFC in single domain. The methods specified in this document still apply to that scenario with some modifications and this may be considered in future work.

Terminology The terms in this document are defined in , and . The following lists widely used terms in this document. CF: Classifier IBN: Internal Boundary Node NSH: Network Service Header SF: Service Function SFC: Service Function Chaining hSFC: Hierarchical Service Function Chaining SR: Segment Routing SC: Service Chain TTL: Time To Live NAT: Network Address Translator

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Internal Boundary Node (IBN) This document follows the concept of Internal Boundary Node (IBN) defined in , which acts as a gateway to connect the upper and lower domains. depicts an example architecture of hSFC. In SR-based hSFC, an IBN acts as an SR Proxy in the upper-level domain and as a classifier in the lower-level domain . The CF within IBN performs lower-level path selection (reclassification in sub-domain) and SR Proxy within IBN is responsible to handle upper-level SR paths, including caching and restoring them whenever the packets exit the sub-domain via IBN. IBN also realizes some cross-domain information transfer (e.g., SFC metadata). In the example, packets are classified to traverse SC#1 in the upper-level classifier. When they arrives at the IBN, they're further re-classified by lower-level classifier to enter either SC#2 or SC#3. After the packets are processed by last SF (i.e., SF#2.2 or SF#3.2) of each lower-level SC, they're returned to IBN and then resume SC#1 traversal.

Illustration of hSFC Architecture | +--------+ +--------------> | CF | | | SFF | | +--------+ | +--------+ | | | | +--------+ | | | Lower- | | ***************** | level | ***************** * sub-domain | | CF | | * * +----+-+-+--------^<+--------+ * * | | | | * * | | | | * * | +--v----+ ++------+ | * * | | SF#3.1+------> SF#3.2| | * * | +-------+ +-------+ | * * | | * * +-v-------+ +-------+-+ * * | SF#2.1 +------------> SF#2.2 | * * +---------+ +---------+ * * * ********************************************** ]]>

Path Selection/(Re-)Classification The classification in upper-level domain (SR-based) follows the definition in . The packets steered into an SR policy carry an ordered list of segments associated with that SR policy including corresponding IBNs. The re-classification in lower-level domain varies according to the SFC deployment method applied in the sub-domain, for SR-based SFC and for NSH-based SFC.

Path Restoration The information of upper-level SC is either not required or not available in the sub-domain. As per , it's recommended to store such information somewhere, within the packets themselves or in the IBN. At the termination of an SC in the sub-domain, the packets SHOULD be restored to the original upper-level SC to resume remaining SFC. The following methods are categorized into stateful and stateless according to whether the state is stored in IBN.

Stateful IBN The stateful method needs to store the state in the IBN, including the upper-level SC path (e.g., the whole IPv6 header, or partial fields such as SRH that are necessary to recover the path) and other auxiliary information (e.g., SFC metadata), and restore the state in order to recover the upper-level path when packets are returned to the IBN in the sub-domain. The state saved in the IBN needs to be organized by selecting an appropriate index method so that the upper-level path can be accurately restored when exiting the sub-domain and consequently packets resume the remaining SFC processing. The downside of stateful method is that it requires IBN to maintain scalability to handle the state explosion in large-scale networks with massive flows. The design of scalable IBNs is out-of-scope in this document. This document further categorizes stateful methods with different indexing system.

Flow-indexed State IBN can identify traffic in the granularity of flow such as five-tuple (source address, destination address, source port, destination port) , and use such information as an index to cache the state. Assume that the flow-specific information should not be modified in the lower-level domain, the path can be later restored by adopting the same identification. However, this information may be modified in the lower-level domain (SFs such as NAT may modify the fields in the five-tuple). In this case, it is necessary to assign flow IDs with flow granularity in the IBN as described in and encapsulate it in the packet (e.g., carried by metadata as shown in ), and use flow ID to index the state when exiting the sub-domain, with the assumption that this flow ID MUST NOT be modified along the path.

Encode Flow ID in Metadata

Path-indexed State This section describes how to index state in IBN by path-specific identifier.

Upper-level Path ID As per , SPI is used to distinguish different upper-level SC paths which can be used as an index method. As for SR-based SFC where service information is carried by data plane (e.g., SID list), the data plane information can be utilized to recognize different upper-level SC paths. A passive method is to reuse the unique identifier of the upper-level path provided by native data plane mechanism such as path segment to index the states in IBN and encapsulate it in the metadata of packets throughout the sub-domain whereas the upper-level data plane information is thereby stripped and cached in IBN. Such path-specific identifiers can be used to index the state and perform path recovery at the termination of sub-domain in the IBN. A proactive method is to compute and assign the path ID based of hash value of data plane information (e.g., source address and segment list) when the packets arrived at IBN. The packets would carry this path ID in metadata within the sub-domain. This identifier is also used to index the state and realize path restoration when the packets terminates sub-domain SC at the exit of IBN. The assumption of the above two methods is that the sub-domain MUST NOT modify the path ID carried by metadata in the packets.

Lower-level Path ID When the IBN reclassifies the packets, it can uniquely assign unique path ID to the selected lower-level path. This path ID is utilized to index the state and also be carried by the packet in order to restore the upper-level state, following the aforementioned methods as upper-level path ID. This method can only be effective assuming the traffic from different upper-level SCs MUST NOT be re-classified to the same lower-level SC. Otherwise, the same path ID will be ambiguously mapped into multiple upper-level path states. Comparison: Typically, a class of flows may be classified into the same service function path. Therefore, flow-indexed method needs to assign more flow-specific identifiers (as index) and store more corresponding states (as value) to realize path restoration compared with path-indexed one.

SID-bound State proposes SR proxies to support SR-unaware SFs so that the SFs are agnostic about the SR network. This concept can also apply in hSFC since the lower-level SFC sub-domain is agnostic about the upper-level SR network. Therefore, SR-based hSFC can reuse the architecture of SR proxies (either static or dynamic) defined in and thus, realize incremental deployment from single-layer SR SFC to hierarchical one. In such case, an IBN is composed of an SR Proxy in place of SFF in and an additional sub-domain classifier. The SR Proxy and the classifier could be deployed in either co-located or separate devices. As shown in , IBN in SR-based hSFC could be bound with SID in the granularity of upper-level path. As per , the SID is bound to a pair of directed interfaces (i.e., IFACE-IN and IFACE-OUT) on the proxy, where the matched traffic is sent via IFACE-OUT towards the associated lower-level CF and receiving the traffic returning from the CF via IFACE-IN. When the destination address of a packet matches the bound SID entry in the FIB of the SR-aware IBN, IBN decapsulates the upper-level SR Header of the packet and stores the state indexed by the receiving interface(IFACE-IN). After classified by the CF, lower-level SR header (if sub-domain supports SR-based SFC) will be encapsulated to the original packet in order for sub-domain SFC traversal.

Example of IBN Evolving from SR Proxy ~ | | IFACE | IFACE | | ~---------> | CF | (1) ~ +-+ OUT | IN +-+ ~ (3) +--------+ ~ +-------+-------+ ~ ~ ~ ~ +---------------+ ~ ~ | Lower-level | ~ ~~~~| CF |~~~~ *************| |************** * sub-domain +--+--------^---+ * * | | * * +----+-+ +---^-------+ * * | | | | * * | +--v----+ +--+----+ | * * | | SF#3.1+------> SF#3.2| | * * | +-------+ +-------+ | * * | | * * +-v-------+ +------+-+ * * | SF#2.1 +------------> SF#2.2 | * * +---------+ (2) +--------+ * ******************************************** +--------------+ | Lower-level | | SR Header | +--------------+ | Original | | Packet | +--------------+ ]]>

Stateless IBN Compared with the stateful method, when entering the sub-domain, the stateless method does not require to store the state in the IBN locally. All upper-level path states are carried along with the packets themselves by either metadata or header encapsulation described below. The disadvantage is that it will enlarge the original packet header, which may encounter MTU problems and reduce transmission efficiency in the sub-domains. As the state is no longer stored in the IBN, when the sub-domain completes lower-level SFP, it is no longer required to return to the centralized IBN for the recovery of the upper-level path. Especially when some nodes (e.g., the last SF/SFF in lower-level path) are capable of restoring the upper-level SFP from the packet as IBN does, these nodes can extract the path information themselves without packets' going back to IBN. Furthermore, the packet can be directly forward to next-hop of upper-level path if the upper-level routing policy is visible to the sub-domain. This optimization would reduce the workload of the centralized IBN, promoting the scalability and reliability. There are generally two ways to carry upper-level path state within the packet: metadata and header encapsulation.

Metadata In and , several methods of SFC metadata are defined, most of which are avaiable to take along upper-level path state as shown in .

Encode Upper-level Path State in Metadata In such case, SFs in the sub-domain are all required to support the recognition of the metadata it uses. Therefore, the inner payload can be processed by transparently skipping the metadata.

Header Encapsulation The header encapsulation method is to nest the upper-level SR header between the header of the lower-level SFP and the inner payload as illustrated in and . This requires all SFs in the sub-domain to be able to identify the upper-level IPv6 and extension header nested behind lower-level SFC header(e.g., SR or NSH). Therefore, the inner payload can be processed by transparently skipping the upper-SR header.

Encapsulation for SR-based Sub-domain

Encapsulation for NSH-based Sub-domain Comparison: The encapsulation method requires to retain the whole upper-level header. In comparison, metadata can only carry partial information that is sufficient to reconstruct the upper-level path.