path: root/doc/rfc/rfc9491.txt

Internet Engineering Task Force (IETF)                  J. Guichard, Ed.
Request for Comments: 9491                        Futurewei Technologies
Category: Standards Track                               J. Tantsura, Ed.
ISSN: 2070-1721                                                   Nvidia
                                                           November 2023


Integration of the Network Service Header (NSH) and Segment Routing for
                    Service Function Chaining (SFC)

Abstract

   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.

   Combining these technologies allows SR to be used for steering
   packets between Service Function Forwarders (SFFs) along a given
   Service Function Path (SFP), whereas the NSH is responsible for
   maintaining the integrity of the service plane, the SFC instance
   context, and any associated metadata.

   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.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9491.

Copyright Notice

   Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction
     1.1.  SFC Overview and Rationale
     1.2.  Requirements Language
   2.  SFC within Segment Routing Networks
   3.  NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel
   4.  SR-Based SFC with the Integrated NSH Service Plane
   5.  Packet Processing for SR-Based SFC
     5.1.  SR-Based SFC (SR-MPLS) Packet Processing
     5.2.  SR-Based SFC (SRv6) Packet Processing
   6.  Encapsulation
     6.1.  NSH Using SR-MPLS Transport
     6.2.  NSH Using SRv6 Transport
   7.  Security Considerations
   8.  Backwards Compatibility
   9.  Caching Considerations
   10. MTU Considerations
   11. IANA Considerations
     11.1.  Protocol Number for the NSH
     11.2.  SRv6 Endpoint Behavior for the NSH
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Contributors
   Authors' Addresses

1.  Introduction


1.1.  SFC Overview and Rationale

   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 the Third Generation Partnership
   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 their function; 2) some SFs
   that receive traffic that they are not supposed to process (e.g., TCP
   proxies receiving UDP traffic), which inevitably affects their
   dimensioning and performance; and 3) an increased design complexity
   related to the properly ordered invocation of several SFs.

   In order to solve those problems and to decouple the service's
   topology from the underlying physical network while allowing for
   simplified service delivery, SFC techniques have been introduced
   [RFC7665].

   SFC techniques are meant to rationalize the service delivery logic
   and reduce 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.  [RFC7498] provides an
   overview of the overall SFC problem space, and [RFC7665] specifies an
   SFC data plane architecture.  The SFC architecture does not make
   assumptions on how advanced features (e.g., load balancing, loose or
   strict service paths) could be enabled within a domain.  Various
   deployment options are made available to operators with the SFC
   architecture; this approach is fundamental to accommodate various and
   heterogeneous deployment contexts.

   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, reuse
   existing packet header fields, or define an IPv6 extension header).
   Among all these approaches, the IETF created a transport-independent
   SFC encapsulation scheme: NSH [RFC8300].  This design is pragmatic,
   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 SFFs vs. SF-SFF hops.

1.2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  SFC within Segment Routing Networks

   [RFC8300] specifies how to encapsulate the NSH directly within a
   link-layer header.  In this document, IANA has assigned IP protocol
   number 145 for the NSH so that it can also be encapsulated directly
   within an IP header.  The procedures that follow make use of this
   property.

   As described in [RFC8402], SR leverages the source-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 [SERVICE-PROGRAMMING].

   The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and
   Segment Routing over IPv6 (SRv6) [RFC8754], can encode an SF as a
   segment so that a service function chain can be specified as a
   segment list.  Nevertheless, and as discussed in [RFC7498], traffic
   steering is only a subset of the issues that motivated the design of
   the SFC architecture.  Further considerations, such as simplifying
   classification at intermediate SFs and allowing for coordinated
   behaviors among SFs by means of supplying context information (a.k.a.
   metadata), should be considered when designing an SFC data plane
   solution.

   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:

   NSH-based SFC with the SR-based transport plane:
      In this scenario, SR-MPLS or SRv6 provides the transport
      encapsulation between SFFs, while the NSH is used to convey and
      trigger SFC policies.

   SR-based SFC with the integrated NSH service plane:
      In this scenario, each service hop of the service function chain
      is represented as a segment of the SR segment list.  SR is thus
      responsible for steering traffic through the necessary SFFs as
      part of the segment routing path, while the NSH is responsible for
      maintaining the service plane and holding the SFC instance context
      (including associated metadata).

   Of course, it is possible to combine both of these two scenarios to
   support specific deployment requirements and use cases.

   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 (SFP) and different SR policies can coexist on
   the same SFP without conflict during SFF processing.

