<?xml version="1.0"encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!ENTITY SFCARCH SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"><!ENTITYSFCSTATE SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7498.xml">nbsp " "> <!ENTITYRFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8665 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml"> <!ENTITY RFC8667 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8667.xml"> <!ENTITY RFC8402 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"> <!ENTITY RFC3031 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"> <!ENTITY RFC8200 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"> <!ENTITY NSH SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml">zwsp "​"> <!ENTITYRFC8754 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml">nbhy "‑"> <!ENTITYRFC8660 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"> <!ENTITY RFC8596 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8596.xml"> <!ENTITY RFC8663 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8663.xml"> <!ENTITY SRARCH SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-segment-routing-15.xml"> <!ENTITY SRMPLS SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-segment-routing-mpls-12.xml"> <!ENTITY SRV6 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6man-segment-routing-header-09.xml"> <!ENTITY SRSPGM SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-sr-service-programming-07.xml">wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="3"?> <!-- the number of levels of subsections in ToC. default: 3 --> <!-- control references --> <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="yes" docName="draft-ietf-spring-nsh-sr-15"ipr="trust200902">number="9491" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <titleabbrev="NSH-SRabbrev="NSH SR SFC">Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)</title> <seriesInfo name="RFC" value="9491"/> <author fullname="James N Guichard" initials="J" surname="Guichard" role="editor"> <organization>Futurewei Technologies</organization> <address> <postal> <street>2330 CentralExpress Way</street>Expressway</street> <city>Santa Clara</city><country>USA</country><country>United States of America</country> </postal> <email>james.n.guichard@futurewei.com</email> </address> </author> <author fullname="Jeff Tantsura" initials="J" surname="Tantsura" role="editor"> <organization>Nvidia</organization> <address> <postal><street></street> <city></city> <country>USA</country><street/> <city/> <country>United States of America</country> </postal> <email>jefftant.ietf@gmail.com</email> </address> </author> <datemonth="June"month="November" year="2023"/> <area>RTG</area> <workgroup>SPRING</workgroup><keyword>NSH, SR, MPLS-SR, SRv6, SFC</keyword><keyword>NSH</keyword> <keyword>SR</keyword> <keyword>MPLS-SR</keyword> <keyword>SRv6</keyword> <keyword>SFC</keyword> <abstract> <t> This document describes the integration of the Network Service Header (NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture.</t><t></t> <t> Combining these technologies allows SR to be used for steering packets between Service Function Forwarders(SFF)(SFFs) along a given Service Function Path(SFP) while NSH has(SFP), whereas theresponsibilityNSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata.</t><t></t> <t> This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH. </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> </t> <sectiontitle="SFCnumbered="true" toc="default"> <name>SFC Overview andRationale">Rationale</name> <t> The dynamic enforcement of a service-derived and adequate forwarding policy for packets entering a network that supports advanced Service Functions (SFs) has become a key challenge for network operators. For instance, cascading SFs at the3GPP (ThirdThird Generation PartnershipProject)Project (3GPP) Gi interface (N6 interface in 5G architecture) has shown limitations such as 1) redundant classification features that must be supported by many SFs to execute theirfunction,function; 2) some SFs that receive traffic that they are not supposed to process (e.g., TCP proxies receiving UDPtraffic)traffic), which inevitably affects their dimensioning andperformance,performance; and 3) an increased design complexity related to the properly ordered invocation of several SFs.</t><t></t> <t> In order to solve thoseproblems,problems and to decouple the service's topology from the underlying physical network while allowing for simplified service delivery,Service Function Chaining (SFC)SFC techniques have been introduced <xreftarget="RFC7665"></xref>. </t><t>target="RFC7665" format="default"/>. </t> <t> SFC techniques are meant to rationalize the service delivery logic andmasterreduce the resulting complexity while optimizing service activation time cycles for operators that need more agile service delivery procedures to better accommodate ever-demanding customer requirements. SFC allows network operators to dynamically create service planes that can be used by specific traffic flows. Each service plane is realized by invoking and chaining the relevant service functions in the right sequence. <xreftarget="RFC7498"></xref>target="RFC7498" format="default"/> provides an overview of the overall SFC problemspacespace, and <xreftarget="RFC7665"></xref>target="RFC7665" format="default"/> specifies an SFC data plane architecture. The SFC architecture does not make assumptions on how advanced features (e.g.,load-balancing,load balancing, loose or strict service paths) could be enabled within a domain. Various deployment options are made available to operators with the SFCarchitecture andarchitecture; this approach is fundamental to accommodate various and heterogeneous deployment contexts.</t><t> Many</t> <t>Many approaches can be considered for encoding the information required for SFC purposes (e.g., communicate a service chain pointer, encode a list of loose/explicit paths, or disseminate a service chain identifier together with a set of context information). Likewise, many approaches can also be considered for the channel to be used to carry SFC-specific information (e.g., define a new header,re-usereuse existing packet header fields, or define an IPv6 extension header). Among all these approaches, the IETF created a transport-independent SFC encapsulation scheme: NSH <xreftarget="RFC8300"></xref>.target="RFC8300" format="default"/>. This design ispragmaticpragmatic, as it does not require replicating the same specification effort as a function of underlying transport encapsulation. Moreover, this design approach encourages consistent SFC-based service delivery in networks enabling distinct transport protocols in various network segments or even between SFFsvsvs. SF-SFF hops. </t> </section> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <sectiontitle="SFCnumbered="true" toc="default"> <name>SFC within Segment RoutingNetworks"> <t> [RFC8300]Networks</name> <t><xref target="RFC8300" format="default"/> specifies how to encapsulate theNetwork Service HeaderNSH directly within a link-layer header. In this document,we assign anIANA has assigned IP protocol number[TBA1]145 for theNSH,NSH so that it can also be encapsulated directly within an IP header. The procedures that follow make use of this property. </t><t> <xref target="RFC8402">As<t>As describedin</xref>,in <xref target="RFC8402" format="default"/>, SR leverages thesource routingsource-routing technique. Concretely, 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 <xreftarget="I-D.ietf-spring-sr-service-programming"></xref>. </t><t>target="I-D.ietf-spring-sr-service-programming" format="default"/>. </t> <t> The two SR data plane encapsulations, namely <xreftarget="RFC8660">SR-MPLS</xref>target="RFC8660" format="default">SR-MPLS</xref> and <xreftarget="RFC8754">SRv6</xref>,target="RFC8754" format="default">Segment Routing over IPv6 (SRv6)</xref>, canbothencode an SF as a segment so thatan SFCa service function chain can be specified as a segment list. Nevertheless, and as discussed in <xreftarget="RFC7498"></xref>,target="RFC7498" format="default"/>, traffic steering is only a subset of the issues that motivated the design of the SFC architecture. Furtherconsiderationsconsiderations, such as simplifying classification at intermediate SFs and allowing for coordinated behaviors among SFs by means of supplying context information (a.k.a.metadata)metadata), should be considered when designing an SFC data plane solution.</t><t> While</t> <t>While each scheme (i.e., NSH-based SFC and SR-based SFC) can work independently, this document describes how the two can be used together in concert and to complement each other through two representative application scenarios. Both application scenarios may be supported using either SR-MPLS or SRv6:</t><t> <list style="symbols"> <t> NSH-based</t> <dl spacing="normal" newline="true"> <dt>NSH-based SFC with the SR-based transportplane: inplane:</dt> <dd>In thisscenarioscenario, SR-MPLS or SRv6 provides the transport encapsulation betweenSFFsSFFs, while the NSH is used to convey and trigger SFCpolicies. </t><t> SR-basedpolicies.</dd> <dt>SR-based SFC with the integrated NSH serviceplane: inplane:</dt> <dd>In thisscenarioscenario, each service hop of theSFCservice function chain is represented as a segment of the SRsegment-list.segment list. SR is thus responsible for steering traffic through the necessary SFFs as part of the segment routingpathpath, while the NSH is responsible for maintaining the service plane and holding the SFC instance context (including associatedmetadata). </t> </list> Itmetadata).</dd> </dl> <t>Of course, it isof coursepossible to combine both of these two scenarios to support specific deployment requirements and use cases. </t><t> A<t>A classifierMUST<bcp14>MUST</bcp14> useanone NSH Service Path Identifier (SPI)perfor each SR policy so that different traffic flowsthatcan use the same NSH Service Function Path (SFP)butand different SRpolicypolicies can coexist on the same SFP without conflict during SFF processing.</t> </section> <sectiontitle="NSH-basednumbered="true" toc="default"> <name>NSH-Based SFC with SR-MPLS or the SRv6 TransportTunnel"> <t> BecauseTunnel</name> <t>Because of the transport-independent nature of NSH-based service function chains, it is expected that the NSH has broad applicability across different network domains (e.g., access, core). By way ofillustrationillustration, the various SFs involved in a service function chain may be available in a single datacenter,center or spread throughout multiple locations (e.g., data centers, different Points of Presence (POPs)), depending upon the network operator preference and/or availability of service resources. Regardless of where the SFs aredeployeddeployed, it is necessary to provide traffic steering through a set of SFFs, and when NSH and SR are integrated, this is provided by SR-MPLS orSRv6. </t><t> TheSRv6.</t> <t>The following three figures provide an example of anSFC establishedSFC-established flow F that has SF instances located in different data centers, DC1 and DC2. For the purpose of illustration, let the SFC's NSH SPI be 100 and the initial Service Index (SI) be 255.</t><t> Referring</t> <t>Referring to <xreftarget="figure_1"></xref>,target="figure_1" format="default"/>, packets of flow F in DC1 are classified into an NSH-basedSFC andservice function chain, encapsulated after classification as <Inner Pkt><NSH: SPI 100, SI255><Outer-transport>255><Outer-transport>, and forwarded to SFF1 (which is the first SFF hop for this service functionchain). </t><t> Afterchain).</t> <t>After removing the outer transport encapsulation, SFF1 uses the SPI and 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. Therefore, SFF1thereforehas <SPI 100, SI 254> when the packet comes back from SF1. SFF1 does a lookup on <SPI 100, SI254>254>, which results in <next-hop: DC1-GW1> and forwards the packet to DC1-GW1.</t><t></t> <figuretitle="SRanchor="figure_1"> <name>SR forinter-DCInter-DC SFC - Part1" anchor="figure_1"> <artwork>1</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------------------------- DC1 ----------------------------+ | +-----+ | | | SF1 | | | +--+--+ | | | | | | | | +------------+ | +------------+ | | | N(100,255) | | | N(100,254) | | | +------------+ | +------------+ | | | F:Inner Pkt| | | F:Inner Pkt| | | +------------+ ^ | | +------------+ | | (2) | | | (3) | | | | v | | (1) | (4) | |+------------+ ----> +--+---+ ----> +---------+ | || | NSH | | NSH | | | || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + | || | | | | | | |+------------+ +------+ +---------+ | | | | +------------+ +------------+ | | | N(100,255) | | N(100,254) | | | +------------+ +------------+ | | | F:Inner Pkt| | F:Inner Pkt| | | +------------+ +------------+ | | | +------------------------------------------------------------+</artwork> </figure> </t><t>]]></artwork></figure> <t> Referring now to <xreftarget="figure_2"></xref>,target="figure_2" format="default"/>, DC1-GW1 performs a lookup using the information conveyed in theNSHNSH, which results in <next-hop: DC2-GW1, encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or SRv6, has the SRsegment-listsegment list to forward the packet across the inter-DC network to DC2. </t> <figuretitle="SRanchor="figure_2"> <name>SR forinter-DCInter-DC SFC - Part2" anchor="figure_2"> <artwork>2</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +----------- Inter DC ----------------+ (4) | (5) | +------+ ----> | +---------+ ----> +---------+ | | | NSH | | | SR | | | + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | | | | | | | | | +------+ | +---------+ +---------+ | | | | +------------+ | | | S(DC2-GW1) | | | +------------+ | | | N(100,254) | | | +------------+ | | | F:Inner Pkt| | | +------------+ | +-------------------------------------+</artwork>]]></artwork> </figure></t><t><t> When the packet arrives at DC2, as shown in <xreftarget="figure_3"></xref>,target="figure_3" format="default"/>, the SR encapsulation isremovedremoved, and DC2-GW1 performs a lookup on theNSHNSH, which results in next hop: SFF2. When SFF2 receives the packet, it performs a lookup on <NSH: SPI 100, SI 254> and determines to forward the packet to SF2. SF2 applies its service, decrements the SI by 1, and returns the packet to SFF2. Therefore, SFF2thereforehas <NSH: SPI 100, SI 253> when the packet comes back from SF2. SFF2 does a lookup on <NSH: SPI 100, SI253>253>, which results in the end of the service function chain. </t> <figuretitle="SRanchor="figure_3"> <name>SR forinter-DCInter-DC SFC - Part3" anchor="figure_3"> <artwork>3</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +------------------------ DC2 ----------------------+ | +-----+ | | | SF2 | | | +--+--+ | | | | | | | | +------------+ | +------------+ | | | N(100,254) | | | N(100,253) | | | +------------+ | +------------+ | | | F:Inner Pkt| | | F:Inner Pkt| | | +------------+ ^ | | +------------+ | | (7) | | | (8) | | | | v | (5) | (6) | (9) | +---------+ ---> | +----------+ ----> +--+---+ ----> | | | SR | | | NSH | | IP | + DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | | | | | | | | | | +---------+ | +----------+ +------+ | | | | +------------+ +------------+ | | | N(100,254) | | F:Inner Pkt| | | +------------+ +------------+ | | | F:Inner Pkt| | | +------------+ | +---------------------------------------------------+</artwork>]]></artwork> </figure> <t> The benefits of this scheme are listed hereafter:</t><t> <list style="symbols"> <t> The</t> <ul spacing="normal"> <li>The network operator is able to take advantage of the transport-independent nature of the NSHencapsulation,encapsulation while the service is provisionedend-to-end. </t><t> Theend-to-end.</li> <li>The network operator is able to take advantage of thetraffic steering (traffic engineering)traffic-steering (traffic-engineering) capability of SR whereappropriate. </t><t> Clearappropriate.</li> <li>Clear responsibility division and scope between the NSH andSR. </t> </list> </t><t> NoteSR.</li> </ul> <t>Note that this scenario is applicable to any case where multiple segments of a service function chain are distributed across multiple domains or where traffic-engineered paths are necessary between SFFs (strict forwardingpathspaths, for example). Further, note that the above example can also be implemented using end-to-end segment routing between SFF1 and SFF2. (Assuchsuch, DC-GW1 and DC-GW2 are forwarding the packets based on segment routing instructions and are not looking at the NSH header for forwarding.) </t> </section> <sectiontitle="SR-basednumbered="true" toc="default"> <name>SR-Based SFC with the Integrated NSH ServicePlane"> <t> InPlane</name> <t>In thisscenarioscenario, we assume that the SFs areNSH-aware and thereforeNSH-aware; therefore, it should not be necessary to implement an SFC proxy to achieve SFC. The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF transport and the NSH to provide the service plane betweenSFsSFs, thereby maintaining SFC context (e.g., the service plane path referenced by the SPI) and any associated metadata.</t><t> When</t> <t>When a service function chain is established, a packet associated with that chain will first carry an NSH that will be used to maintain the end-to-end service plane through use of the SFC context. The SFC context is used by an SFF to determine the SR segment list for forwarding the packet to the next-hop SFFs. The packet is then encapsulated using the SR header and forwarded in the SR domain following normal SR operations.</t><t> When</t> <t>When a packet has to be forwarded to an SF attached to an SFF, the SFF performs a lookup on the segment identifier (SID) associated with the SF. In the case ofSR-MPLSSR-MPLS, this will be aprefix SIDPrefix-SID <xreftarget="RFC8402"></xref>.target="RFC8402" format="default"/>. In the case of SRv6, the behavior described within this document is assigned the name END.NSH, andsection 9.2 requests<xref target="NSHEPB"/> describes the allocation ofathe code point by IANA. The result of this lookup allows the SFF to retrieve thenext hopnext-hop context between the SFF and SF (e.g., the destinationMACMedia Access Control (MAC) address in case Ethernet encapsulation is used between the SFF and SF). In addition, the SFF strips the SR information from the packet, updates the SR information, and saves it to a cache indexed by the NSH Service Path Identifier (SPI) and the Service Index (SI) decremented by 1. This saved SR information is used to encapsulate and forward the packet(s) coming back from the SF.</t><t> The</t> <t>The behavior of remembering the SRsegment-listsegment list occurs at the end of the regularly defined logic. The behavior of reattaching thesegment-listsegment list occurs before the SR process of forwarding the packet to the next entry in thesegment-list.segment list. Both behaviors are further detailed insection 5. </t><t> When<xref target="sec-5"/>. </t> <t>When the SF receives the packet, it processes it as usual. When the SF is co-resident with a classifier, thealready processedalready-processed packet may bere-classified.reclassified. The SF sends the packet back to the SFF. Once the SFF receives this packet, it extracts the SR information using the NSH SPI and SI as the index into the cache. The SFF then pushes the retrieved SR header on top of the NSHheader,header and forwards the packet to the next segment in thesegment-list.segment list. The lookup in the SFF cache might fail ifre-classificationreclassification at the SF changed the NSH SPI and/or SI to values that do not exist in the SFF cache. In such a case, the SFF must generate an error and drop the packet.</t><t></t> <t> <xreftarget="figure_4"></xref>target="figure_4" format="default"/> illustrates an example of this scenario. </t> <figuretitle="NSHanchor="figure_4"> <name>NSH over SR forSFC" anchor="figure_4"> <artwork>SFC</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-----+ +-----+ | SF1 | | SF2 | +--+--+ +--+--+ | | | | +-----------+ | +-----------+ +-----------+ | +-----------+ |N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) |,+-----------+ | +-----------+ +-----------+ | +-----------+ |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| +-----------+ | +-----------+ +-----------+ | +-----------+ (2) ^ | (3) | (5) ^ | (6) | | | | | | | | | | | | | (1) | | v (4) | | v (7) +------------+ ---> +-+----+ ----> +---+--+ --> | | NSHoverSR | | NSHoverSR | | IP | Classifier +-----------+ SFF1 +---------------------+ SFF2 | | | | | | | +------------+ +------+ +------+ +------------+ +------------+ +------------+ | S(SF1) | | S(SF2) | | F:Inner Pkt| +------------+ +------------+ +------------+ | S(SFF2) | | N(100,254) | +------------+ +------------+ | S(SF2) | | F:Inner Pkt| +------------+ +------------+ | N(100,255) | +------------+ | F:Inner Pkt| +------------+</artwork>]]></artwork> </figure>The<t>The benefits of this schemeinclude: </t><t> <list style="symbols"> <t> Itinclude the following: </t> <ul spacing="normal"> <li>It is economically sound for SF vendors to only support one unified SFC solution. The SF is unaware of theSR. </t><t> ItSR.</li> <li>It simplifies the SFF (i.e., the SR router) by nullifying the needs forre-classificationreclassification and SRproxy. </t><t> SRproxy.</li> <li>SR is also used for forwardingpurposespurposes, including betweenSFFs. </t><t> ItSFFs.</li> <li>It takes advantage of SR to eliminate the NSH forwarding state in SFFs. This applies each time strict or loose SFPs are inuse. </t><t> Ituse.</li> <li>It requires nointerworkinginterworking, as would be the case ifSR-MPLS basedSR-MPLS-based SFC and NSH-based SFC were deployed as independent mechanisms in different parts of thenetwork. </t> </list> </t>network.</li> </ul> </section> <sectiontitle="Packetnumbered="true" toc="default" anchor="sec-5"> <name>Packet Processing forSR-based SFC">SR-Based SFC</name> <t> This section describes the End.NSH behavior (SRv6),Prefix SIDPrefix-SID behavior (SR-MPLS), and NSH processing logic.</t> <sectiontitle="SR-basednumbered="true" toc="default"> <name>SR-Based SFC (SR-MPLS) PacketProcessing">Processing</name> <t> When an SFF receives a packet destined to S and S is a localprefix SIDPrefix-SID associated with an SF, the SFF strips the SRsegment-listsegment list (label stack) from the packet, updates the SR information, and saves it to a cache indexed by the NSH Service Path Identifier (SPI) and the Service Index (SI) decremented by 1. This saved SR information is used to re-encapsulate and forward the packet(s) coming back from the SF.</t> </section> <sectiontitle="SR-basednumbered="true" toc="default"> <name>SR-Based SFC (SRv6) PacketProcessing">Processing</name> <t> This section describes the End.NSH behavior and NSH processing logic for SRv6. The pseudocode is shown below.</t> <t> When N receives a packet destined to S and S is a local End.NSH SID, the processing is the same as that specified by <xreftarget="RFC8754"></xref> section 4.3.1.1,target="RFC8754" sectionFormat="comma" section="4.3.1.1"/>, up through lineS.15.</t>S15.</t> <t> AfterS.15,S15, if S is a local End.NSH SID, then:</t><t><sourcecode type="pseudocode"><![CDATA[ S15.1. Remove and store IPv6 and SRH headers in local cache indexed by<NSH:<NSH: service-path-id, service-index-1></t> <t>-1> S15.2. Submit the packet to the NSH FIB lookup and transmit to the destination associated with<NSH:<NSH: service-path-id,service-index></t> <t> Note:service-index> ]]></sourcecode> <aside><t>Note: The End.NSH behavior interrupts the normal SRH packetprocessingprocessing, as described in <xreftarget="RFC8754"></xref> section 4.3.1.1,target="RFC8754" sectionFormat="comma" section="4.3.1.1"/>, which does not continue to S16 at thistime.</t>time.</t></aside> <t> When a packet is returned to the SFF from the SF, reattach the cached IPv6 and SRH headers based on the <NSH: service-path-id, service-index> from the NSH header.ThenThen, resume processing from <xreftarget="RFC8754"></xref> section 4.3.1.1target="RFC8754" sectionFormat="comma" section="4.3.1.1"/> with lineS.16.</t>S16.</t> </section> </section> <section anchor="Encapsulation"title="Encapsulation">numbered="true" toc="default"> <name>Encapsulation</name> <t> </t> <section anchor="MPLS-SR"title="NSH usingnumbered="true" toc="default"> <name>NSH Using SR-MPLSTransport">Transport</name> <t> SR-MPLS instantiatesSegment IDssegment identifiers (SIDs) as MPLSlabels and thereforelabels; therefore, the segment routing header is a stack of MPLS labels.</t><t></t> <t> When carrying an NSH within an SR-MPLS transport, the full encapsulation headers are as illustrated in <xreftarget="figure_5"></xref>. </t><t>target="figure_5" format="default"/>. </t> <figurealign="center" title="NSH using SR-MPLS Transport"anchor="figure_5"><artwork><name>NSH Using SR-MPLS Transport</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +------------------+ ~MPLS-SRSR-MPLS Labels ~ +------------------+ | NSH Base Hdr | +------------------+ | Service Path Hdr | +------------------+ ~ Metadata ~ +------------------+</artwork>]]></artwork> </figure></t><t> <xref target="RFC8402">As<t>As describedin</xref>, thein <xref target="RFC8402" format="default"/>, "[t]he 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 theSID.SID." When an NSH is carried beneathSR-MPLSSR-MPLS, it is necessary to terminate the NSH-based SFC at the tail-end node of the SR-MPLS label stack. This can be achieved using either the NEXT or CONTINUE operation.</t><t></t> <t> If the NEXT operation is to be used, then at the end of the SR-MPLSpathpath, it is necessary to provide an indication to thetail-endtail end that the NSH follows the SR-MPLS label stack as described by <xreftarget="RFC8596"></xref>. </t><t>target="RFC8596" format="default"/>. </t> <t> If the CONTINUE operation is to be used, this is the equivalent of MPLS Ultimate Hop Popping(UHP) and therefore(UHP); therefore, it is necessary to ensure that the penultimate hop node does not pop the top label of the SR-MPLS label stack and thereby expose the NSH to the wrong SFF. This is realized by settingNo-PHPthe No Penultimate Hop Popping (No-PHP) flag in Prefix-SID Sub-TLV <xreftarget="RFC8667"></xref>,target="RFC8667" format="default"/> <xreftarget="RFC8665"></xref>.target="RFC8665" format="default"/>. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that a specificprefix-SIDPrefix-SID be allocated at each node for use by the SFC application for this purpose. </t> </section> <section anchor="SRv6"title="NSH usingnumbered="true" toc="default"> <name>NSH Using SRv6Transport">Transport</name> <t>When carrying a NSH within an SRv6transporttransport, the full encapsulation is as illustrated in <xreftarget="figure_6"></xref>. </t><t>target="figure_6" format="default"/>. </t> <figurealign="center" title="NSH using SRv6 Transport"anchor="figure_6"><artwork><name>NSH Using SRv6 Transport</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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-bit IPv6 address) | m | | e | | n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t | | | | R ~ ... ~ o | | u | | t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i | | n | Segment List[n] (128-bit 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.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>]]></artwork> </figure></t><t>Encapsulation of the NSH following SRv6 is indicated by the IP protocol number for the NSH in the Next Header of the SRH.</t> </section> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> Generic SFC-related security considerations are discussed in <xreftarget="RFC7665"></xref>.</t>target="RFC7665" format="default"/>.</t> <t> NSH-specific security considerations are discussed in <xreftarget="RFC8300"></xref>.</t>target="RFC8300" format="default"/>.</t> <t> Genericsegment routing relatedsecurity considerations related to segment routing are discussed insection 7 of<xreftarget="RFC8754"></xref>target="RFC8754" sectionFormat="of" section="7"/> andsection 5 of<xreftarget="RFC8663"></xref>.target="RFC8663" sectionFormat="of" section="5"/>. </t> </section> <sectiontitle="Backwards Compatibility">numbered="true" toc="default"> <name>Backwards Compatibility</name> <t>For SRv6/IPv6, if a processing node does not recognizeNSHthe NSH, it should follow the procedures described insection 4 of<xreftarget="RFC8200"></xref>.target="RFC8200" sectionFormat="of" section="4"/>. For SR-MPLS, if a processing node does not recognizeNSHthe NSH, it should follow the procedures laid out insection 3.18 of<xreftarget="RFC3031"></xref>.target="RFC3031" sectionFormat="of" section="3.18"/>. </t> </section> <sectiontitle="Caching Considerations">numbered="true" toc="default"> <name>Caching Considerations</name> <t>The cache mechanism must remove cached entries at an appropriate time determined by the implementation. Further, an implementationMAY<bcp14>MAY</bcp14> allow network operators to set the said time value. In the case where a packet arriving from an SF does not have a matching cached entry, the SFFSHOULD<bcp14>SHOULD</bcp14> log thisevent,event andMUST<bcp14>MUST</bcp14> drop the packet. </t> </section> <sectiontitle="MTU Considerations"> <t> Alignednumbered="true" toc="default"> <name>MTU Considerations</name> <t>Aligned withSection 5 of [RFC8300]<xref target="RFC8300" sectionFormat="of" section="5"/> andSection 5.3 of<xreftarget="RFC8754"></xref>,target="RFC8754" sectionFormat="of" section="5.3"/>, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> for network operators to increase the underlying MTU so that SR/NSH traffic is forwarded within an SR domain without fragmentation. </t> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="NSHPROTO"title="Protocolnumbered="true" toc="default"> <name>Protocol Number forNSH"> <figure><artwork>IANA is requested to assign athe NSH</name> <t>IANA has assigned protocol numberTBA1145 for the NSH[RFC8300] from<xref target="RFC8300" format="default"/> in the "Assigned Internet Protocol Numbers" registryavailable at https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml +---------+---------+--------------+---------------+----------------+ | Decimal | Keyword |<eref target="https://www.iana.org/assignments/protocol-numbers/" brackets="angle"/>.</t> <table anchor="iana-1" align="center"> <name>Assigned Internet Protocol| IPv6 | Reference | | | | |Numbers Registry</name> <thead> <tr> <th>Decimal</th> <th>Keyword</th> <th>Protocol</th> <th>IPv6 Extension| | | | | | Header | | +---------+---------+--------------+---------------+----------------+ | TBA1 | NSH | Network | N | [This Document]| | | |Header</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>145</td> <td>NSH</td> <td>Network Service| | | | | | Header | | | +---------+---------+--------------+---------------+----------------+ </artwork></figure>Header</td> <td>N</td> <td>RFC 9491</td> </tr> </tbody> </table> </section> <section anchor="NSHEPB"title="SRv6numbered="true" toc="default"> <name>SRv6 Endpoint Behavior forNSH"> <figure><artwork>This I-D requests IANA to allocate, withinthe NSH</name> <t>IANA has allocated the following value in the "SRv6 Endpoint Behaviors"sub-registry belonging to the top-level "Segment-routing with IPv6 data plane (SRv6) Parameters" registry,subregistry under thefollowing allocations: Value Description Reference -------------------------------------------------------------- TBA2 End.NSH"Segment Routing" registry:</t> <table anchor="iana-2" align="center"> <name>SRv6 Endpoint Behaviors Subregistry</name> <thead> <tr> <th>Value</th> <th>Hex</th> <th>Endpoint Behavior</th> <th>Reference</th> <th>Change Controller</th> </tr> </thead> <tbody> <tr> <td>84</td> <td>0x0054</td> <td>End.NSH - NSHSegment [This.ID] </artwork></figure>Segment</td> <td>RFC 9491</td> <td>IETF</td> </tr> </tbody> </table> </section> </section> </middle> <back> <displayreference target="I-D.ietf-spring-sr-service-programming" to="SERVICE-PROGRAMMING"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8663.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8667.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7498.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8596.xml"/> <reference anchor="I-D.ietf-spring-sr-service-programming"> <front> <title>Service Programming with Segment Routing</title> <author fullname="Francois Clad" initials="F." surname="Clad" role="editor"> <organization>Cisco Systems, Inc.</organization> </author> <author fullname="Xiaohu Xu" initials="X." surname="Xu" role="editor"> <organization>China Mobile</organization> </author> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <organization>Cisco Systems, Inc.</organization> </author> <author fullname="Daniel Bernier" initials="D." surname="Bernier"> <organization>Bell Canada</organization> </author> <author fullname="Cheng Li" initials="C." surname="Li"> <organization>Huawei</organization> </author> <author fullname="Bruno Decraene" initials="B." surname="Decraene"> <organization>Orange</organization> </author> <author fullname="Shaowen Ma" initials="S." surname="Ma"> <organization>Mellanox</organization> </author> <author fullname="Chaitanya Yadlapalli" initials="C." surname="Yadlapalli"> <organization>AT&T</organization> </author> <author fullname="Wim Henderickx" initials="W." surname="Henderickx"> <organization>Nokia</organization> </author> <author fullname="Stefano Salsano" initials="S." surname="Salsano"> <organization>Universita di Roma "Tor Vergata"</organization> </author> <date day="21" month="August" year="2023"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-service-programming-08"/> </reference> </references> </references> <section anchor="Contributors"title="Contributing Authors"> <t><figure><artwork> Thenumbered="false" toc="default"> <name>Contributors</name> <t>The followingco-authors, along with their respective affiliations at the time of publication,coauthors provided valuable inputs and text contributions to thisdocument. Mohamed Boucadair Orange mohamed.boucadair@orange.com Joel Halpern Ericsson joel.halpern@ericsson.com Syed Hassan Ciscodocument.</t> <contact fullname="Mohamed Boucadair"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </contact> <contact fullname="Joel Halpern"> <organization>Ericsson</organization> <address> <email>joel.halpern@ericsson.com</email> </address> </contact> <contact fullname="Syed Hassan"> <organization>Cisco System,inc. shassan@cisco.com Wim Henderickx Nokia wim.henderickx@nokia.com Haoyu Song Futurewei Technologies haoyu.song@futurewei.com </artwork></figure></t>inc.</organization> <address> <email>shassan@cisco.com</email> </address> </contact> <contact fullname="Wim Henderickx"> <organization>Nokia</organization> <address> <email>wim.henderickx@nokia.com</email> </address> </contact> <contact fullname="Haoyu Song"> <organization>Futurewei Technologies</organization> <address> <email>haoyu.song@futurewei.com</email> </address> </contact> </section></middle> <back> <references title="Normative References"> &RFC2119; &RFC8174; &RFC8402; &NSH; &RFC8754; &RFC8660; &RFC8663; &RFC8665; &RFC8667; &RFC3031; &RFC8200; </references> <references title="Informative References"> &SFCSTATE; &SFCARCH; &RFC8596; &SRSPGM; </references></back> </rfc>