| SFC | J. Guichard, Ed. |
| Internet-Draft | H. Song |
| Intended status: Informational | Huawei |
| Expires: September 20, 2018 | J. Tantsura |
| Nuage Networks | |
| J. Halpern | |
| Ericsson | |
| W. Henderickx | |
| Nokia | |
| March 19, 2018 |
NSH and Segment Routing Integration for Service Function Chaining
draft-guichard-sfc-nsh-sr-00
This document describes two application scenarios where Network Service Header (NSH) and Segment Routing (SR) can be deployed together to support Service Function Chaining (SFC) in an efficient manner while maintaining separation of the service and transport planes as originally intended by the SFC architecture.
In the first scenario, an NSH-based SFC is created using SR as the transport between SFFs. SR in this case is just one of many encapsulations that could be used to maintain the transport-independent nature of NSH-based service chains.
In the second scenario, SR is used to represent each service hop of the NSH-based SFC as a segment within the segment-list. SR and NSH in this case are integrated.
In both of these scenarios SR is responsible for steering packets between SFFs of a given SFP and NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata.
These application scenarios demonstrate that NSH and SR can work jointly and complement each other leaving the network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure, and still maintain an end-to-end service plane using the NSH technology.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 20, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Service Function Chaining (SFC) allows network services to be dynamically created for specific flows by chaining the relevant service functions in the right sequence. RFC7498 provides an overview of the SFC problem statement and RFC7665 specifies the SFC architecture. NSH-based SFC is the most mature SFC solution.
As described in, Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an SR Policy instantiated as an ordered list of instructions called segments. While initially designed for policy-based source routing, SR also finds its application in supporting SFC [I-D.xu-clad-spring-sr-service-chaining]. The two flavors of SR, namely MPLS-SR and SRv6, can both encode a Service Function (SF) as a segment so that an SFC can be specified as a segment list.
While each scheme (i.e., NSH-based SFC and SR-based SFC) can work independently, we show how the two can work together in concert and complement each other through two representative application scenarios. Both application scenarios may be supported using either MPLS-SR or SRv6:
It is of course possible to combine both of these two scenarios so as to support specific deployment requirements and use cases.
Because of the transport-independent nature of NSH-based service chains, it is expected that the technology has broad applicability across different domains of the network. By way of illustration perhaps the SFs for a given SFC are available in a single data center, or perhaps spread throughout multiple data centers, or different POPs, depending upon the preference and/or availability of service resources. Regardless of where the service resources are deployed it is necessary to provide traffic steering through a set of SFFs and NSH-based service chains provide the flexibility for the network operator to choose which particular tunnel transport to use between said SFFs, which may be different depending upon which area of the network the SFF/SF is currently deployed. Therefore from an SFC architecture perspective, segment routing is simply one of multiple available transport encapsulations that can be used for traffic steering between SFFs.
The following 3 figures provide an example of an SFC established for flow F that has SFs located in different data centers, DC1 and DC2. For the purpose of illustration, let the SFC's Service Path Identifier (SPI) be 100 and the initial Service Index (SI) be 255.
Referring to Figure 1 packets of flow F in DC1 are classified into an NSH-based SFC and encapsulated after classification as <Inner Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1.
After removing the outer transport encapsulation, that may or may not be MPLS-SR or SRv6, SFF1 uses the SPI, SI carried within the NSH encapsulation to determine that it should forward the packet to SF1. SF1 applies its service, decrements the SI by 1, and returns the packet to SFF1. SFF1 therefore has <SPI 100, SI 254> when the packet comes back from SF1. SFF1 does a lookup on <SPI 100, SI 254> which results in <next-hop: DC-GW1> and forwards the packet to DC-GW 1.
+--------------------------- DC1 ---------------------------+
| +-----+ |
| | SF1 | |
| +--+--+ |
| | |
| | |
| +------------+ | +------------+ |
| | N(100,255) | | | F:Inner Pkt| |
| +------------+ | +------------+ |
| | F:Inner Pkt| | | N(100,254) | |
| +------------+ ^ | | +------------+ |
| (2) | | | (3) |
| | | v |
| (1) | (4) |
|+------------+ ----> +--+---+ ----> +--------+ |
|| | NSH | | NSH | | |
|| Classifier +------------+ SFF1 +--------------+ DC-GW1 + |
|| | | | | | |
|+------------+ +------+ +--------+ |
| |
| +------------+ +------------+ |
| | N(100,255) | | N(100,254) | |
| +------------+ +------------+ |
| | F:Inner Pkt| | F:Inner Pkt| |
| +------------+ +------------+ |
| |
+-----------------------------------------------------------+
Figure 1: SR for inter-DC SFC - Part 1
+----------- Inter DC --------------+
| (5) |
+------+ ----> | +--------+ ----> +--------+ |
| | NSH | | | SR | | |
+ SFF1 +----------|-+ DC-GW1 +-------------+ DC-GW2 + |
| | | | | | | |
+------+ | +--------+ +--------+ |
| |
| +------------+ |
| | S(DC-GW2) | |
| +------------+ |
| | N(100,254) | |
| +------------+ |
| | F:Inner Pkt| |
| +------------+ |
+-----------------------------------+
Figure 2: SR for inter-DC SFC - Part 2
Referring now to Figure 2 DC-GW1 performs a lookup on the NSH which results in <next-hop: DC-GW2, encapsulation: SR>. The SR encapsulation has the SR segment-list to forward the packet across the Inter-DC network to DC2.
+------------------------ DC2 ----------------------+
| +-----+ |
| | SF2 | |
| +--+--+ |
| | |
| | |
| +------------+ | +------------+ |
| | N(100,254) | | | F:Inner Pkt| |
| +------------+ | +------------+ |
| | F:Inner Pkt| | | N(100,253) | |
| +------------+ ^ | | +------------+ |
| (7) | | | (8) |
| | | v |
| (6) | (9) |
|+---------+ ----> +--+---+ ----> |
|| | NSH | | IP |
|| DC-GW2 +------------+ SFF2 | |
|| | | | |
|+---------+ +------+ |
| |
| +------------+ +------------+ |
| | N(100,254) | | F:Inner Pkt| |
| +------------+ +------------+ |
| | F:Inner Pkt| |
| +------------+ |
+---------------------------------------------------+
Figure 3: SR for inter-DC SFC - Part 3
When the packet arrives at DC2, as shown in Figure 3, DC-GW1 performs a lookup on the NSH which results in <next-hop: DC-GW2, encapsulation: SR>. The SR encapsulation has the SR segment-list to forward the packet across the Inter-DC network to DC2.
Note that this scenario is applicable to any case where multiple sections of an SFC are distributed into multiple domains or where a traffic engineered path is necessary between SFFs.
In this scenario we assume that the SFs are NSH-aware and therefore it should not be necessary to implement an SFC proxy to achieve Service Function Chaining. The operation relies upon SR to perform SFF-SFF transport and NSH to provide the service plane between SFs thereby maintaining SFC context and metadata.
When an SFC is established, a packet will first encapsulate an NSH that will be used to maintain the end-to-end service plane through use of the SFC context. The SFC context (e.g., the service plane path referenced by the SPI) is used by an SFF to determine the SR segment list for forwarding the packet between the SFFs. The packet is then encapsulated with the SR header and forwarded in the SR domain.
When a packet's service segment targets a local SF, the SFF strips off its SR header, updates the SR information, and saves it to a cache indexed by the NSH SPI. This saved SR information is used to encapsulate and forward the packet(s) coming back from the SF.
When the SF receives the packet, it processes the packet as usual and sends it back to the SFF. Once the SFF receives this packet, it extracts the SR information using the NSH SPI as the index into the cache. The SFF then pushes the SR header on top of the NSH header, and forwards the packet to the next segment in the segment list.
+-----+ +-----+
| SF1 | | SF2 |
+--+--+ +--+--+
| |
| |
+-----------+ | +-----------+ +-----------+ | +-----------+
|N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt|
+-----------+ | +-----------+ +-----------+ | +-----------+
|F:Inner Pkt| | |N(100,254) | |F:Inner Pkt| | |N(100,253) |
+-----------+ | +-----------+ +-----------+ | +-----------+
(2) ^ | (3) | (5) ^ | (6) |
| | | | | |
| | v | | v
+------------+ (1)--> +-+----+ (4)--> +---+--+ (7)-->IP
| | NSHoSR | | NSHoSR | |
| Classifier +--------+ SFF1 +---------------------+ SFF2 |
| | | | | |
+------------+ +------+ +------+
+------------+ +------------+
| S(SF1) | | S(SF2) |
+------------+ +------------+
| S(SFF2) | | N(100,254) |
+------------+ +------------+
| S(SF2) | | F:Inner Pkt|
+------------+ +------------+
| N(100,255) |
+------------+
| F:Inner Pkt|
+------------+
Figure 4: NSH over SR for SFC
Figure 4 illustrates an example of this scenario.
MPLS-SR instantiates Segment IDs (SIDs) as MPLS labels and therefore the segment routing header is a stack of MPLS labels.
When carrying NSH within an MPLS-SR transport the full encapsulation is as illustrated in Figure 5.
+------------------+
~ MPLS-SR Labels ~
+------------------+
| NSH Base Hdr |
+------------------+
| Service Path Hdr |
+------------------+
~ Metadata ~
+------------------+
Figure 5: NSH using MPLS-SR Transport
As described in the IGP signaling extension for IGP-Prefix segment includes a flag to indicate whether directly connected neighbors of the node on which the prefix is attached should perform the NEXT operation or the CONTINUE operation when processing the SID. When NSH is carried beneath MPLS-SR it is necessary to terminate the NSH-based SFC at the tail-end node of the MPLS-SR label stack. This is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore the prefix-SID associated with the tail-end of the SFC MUST be advertised with the CONTINUE operation so that the penultimate hop node does not pop the top label of the MPLS-SR label stack and thereby expose NSH to the wrong SFF. It is recommended that a specific prefix-SID be allocated at each node for use by the SFC application for this purpose.
At then end of the MPLS-SR path it is necessary to provide an indication to the tail-end that NSH follows the MPLS-SR label stack. There are several ways to achieve this but specification is outside the scope of this document.
When carrying NSH within an SRv6 transport the full encapsulation is as illustrated in Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e
| | g
| Segment List[0] (128 bits IPv6 address) | m
| | e
| | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t
| |
| | R
~ ... ~ o
| | u
| | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i
| | n
| Segment List[n] (128 bits IPv6 address) | g
| |
| | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
// // H
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| Service Path Identifier | Service Index | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| |
~ Variable-Length Context Headers (opt.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NSH using MPLS-SR Transport
TBD.
This memo includes no request to IANA.
TBD.