3.  NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel

   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 of
   illustration, the various SFs involved in a service function chain
   may be available in a single data 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 are
   deployed, 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 or SRv6.

   The following three figures provide an example of an SFC-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.

   Referring to Figure 1, packets of flow F in DC1 are classified into
   an NSH-based service function chain, encapsulated after
   classification as <Inner Pkt><NSH: SPI 100, SI 255><Outer-transport>,
   and forwarded to SFF1 (which is the first SFF hop for this service
   function chain).

   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,
   SFF1 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:
   DC1-GW1> and forwards the packet to DC1-GW1.

   +--------------------------- 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|            |
   |             +------------+       +------------+            |
   |                                                            |
   +------------------------------------------------------------+

                   Figure 1: SR for Inter-DC SFC - Part 1

   Referring now to Figure 2, DC1-GW1 performs a lookup using the
   information conveyed in the NSH, which results in <next-hop: DC2-GW1,
   encapsulation: SR>.  The SR encapsulation, which may be SR-MPLS or
   SRv6, has the SR segment list to forward the packet across the inter-
   DC network to DC2.

                     +----------- Inter DC ----------------+
              (4)    |                (5)                  |
   +------+  ---->   | +---------+   ---->     +---------+ |
   |      |   NSH    | |         |     SR      |         | |
   + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |
   |      |          | |         |             |         | |
   +------+          | +---------+             +---------+ |
                     |                                     |
                     |          +------------+             |
                     |          | S(DC2-GW1) |             |
                     |          +------------+             |
                     |          | N(100,254) |             |
                     |          +------------+             |
                     |          | F:Inner Pkt|             |
                     |          +------------+             |
                     +-------------------------------------+

                   Figure 2: SR for Inter-DC SFC - Part 2

   When the packet arrives at DC2, as shown in Figure 3, the SR
   encapsulation is removed, and DC2-GW1 performs a lookup on the NSH,
   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, SFF2 has <NSH: SPI 100,
   SI 253> when the packet comes back from SF2.  SFF2 does a lookup on
   <NSH: SPI 100, SI 253>, which results in the end of the service
   function chain.

                   +------------------------ 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|                          |
                   |           +------------+                          |
                   +---------------------------------------------------+

                Figure 3: SR for Inter-DC SFC - Part 3

   The benefits of this scheme are listed hereafter:

   *  The network operator is able to take advantage of the transport-
      independent nature of the NSH encapsulation while the service is
      provisioned end-to-end.

   *  The network operator is able to take advantage of the traffic-
      steering (traffic-engineering) capability of SR where appropriate.

   *  Clear responsibility division and scope between the NSH and SR.

   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 forwarding paths, for example).  Further, note that the above
   example can also be implemented using end-to-end segment routing
   between SFF1 and SFF2.  (As such, DC-GW1 and DC-GW2 are forwarding
   the packets based on segment routing instructions and are not looking
   at the NSH header for forwarding.)

4.  SR-Based SFC with the Integrated NSH Service Plane

   In this scenario, we assume that the SFs are NSH-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 between SFs,
   thereby maintaining SFC context (e.g., the service plane path
   referenced by the SPI) and any associated metadata.

   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.

   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 of SR-MPLS, this will be a Prefix-SID [RFC8402].
   In the case of SRv6, the behavior described within this document is
   assigned the name END.NSH, and Section 11.2 describes the allocation
   of the code point by IANA.  The result of this lookup allows the SFF
   to retrieve the next-hop context between the SFF and SF (e.g., the
   destination Media 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.

   The behavior of remembering the SR segment list occurs at the end of
   the regularly defined logic.  The behavior of reattaching the segment
   list occurs before the SR process of forwarding the packet to the
   next entry in the segment list.  Both behaviors are further detailed
   in Section 5.

   When the SF receives the packet, it processes it as usual.  When the
   SF is co-resident with a classifier, the already-processed packet may
   be 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 NSH header and forwards the packet
   to the next segment in the segment list.  The lookup in the SFF cache
   might fail if reclassification 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.

   Figure 4 illustrates an example of this scenario.

                        +-----+                       +-----+
                        | 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|
             +------------+

                    Figure 4: NSH over SR for SFC

   The benefits of this scheme include the following:

   *  It is economically sound for SF vendors to only support one
      unified SFC solution.  The SF is unaware of the SR.

   *  It simplifies the SFF (i.e., the SR router) by nullifying the
      needs for reclassification and SR proxy.

   *  SR is also used for forwarding purposes, including between SFFs.

   *  It takes advantage of SR to eliminate the NSH forwarding state in
      SFFs.  This applies each time strict or loose SFPs are in use.

   *  It requires no interworking, as would be the case if SR-MPLS-based
      SFC and NSH-based SFC were deployed as independent mechanisms in
      different parts of the network.

5.  Packet Processing for SR-Based SFC

   This section describes the End.NSH behavior (SRv6), Prefix-SID
   behavior (SR-MPLS), and NSH processing logic.

5.1.  SR-Based SFC (SR-MPLS) Packet Processing

   When an SFF receives a packet destined to S and S is a local Prefix-
   SID associated with an SF, the SFF strips the SR segment 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.

5.2.  SR-Based SFC (SRv6) Packet Processing

   This section describes the End.NSH behavior and NSH processing logic
   for SRv6.  The pseudocode is shown below.

   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 [RFC8754],
   Section 4.3.1.1, up through line S15.

   After S15, if S is a local End.NSH SID, then:

   S15.1.         Remove and store IPv6 and SRH headers in local cache
                  indexed by <NSH: service-path-id, service-index -1>
   S15.2.         Submit the packet to the NSH FIB lookup and transmit
                  to the destination associated with <NSH:
                  service-path-id, service-index>

      |  Note: The End.NSH behavior interrupts the normal SRH packet
      |  processing, as described in [RFC8754], Section 4.3.1.1, which
      |  does not continue to S16 at this time.

   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.  Then, resume processing from [RFC8754],
   Section 4.3.1.1 with line S16.

6.  Encapsulation


6.1.  NSH Using SR-MPLS Transport

   SR-MPLS instantiates segment identifiers (SIDs) as MPLS labels;
   therefore, the segment routing header is a stack of MPLS labels.

   When carrying an NSH within an SR-MPLS transport, the full
   encapsulation headers are as illustrated in Figure 5.

                          +------------------+
                          ~   SR-MPLS Labels ~
                          +------------------+
                          |   NSH Base Hdr   |
                          +------------------+
                          | Service Path Hdr |
                          +------------------+
                          ~     Metadata     ~
                          +------------------+

                   Figure 5: NSH Using SR-MPLS Transport

   As described in [RFC8402], "[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 the
   SID."  When an NSH is carried beneath SR-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.

   If the NEXT operation is to be used, then at the end of the SR-MPLS
   path, it is necessary to provide an indication to the tail end that
   the NSH follows the SR-MPLS label stack as described by [RFC8596].

   If the CONTINUE operation is to be used, this is the equivalent of
   MPLS Ultimate Hop Popping (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 setting the No Penultimate Hop Popping (No-PHP) flag
   in Prefix-SID Sub-TLV [RFC8667] [RFC8665].  It is RECOMMENDED that a
   specific Prefix-SID be allocated at each node for use by the SFC
   application for this purpose.

6.2.  NSH Using SRv6 Transport

   When carrying a 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-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.)          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6: NSH Using SRv6 Transport

   Encapsulation of the NSH following SRv6 is indicated by the IP
   protocol number for the NSH in the Next Header of the SRH.

7.  Security Considerations

   Generic SFC-related security considerations are discussed in
   [RFC7665].

   NSH-specific security considerations are discussed in [RFC8300].

   Generic security considerations related to segment routing are
   discussed in Section 7 of [RFC8754] and Section 5 of [RFC8663].

8.  Backwards Compatibility

   For SRv6/IPv6, if a processing node does not recognize the NSH, it
   should follow the procedures described in Section 4 of [RFC8200].
   For SR-MPLS, if a processing node does not recognize the NSH, it
   should follow the procedures laid out in Section 3.18 of [RFC3031].

9.  Caching Considerations

   The cache mechanism must remove cached entries at an appropriate time
   determined by the implementation.  Further, an implementation MAY
   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 SFF SHOULD log this event and MUST drop the packet.

10.  MTU Considerations

   Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it
   is RECOMMENDED for network operators to increase the underlying MTU
   so that SR/NSH traffic is forwarded within an SR domain without
   fragmentation.

11.  IANA Considerations

11.1.  Protocol Number for the NSH

   IANA has assigned protocol number 145 for the NSH [RFC8300] in the
   "Assigned Internet Protocol Numbers" registry
   <https://www.iana.org/assignments/protocol-numbers/>.

    +=========+=========+================+================+===========+
    | Decimal | Keyword | Protocol       | IPv6 Extension | Reference |
    |         |         |                | Header         |           |
    +=========+=========+================+================+===========+
    | 145     | NSH     | Network        | N              | RFC 9491  |
    |         |         | Service Header |                |           |
    +---------+---------+----------------+----------------+-----------+

            Table 1: Assigned Internet Protocol Numbers Registry

11.2.  SRv6 Endpoint Behavior for the NSH

   IANA has allocated the following value in the "SRv6 Endpoint
   Behaviors" subregistry under the "Segment Routing" registry:

      +=======+========+===================+===========+============+
      | Value | Hex    | Endpoint Behavior | Reference | Change     |
      |       |        |                   |           | Controller |
      +=======+========+===================+===========+============+
      | 84    | 0x0054 | End.NSH - NSH     | RFC 9491  | IETF       |
      |       |        | Segment           |           |            |
      +-------+--------+-------------------+-----------+------------+

                Table 2: SRv6 Endpoint Behaviors Subregistry

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing with the MPLS Data Plane", RFC 8660,
              DOI 10.17487/RFC8660, December 2019,
              <https://www.rfc-editor.org/info/rfc8660>.

   [RFC8663]  Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
              W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
              DOI 10.17487/RFC8663, December 2019,
              <https://www.rfc-editor.org/info/rfc8663>.

   [RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
              H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", RFC 8665,
              DOI 10.17487/RFC8665, December 2019,
              <https://www.rfc-editor.org/info/rfc8665>.

   [RFC8667]  Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
              Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
              Extensions for Segment Routing", RFC 8667,
              DOI 10.17487/RFC8667, December 2019,
              <https://www.rfc-editor.org/info/rfc8667>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

12.2.  Informative References

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <https://www.rfc-editor.org/info/rfc7498>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8596]  Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
              "MPLS Transport Encapsulation for the Service Function
              Chaining (SFC) Network Service Header (NSH)", RFC 8596,
              DOI 10.17487/RFC8596, June 2019,
              <https://www.rfc-editor.org/info/rfc8596>.

   [SERVICE-PROGRAMMING]
              Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li,
              C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W.,
              and S. Salsano, "Service Programming with Segment
              Routing", Work in Progress, Internet-Draft, draft-ietf-
              spring-sr-service-programming-08, 21 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-service-programming-08>.

Contributors

   The following coauthors provided valuable inputs and text
   contributions to this document.

   Mohamed Boucadair
   Orange
   Email: mohamed.boucadair@orange.com


   Joel Halpern
   Ericsson
   Email: joel.halpern@ericsson.com


   Syed Hassan
   Cisco System, inc.
   Email: shassan@cisco.com


   Wim Henderickx
   Nokia
   Email: wim.henderickx@nokia.com


   Haoyu Song
   Futurewei Technologies
   Email: haoyu.song@futurewei.com


Authors' Addresses

   James N Guichard (editor)
   Futurewei Technologies
   2330 Central Expressway
   Santa Clara, CA
   United States of America
   Email: james.n.guichard@futurewei.com


   Jeff Tantsura (editor)
   Nvidia
   United States of America
   Email: jefftant.ietf@gmail.com