rfc9491xml2.original.xml   rfc9491.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "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">
<!ENTITY SFCSTATE SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7498.xml">
<!ENTITY RFC2119 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.830
0.xml">
<!ENTITY RFC8754 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8754.xml">
<!ENTITY RFC8660 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/refere
nce.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/refere
nce.I-D.draft-ietf-spring-segment-routing-mpls-12.xml">
<!ENTITY SRV6 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/referenc
e.I-D.draft-ietf-6man-segment-routing-header-09.xml">
<!ENTITY SRSPGM SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.draft-ietf-spring-sr-service-programming-07.xml">
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?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 category="std" docName="draft-ietf-spring-nsh-sr-15" ipr="trust200902">
<front>
<title abbrev="NSH-SR SFC">Integration of Network Service Header
(NSH) and Segment Routing
for Service Function Chaining (SFC)</title>
<author fullname="James N Guichard" initials="J" surname="Guichar
d" role="editor">
<organization>Futurewei Technologies</organization>
<address>
<postal>
<street>2330 Central Express Way</street>
<city>Santa Clara</city>
<country>USA</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>
</postal>
<email>jefftant.ietf@gmail.com</email>
</address>
</author>
<date month="June" year="2023"/>
<area>RTG</area>
<workgroup>SPRING</workgroup>
<keyword>NSH, SR, MPLS-SR, SRv6, SFC</keyword>
<abstract>
<t>
This document describes the integration of the Ne
twork 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 a
s originally intended by the SFC architecture.
</t><t>
Combining these technologies allows SR to be used
for steering packets between Service Function
Forwarders (SFF) along a given Service Function
Path (SFP) while NSH has the responsibility for
maintaining the integrity of the service plane,
the SFC instance context, and any associated metadata.
</t><t>
This integration demonstrates that NSH and SR ca
n 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 NSH.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
</t>
<section title="SFC Overview and Rationale">
<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 the 3GPP (Third Generation Partnership Project) Gi interface
(N6 interface in 5G architecture) has
shown limitations such as 1) redundant classific
ation features must be supported by many SFs to execute their function, 2) some
SFs 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 SF
s.
</t><t>
In order to solve those problems, and to decouple
the service's topology from the underlying physical network while allowing for
simplified service delivery, Service
Function Chaining (SFC) techniques have been intr
oduced <xref target="RFC7665"></xref>.
</t><t>
SFC techniques are meant to rationalize the servi
ce delivery logic and master the resulting complexity while optimizing service a
ctivation time cycles for operators
that need more agile service delivery procedures
to better accommodate ever-demanding customer requirements. SFC allows network o
perators 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 function
s in the right sequence.
<xref target="RFC7498"></xref> provides an overvi
ew of the overall SFC problem space and <xref target="RFC7665"></xref> specifies
an SFC data plane architecture.
The SFC architecture does not make assumptions o
n how advanced features (e.g., load-balancing, loose or strict service paths) co
uld be enabled within
a domain. Various deployment options are made av
ailable to operators with the SFC architecture and this approach is fundamental
to accommodate various and heterogeneous
deployment contexts.
</t><t>
Many approaches can be considered for encoding th
e information required for SFC purposes (e.g., communicate a service chain point
er, encode a list of loose/explicit paths,
or disseminate a service chain identifier togethe
r with a set of context information). Likewise, many approaches can also be cons
idered for the channel to be used to carry
SFC-specific information (e.g., define a new head
er, re-use existing packet header fields, or define an IPv6 extension header). A
mong all these approaches, the IETF created a
transport-independent SFC encapsulation scheme: N
SH <xref target="RFC8300"></xref>. This design is pragmatic as it does not requi
re replicating the same specification effort as a function of underlying
transport encapsulation. Moreover, this design a
pproach encourages consistent SFC-based service delivery in networks enabling di
stinct transport protocols in various network
segments or even between SFFs vs SF-SFF hops.
</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHA
LL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY
", and
"OPTIONAL" in this document are to be interpreted as described
in BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and on
ly when, they appear in all capitals, as shown here.</t>
</section>
</section>
<section title="SFC within Segment Routing Networks">
<t>
[RFC8300] specifies how to encapsulate the Netwo
rk Service Header directly within a link-layer header. In this document, we assi
gn an IP
protocol number [TBA1] for the NSH, so that it c
an also be encapsulated directly within an IP header. The procedures that follow
make use of this property.
</t>
<t>
<xref target="RFC8402">As described in</xref>, SR
leverages the source routing technique. Concretely, a node steers a packet thro
ugh an
SR policy instantiated as an ordered list of inst
ructions called segments. While initially designed for policy-based source routi
ng, SR also finds
its application in supporting SFC <xref target="I
-D.ietf-spring-sr-service-programming"></xref>.
</t><t>
The two SR data plane encapsulations, namely <xre
f target="RFC8660">SR-MPLS</xref> and <xref target="RFC8754">SRv6</xref>,
can both encode an SF as a segment so that an SFC
can be specified as a segment list. Nevertheless, and as discussed in <xref tar
get="RFC7498"></xref>,
traffic steering is only a subset of the issues t
hat 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 consid
ered when designing an SFC data plane solution.
</t><t>
While each scheme (i.e., NSH-based SFC and SR-bas
ed SFC) can work independently, this document describes how the two can be used
together in concert and 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 SFC with SR-based trans
port plane: in this scenario SR-MPLS or SRv6 provides the transport encapsulatio
n between SFFs while NSH is used to convey and trigger SFC policies.
</t><t>
SR-based SFC with integrated NSH
service plane: in this scenario each service hop of the SFC 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 NSH is responsible for
maintaining the service plane and holding the SFC
instance context (including assoc
iated metadata).
</t>
</list>
It is of course possible to combine both of these
two scenarios to support specific deployment requirements and use cases.
</t>
<t> A classifier MUST use an NSH Service Path Identifier
(SPI) per SR policy so that different traffic flows that use the same NSH Servi
ce Function Path (SFP) but different SR policy can coexist on the same SFP witho
ut conflict during SFF processing.</t>
</section> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<section title="NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel"> std" consensus="yes" docName="draft-ietf-spring-nsh-sr-15" number="9491" ipr="tr
<t> ust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3"
Because of the transport-independent nature of NS symRefs="true" sortRefs="true" version="3">
H-based service function chains, it is expected that the NSH has broad applicabi
lity across different network domains (e.g., access, core).
By way of illustration the various SFs involved i
n a service function chain may be available in a single data center, or spread t
hroughout multiple locations (e.g., data centers, different Points of Presence (
POPs)), depending
upon the network operator preference and/or avail
ability of service resources. Regardless of where the SFs are deployed it is nec
essary to provide traffic steering through a set
of SFFs, and when NSH and SR are integrated, this
is provided by SR-MPLS or SRv6.
</t><t> <front>
The following three figures provide an example of <title abbrev="NSH SR SFC">Integration of the Network Service Header (NSH)
an SFC established flow F that has SF instances located in different data cente and Segment Routing for Service Function Chaining (SFC)</title>
rs, DC1 and DC2. For the purpose of illustration, let <seriesInfo name="RFC" value="9491"/>
the SFC's NSH SPI be 100 and the initial Service <author fullname="James N Guichard" initials="J" surname="Guichard" role="ed
Index (SI) be 255. itor">
</t><t> <organization>Futurewei Technologies</organization>
Referring to <xref target="figure_1"></xref>, pac <address>
kets of flow F in DC1 are classified into an NSH-based SFC and encapsulated afte <postal>
r classification <street>2330 Central Expressway</street>
as &lt;Inner Pkt&gt;&lt;NSH: SPI 100, SI 255&gt;& <city>Santa Clara</city>
lt;Outer-transport&gt; and forwarded to SFF1 (which is the first SFF hop for thi <country>United States of America</country>
s service function chain). </postal>
</t><t> <email>james.n.guichard@futurewei.com</email>
After removing the outer transport encapsulation </address>
, SFF1 uses the SPI and SI carried within the NSH encapsulation to determine tha </author>
t it should forward the packet to SF1. SF1 applies its service, <author fullname="Jeff Tantsura" initials="J" surname="Tantsura" role="edito
decrements the SI by 1, and returns the packet t r">
o SFF1. SFF1 therefore has &lt;SPI 100, SI 254&gt; when the packet comes back fr <organization>Nvidia</organization>
om SF1. SFF1 does a lookup on &lt;SPI 100, SI 254&gt; which <address>
results in &lt;next-hop: DC1-GW1&gt; and forward <postal>
s the packet to DC1-GW1. <street/>
</t><t> <city/>
<figure title="SR for inter-DC SFC - Part 1" anch <country>United States of America</country>
or="figure_1"> </postal>
<artwork> <email>jefftant.ietf@gmail.com</email>
</address>
</author>
<date month="November" year="2023"/>
<area>RTG</area>
<workgroup>SPRING</workgroup>
<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> 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.
</t>
<t> This integration demonstrates that the NSH and SR can work cooperative
ly
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>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>
</t>
<section numbered="true" toc="default">
<name>SFC Overview and 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 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 suppo
sed
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.
</t>
<t> 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 <xref
target="RFC7665" format="default"/>.
</t>
<t> 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. <xref target="RFC7498"
format="default"/> provides an overview of the overall SFC problem
space, and <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, loose or str
ict
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.
</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, 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 <xref target="RFC8300"
format="default"/>. 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.
</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t> The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14 <xref
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
</t>
</section>
</section>
<section numbered="true" toc="default">
<name>SFC within Segment Routing Networks</name>
<t><xref target="RFC8300" format="default"/> 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.
</t>
<t>As described in <xref target="RFC8402" format="default"/>, 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 <xref
target="I-D.ietf-spring-sr-service-programming" format="default"/>.
</t>
<t> The two SR data plane encapsulations, namely <xref target="RFC8660"
format="default">SR-MPLS</xref> and <xref target="RFC8754"
format="default">Segment Routing over IPv6 (SRv6)</xref>, can encode an
SF as a segment so that a service function chain can be specified as a seg
ment
list. Nevertheless, and as discussed in <xref target="RFC7498"
format="default"/>, 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.
</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>
<dl spacing="normal" newline="true">
<dt>NSH-based SFC with the SR-based transport plane:</dt>
<dd>In this scenario, SR-MPLS or SRv6 provides the transport
encapsulation between SFFs, while the NSH is used to convey and trigger S
FC
policies.</dd>
<dt>SR-based SFC with the integrated NSH service plane:</dt>
<dd>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).</dd>
</dl>
<t>Of course, it is possible to combine both of these two scenarios to
support specific deployment requirements and use cases.
</t>
<t>A classifier <bcp14>MUST</bcp14> 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.</t>
</section>
<section numbered="true" toc="default">
<name>NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel</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 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.</t>
<t>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.
</t>
<t>Referring to <xref target="figure_1" format="default"/>, packets of
flow F in DC1 are classified into an NSH-based service function chain,
encapsulated after classification as &lt;Inner Pkt&gt;&lt;NSH: SPI 100,
SI 255&gt;&lt;Outer-transport&gt;, and forwarded to SFF1 (which is the
first SFF hop for this service function chain).</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, SFF1 has &lt;SPI 100, SI
254&gt; when the packet comes back from SF1. SFF1 does a lookup on
&lt;SPI 100, SI 254&gt;, which results in &lt;next-hop: DC1-GW1&gt; and
forwards the packet to DC1-GW1.
</t>
<figure anchor="figure_1">
<name>SR for Inter-DC SFC - Part 1</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+--------------------------- DC1 ----------------------------+ +--------------------------- DC1 ----------------------------+
| +-----+ | | +-----+ |
| | SF1 | | | | SF1 | |
| +--+--+ | | +--+--+ |
| | | | | |
| | | | | |
| +------------+ | +------------+ | | +------------+ | +------------+ |
| | N(100,255) | | | N(100,254) | | | | N(100,255) | | | N(100,254) | |
| +------------+ | +------------+ | | +------------+ | +------------+ |
| | F:Inner Pkt| | | F:Inner Pkt| | | | F:Inner Pkt| | | F:Inner Pkt| |
skipping to change at line 229 skipping to change at line 253
|| | | | | | | || | | | | | |
|+------------+ +------+ +---------+ | |+------------+ +------+ +---------+ |
| | | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | N(100,255) | | N(100,254) | | | | N(100,255) | | N(100,254) | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | F:Inner Pkt| | F:Inner Pkt| | | | F:Inner Pkt| | F:Inner Pkt| |
| +------------+ +------------+ | | +------------+ +------------+ |
| | | |
+------------------------------------------------------------+ +------------------------------------------------------------+
]]></artwork></figure>
</artwork> <t> Referring now to <xref target="figure_2" format="default"/>, DC1-GW1
</figure> performs a lookup using the information conveyed in the NSH, which
</t><t> results in &lt;next-hop: DC2-GW1, encapsulation: SR&gt;. The SR
Referring now to <xref target="figure_2"></xref>, encapsulation, which may be SR-MPLS or SRv6, has the SR segment list to
DC1-GW1 performs a lookup using the information conveyed in the NSH which resul forward the packet across the inter-DC network to DC2.
ts in &lt;next-hop: DC2-GW1, encapsulation: SR&gt;. </t>
The SR encapsulation, which may be SR-MPLS or SRv <figure anchor="figure_2">
6, has the SR segment-list to forward the packet across the inter-DC network to <name>SR for Inter-DC SFC - Part 2</name>
DC2. <artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="SR for inter-DC SFC - Part 2" anch
or="figure_2">
<artwork>
+----------- Inter DC ----------------+ +----------- Inter DC ----------------+
(4) | (5) | (4) | (5) |
+------+ ----> | +---------+ ----> +---------+ | +------+ ----> | +---------+ ----> +---------+ |
| | NSH | | | SR | | | | | NSH | | | SR | | |
+ SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |
| | | | | | | | | | | | | | | |
+------+ | +---------+ +---------+ | +------+ | +---------+ +---------+ |
| | | |
| +------------+ | | +------------+ |
| | S(DC2-GW1) | | | | S(DC2-GW1) | |
| +------------+ | | +------------+ |
| | N(100,254) | | | | N(100,254) | |
| +------------+ | | +------------+ |
| | F:Inner Pkt| | | | F:Inner Pkt| |
| +------------+ | | +------------+ |
+-------------------------------------+ +-------------------------------------+
]]></artwork>
</artwork> </figure>
</figure> <t> When the packet arrives at DC2, as shown in <xref target="figure_3"
format="default"/>, the SR encapsulation is removed, and DC2-GW1
</t><t> performs a lookup on the NSH, which results in next hop: SFF2. When SFF2
When the packet arrives at DC2, as shown in <xref receives the packet, it performs a lookup on &lt;NSH: SPI 100, SI
target="figure_3"></xref>, the SR encapsulation is removed and DC2-GW1 performs 254&gt; and determines to forward the packet to SF2. SF2 applies its
a lookup on the NSH which results in service, decrements the SI by 1, and returns the packet to
next hop: SFF2. When SFF2 receives the packet, it SFF2. Therefore, SFF2 has &lt;NSH: SPI 100, SI 253&gt; when the packet
performs a lookup on &lt;NSH: SPI 100, SI 254&gt; and determines to forward the comes back from SF2. SFF2 does a lookup on &lt;NSH: SPI 100, SI
packet to SF2. SF2 applies its service, 253&gt;, which results in the end of the service function chain.
decrements the SI by 1, and returns the packet t </t>
o SFF2. SFF2 therefore has &lt;NSH: SPI 100, SI 253&gt; when the packet comes ba <figure anchor="figure_3">
ck from SF2. SFF2 does a lookup on &lt;NSH: SPI 100, SI 253&gt; <name>SR for Inter-DC SFC - Part 3</name>
which results in the end of the service function <artwork name="" type="" align="left" alt=""><![CDATA[
chain.
<figure title="SR for inter-DC SFC - Part 3" anch
or="figure_3">
<artwork>
+------------------------ DC2 ----------------------+ +------------------------ DC2 ----------------------+
| +-----+ | | +-----+ |
| | SF2 | | | | SF2 | |
| +--+--+ | | +--+--+ |
| | | | | |
| | | | | |
| +------------+ | +------------+ | | +------------+ | +------------+ |
| | N(100,254) | | | N(100,253) | | | | N(100,254) | | | N(100,253) | |
| +------------+ | +------------+ | | +------------+ | +------------+ |
| | F:Inner Pkt| | | F:Inner Pkt| | | | F:Inner Pkt| | | F:Inner Pkt| |
skipping to change at line 293 skipping to change at line 320
+ DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | | + DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | |
| | | | | | | | | | | | | | | |
+---------+ | +----------+ +------+ | +---------+ | +----------+ +------+ |
| | | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | N(100,254) | | F:Inner Pkt| | | | N(100,254) | | F:Inner Pkt| |
| +------------+ +------------+ | | +------------+ +------------+ |
| | F:Inner Pkt| | | | F:Inner Pkt| |
| +------------+ | | +------------+ |
+---------------------------------------------------+ +---------------------------------------------------+
]]></artwork>
</artwork> </figure>
</figure> <t>
The benefits of this scheme are listed hereafter: The benefits of this scheme are listed hereafter:
</t><t> </t>
<list style="symbols"> <ul spacing="normal">
<t> <li>The network operator is able to take advantage of the
The network operator is able to t transport-independent nature of the NSH encapsulation while the
ake advantage of the transport-independent nature of the NSH encapsulation, whil service is provisioned end-to-end.</li>
e the service is provisioned end-to-end. <li>The network operator is able to take advantage of the
</t><t> traffic-steering (traffic-engineering) capability of SR where
The network operator is able to t appropriate.</li>
ake advantage of the traffic steering (traffic engineering) capability of SR whe <li>Clear responsibility division and scope between the NSH and SR.</li>
re appropriate. </ul>
</t><t> <t>Note that this scenario is applicable to any case where multiple
Clear responsibility division and segments of a service function chain are distributed across multiple
scope between NSH and SR. domains or where traffic-engineered paths are necessary between SFFs
</t> (strict forwarding paths, for example). Further, note that the above
</list> example can also be implemented using end-to-end segment routing between
</t><t> SFF1 and SFF2. (As such, DC-GW1 and DC-GW2 are forwarding the packets
Note that this scenario is applicable to any case based on segment routing instructions and are not looking at the NSH
where multiple segments of a service function chain are distributed across mult header for forwarding.)
iple domains or where traffic-engineered paths are necessary </t>
between SFFs (strict forwarding paths for example </section>
). Further, note that the above example can also be implemented using end-to-end <section numbered="true" toc="default">
segment routing between SFF1 and SFF2. (As such DC-GW1 and DC-GW2 <name>SR-Based SFC with the Integrated NSH Service Plane</name>
are forwarding the packets based on segment routi <t>In this scenario, we assume that the SFs are NSH-aware; therefore,
ng instructions and are not looking at the NSH header for forwarding.) it should not be necessary to implement an SFC proxy to achieve SFC.
</t> The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF transport
</section> and the NSH to provide the service plane between SFs, thereby maintaining
<section title="SR-based SFC with Integrated NSH Service Plane"> SFC
<t> context (e.g., the service plane path referenced by the SPI) and any
In this scenario we assume that the SFs are NSH-a associated metadata.
ware and therefore it should not be necessary to implement an SFC proxy to achie </t>
ve SFC. <t>When a service function chain is established, a packet associated
The operation relies upon SR-MPLS or SRv6 to perf with that chain will first carry an NSH that will be used to maintain
orm SFF-SFF transport and NSH to provide the service plane between SFs thereby m the end-to-end service plane through use of the SFC context. The SFC
aintaining SFC context (e.g., the service plane path referenced by the SPI) and context is used by an SFF to determine the SR segment list for
any associated metadata. forwarding the packet to the next-hop SFFs. The packet is then
</t><t> encapsulated using the SR header and forwarded in the SR domain
When a service function chain is established, a p following normal SR operations.
acket associated with that chain will first carry an NSH that will be used to ma </t>
intain the end-to-end service plane through use of the SFC context. <t>When a packet has to be forwarded to an SF attached to an SFF, the
The SFC context is used by an SFF to determine th SFF performs a lookup on the segment identifier (SID) associated with
e SR segment list for forwarding the packet to the next-hop SFFs. the SF. In the case of SR-MPLS, this will be a Prefix-SID <xref
The packet is then encapsulated using the SR head target="RFC8402" format="default"/>. In the case of SRv6, the behavior
er and forwarded in the SR domain following normal SR operations. described within this document is assigned the name END.NSH, and <xref
</t><t> target="NSHEPB"/> describes the allocation of the code point by IANA. The
When a packet has to be forwarded to an SF attach result of this lookup allows the SFF to retrieve the next-hop context
ed to an SFF, the SFF performs a lookup on the segment identifier (SID) associat between the SFF and SF (e.g., the destination Media Access Control (MAC)
ed with the SF. In the case of SR-MPLS this will be a prefix SID <xref target="R address in case Ethernet encapsulation is used between the SFF and SF). In
FC8402"></xref>. addition, the SFF strips the SR information from the packet, updates the
In the case of SRv6, the behavior described with SR information, and saves it to a cache indexed by the NSH Service Path
in this document is assigned the name END.NSH, and section 9.2 requests allocati Identifier (SPI) and the Service Index (SI) decremented by 1. This saved
on of a code point by IANA. The result of this lookup allows the SFF SR information is used to encapsulate and forward the packet(s) coming
to retrieve the next hop context between the SFF back from the SF.
and SF (e.g., the destination MAC address in case Ethernet encapsulation is use </t>
d between SFF and SF). In addition, the SFF strips the SR <t>The behavior of remembering the SR segment list occurs at the end of
information from the packet, updates the SR info the regularly defined logic. The behavior of reattaching the
rmation, and saves it to a cache indexed by the NSH Service Path Identifier (SPI segment list occurs before the SR process of forwarding the packet to
) and the Service Index (SI) decremented by 1. This saved SR the next entry in the segment list. Both behaviors are further detailed
information is used to encapsulate and forward t in <xref target="sec-5"/>.
he packet(s) coming back from the SF. </t>
</t><t> <t>When the SF receives the packet, it processes it as usual. When the
The behavior of remembering the SR segment-list SF is co-resident with a classifier, the already-processed packet may be
occurs at the end of the regularly defined logic. The behavior of reattaching th reclassified. The SF sends the packet back to the SFF. Once the SFF
e segment-list occurs before the SR process receives this packet, it extracts the SR information using the NSH SPI
of forwarding the packet to the next entry in th and SI as the index into the cache. The SFF then pushes the retrieved SR
e segment-list. Both behaviors are further detailed in section 5. header on top of the NSH header and forwards the packet to the next
</t><t> segment in the segment list. The lookup in the SFF cache might fail if
When the SF receives the packet, it processes it reclassification at the SF changed the NSH SPI and/or SI to values that
as usual. When the SF is co-resident with a classifier, the already processed p do not exist in the SFF cache. In such a case, the SFF must generate an
acket may be re-classified. The SF sends error and drop the packet.
the packet back to the SFF. Once the SFF receive </t>
s this packet, it extracts the SR information using the NSH SPI and SI as the in <t> <xref target="figure_4" format="default"/> illustrates an example of
dex into the cache. The SFF then pushes this scenario. </t>
the retrieved SR header on top of the NSH header <figure anchor="figure_4">
, and forwards the packet to the next segment in the segment-list. The lookup in <name>NSH over SR for SFC</name>
the SFF cache might fail if <artwork name="" type="" align="left" alt=""><![CDATA[
re-classification 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>
<xref target="figure_4"></xref> illustrates an ex
ample of this scenario.
<figure title="NSH over SR for SFC" anchor="figur
e_4">
<artwork>
+-----+ +-----+ +-----+ +-----+
| SF1 | | SF2 | | SF1 | | SF2 |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
| | | |
+-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+
|N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) | , |N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) |
+-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+
|F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt|
+-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+
(2) ^ | (3) | (5) ^ | (6) | (2) ^ | (3) | (5) ^ | (6) |
| | | | | | | | | | | |
| | | | | | | | | | | |
(1) | | v (4) | | v (7) (1) | | v (4) | | v (7)
+------------+ ---> +-+----+ ----> +---+--+ --> +------------+ ---> +-+----+ ----> +---+--+ -->
| | NSHoverSR | | NSHoverSR | | IP | | NSHoverSR | | NSHoverSR | | IP
| Classifier +-----------+ SFF1 +---------------------+ SFF2 | | Classifier +-----------+ SFF1 +---------------------+ SFF2 |
skipping to change at line 373 skipping to change at line 430
| S(SF1) | | S(SF2) | | F:Inner Pkt| | S(SF1) | | S(SF2) | | F:Inner Pkt|
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| S(SFF2) | | N(100,254) | | S(SFF2) | | N(100,254) |
+------------+ +------------+ +------------+ +------------+
| S(SF2) | | F:Inner Pkt| | S(SF2) | | F:Inner Pkt|
+------------+ +------------+ +------------+ +------------+
| N(100,255) | | N(100,255) |
+------------+ +------------+
| F:Inner Pkt| | F:Inner Pkt|
+------------+ +------------+
]]></artwork>
</figure>
<t>The benefits of this scheme include 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 the SR.</li>
<li>It simplifies the SFF (i.e., the SR router) by nullifying the
needs for reclassification and SR proxy.</li>
<li>SR is also used for forwarding purposes, including between SFFs.</li
>
<li>It takes advantage of SR to eliminate the NSH forwarding state in
SFFs. This applies each time strict or loose SFPs are in use.</li>
<li>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.</li>
</ul>
</section>
<section numbered="true" toc="default" anchor="sec-5">
<name>Packet Processing for SR-Based SFC</name>
<t> This section describes the End.NSH behavior (SRv6), Prefix-SID
behavior (SR-MPLS), and NSH processing logic.</t>
<section numbered="true" toc="default">
<name>SR-Based SFC (SR-MPLS) Packet Processing</name>
<t> 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.</t>
</section>
<section numbered="true" toc="default">
<name>SR-Based SFC (SRv6) Packet 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 <xref
target="RFC8754" sectionFormat="comma" section="4.3.1.1"/>, up through
line S15.</t>
<t> After S15, if S is a local End.NSH SID, then:</t>
</artwork> <sourcecode type="pseudocode"><![CDATA[
</figure> S15.1. Remove and store IPv6 and SRH headers in local cache
indexed by <NSH: service-path-id, service-index -1>
The benefits of this scheme include: S15.2. Submit the packet to the NSH FIB lookup and transmit
</t><t> to the destination associated with <NSH:
<list style="symbols"> service-path-id, service-index>
<t> ]]></sourcecode>
It is economically sound for SF v
endors to only support one unified SFC solution. The SF is unaware of the SR.
</t><t>
It simplifies the SFF (i.e., the
SR router) by nullifying the needs for re-classification and SR proxy.
</t><t>
SR is also used for forwarding pu
rposes including between SFFs.
</t><t>
It takes advantage of SR to elimi
nate the NSH forwarding state in SFFs. This applies each time strict or loose SF
Ps are in use.
</t><t>
It requires no interworking as wo
uld be the case if SR-MPLS based SFC and NSH-based SFC were deployed as independ
ent mechanisms in different
parts of the network.
</t>
</list>
</t>
</section>
<section title="Packet Processing for SR-based SFC">
<t>
This section describes the End.NSH behavior (SRv
6), Prefix SID behavior (SR-MPLS), and NSH processing logic.</t>
<section title="SR-based SFC (SR-MPLS) Packet Processing">
<t>
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-lis
t (label stack) from the packet, updates
the SR information, and saves it to a cache inde
xed by the NSH Service Path Identifier (SPI) and the Service Index (SI) decremen
ted by 1. This saved SR information is used
to re-encapsulate and forward the packet(s) comi
ng back from the SF.</t>
</section>
<section title="SR-based SFC (SRv6) Packet Processing">
<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 <xref targe
t="RFC8754"></xref> section 4.3.1.1, up through line S.15.</t>
<t>
After S.15, if S is a local End.NSH SID, then:</
t>
<t>
S15.1. Remove and store IPv6 and SRH headers in
local cache indexed by &lt;NSH: service-path-id, service-index -1&gt;</t>
<t>
S15.2. Submit the packet to the NSH FIB lookup a
nd transmit to the destination associated with &lt;NSH: service-path-id, service
-index&gt;</t>
<t>
Note: The End.NSH behavior interrupts the normal
SRH packet processing as described in <xref target="RFC8754"></xref> section 4.
3.1.1, which does not continue to S16 at this time.</t>
<t>
When a packet is returned to the SFF from the SF
, reattach the cached IPv6 and SRH headers based on the &lt;NSH: service-path-id
, service-index&gt; from the NSH header.
Then resume processing from <xref target="RFC875
4"></xref> section 4.3.1.1 with line S.16.</t>
</section>
</section>
<section anchor="Encapsulation" title="Encapsulation">
<t>
</t> <aside><t>Note: The End.NSH behavior interrupts the normal SRH packet
<section anchor="MPLS-SR" title="NSH using SR-MPLS Transport"> processing, as described in <xref target="RFC8754"
<t> sectionFormat="comma" section="4.3.1.1"/>, which does not continue
SR-MPLS instantiates Segment IDs (SIDs) as MPLS l to S16 at this time.</t></aside>
abels and therefore the segment routing header is a stack of MPLS labels. <t> When a packet is returned to the SFF from the SF, reattach the
</t><t> cached IPv6 and SRH headers based on the &lt;NSH: service-path-id,
When carrying NSH within an SR-MPLS transport, th service-index&gt; from the NSH header. Then, resume processing from
e full encapsulation headers are as illustrated in <xref target="figure_5"></xre <xref target="RFC8754" sectionFormat="comma" section="4.3.1.1"/>
f>. with line S16.</t>
</t><t> </section>
<figure align="center" title="NSH using SR-MPLS T </section>
ransport" anchor="figure_5"> <section anchor="Encapsulation" numbered="true" toc="default">
<artwork> <name>Encapsulation</name>
<t>
</t>
<section anchor="MPLS-SR" numbered="true" toc="default">
<name>NSH Using SR-MPLS Transport</name>
<t> SR-MPLS instantiates segment identifiers (SIDs) as MPLS labels;
therefore, the segment routing header is a stack of MPLS labels.
</t>
<t> When carrying an NSH within an SR-MPLS transport, the full
encapsulation headers are as illustrated in <xref target="figure_5"
format="default"/>.
</t>
<figure anchor="figure_5">
<name>NSH Using SR-MPLS Transport</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+------------------+ +------------------+
~ MPLS-SR Labels ~ ~ SR-MPLS Labels ~
+------------------+ +------------------+
| NSH Base Hdr | | NSH Base Hdr |
+------------------+ +------------------+
| Service Path Hdr | | Service Path Hdr |
+------------------+ +------------------+
~ Metadata ~ ~ Metadata ~
+------------------+ +------------------+
]]></artwork>
</figure>
<t>As described in <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 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.
</t>
<t> 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 <xref
target="RFC8596" format="default"/>.
</t>
<t> 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 <xref target="RFC8667" format="default"/> <xref
target="RFC8665" format="default"/>. It is <bcp14>RECOMMENDED</bcp14>
that a specific Prefix-SID be allocated at each node for use by the
SFC application for this purpose.
</t>
</section>
<section anchor="SRv6" numbered="true" toc="default">
<name>NSH Using SRv6 Transport</name>
<t>When carrying a NSH within an SRv6 transport, the full encapsulation
is as illustrated in <xref target="figure_6" format="default"/>.
</t>
<figure anchor="figure_6">
<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>
</figure>
<t>Encapsulation of the NSH following SRv6 is indicated by the IP protoc
ol
number for the NSH in the Next Header of the SRH.</t>
</section>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
Generic SFC-related security considerations are d
iscussed in <xref target="RFC7665" format="default"/>.</t>
<t>
NSH-specific security considerations are discusse
d in <xref target="RFC8300" format="default"/>.</t>
<t> Generic security considerations related to segment routing are
discussed in <xref target="RFC8754" sectionFormat="of" section="7"/> and
<xref target="RFC8663" sectionFormat="of" section="5"/>.
</artwork> </t>
</figure> </section>
</t><t> <section numbered="true" toc="default">
<xref target="RFC8402">As described in</xref>, th <name>Backwards Compatibility</name>
e IGP signaling extension for IGP-Prefix segment includes a flag to indicate whe <t>For SRv6/IPv6, if a processing node does not recognize the NSH, it shou
ther ld
directly connected neighbors of the node on which follow the procedures described in <xref target="RFC8200"
the prefix is attached should perform the NEXT operation or the CONTINUE operat sectionFormat="of" section="4"/>. For SR-MPLS, if a processing node does
ion when processing the SID. not recognize the NSH, it should follow the procedures laid out in <xref
When NSH is carried beneath SR-MPLS it is necessa target="RFC3031" sectionFormat="of" section="3.18"/>.
ry to terminate the NSH-based SFC at the tail-end node of the SR-MPLS label stac </t>
k. This can be achieved using </section>
either the NEXT or CONTINUE operation. <section numbered="true" toc="default">
</t><t> <name>Caching Considerations</name>
If the NEXT operation is to be used, then at the <t>The cache mechanism must remove cached entries at an appropriate time
end of the SR-MPLS path it is necessary to provide an indication to the tail-en determined by the implementation. Further, an implementation
d that NSH follows the SR-MPLS label <bcp14>MAY</bcp14> allow network operators to set the said time value.
stack as described by <xref target="RFC8596"></x In the case where a packet arriving from an SF does not have a matching
ref>. cached entry, the SFF <bcp14>SHOULD</bcp14> log this event and
</t><t> <bcp14>MUST</bcp14> drop the packet. </t>
If the CONTINUE operation is to be used, this is </section>
the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore it is necessary <section numbered="true" toc="default">
to ensure that the penultimate hop node <name>MTU Considerations</name>
does not pop the top label of the SR-MPLS label <t>Aligned with <xref target="RFC8300" sectionFormat="of" section="5"/>
stack and thereby expose NSH to the wrong SFF. This is realized by setting No-PH and <xref target="RFC8754" sectionFormat="of" section="5.3"/>, it is
P flag in <bcp14>RECOMMENDED</bcp14> for network operators to increase the
Prefix-SID Sub-TLV <xref target="RFC8667"></xref underlying MTU so that SR/NSH traffic is forwarded within an SR domain
>, <xref target="RFC8665"></xref>. It is RECOMMENDED that a specific prefix-SID without fragmentation.
be allocated at each node for use
by the SFC application for this purpose.
</t>
</section>
<section anchor="SRv6" title="NSH using SRv6 Transport">
<t>When carrying NSH within an SRv6 transport the full en
capsulation is as illustrated in <xref target="figure_6"></xref>.
</t><t>
<figure align="center" title="NSH using SRv6 Tran
sport" anchor="figure_6">
<artwork>
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>
</figure>
</t>
<t>Encapsulation of NSH following SRv6 is indicated by th
e IP protocol number for NSH in the Next Header of the SRH.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Generic SFC-related security considerations are d
iscussed in <xref target="RFC7665"></xref>.</t>
<t>
NSH-specific security considerations are discusse
d in <xref target="RFC8300"></xref>.</t>
<t>
Generic segment routing related security conside
rations are discussed in section 7 of <xref target="RFC8754"></xref> and section
5 of <xref target="RFC8663"></xref>.
</t>
</section>
<section title="Backwards Compatibility">
<t>For SRv6/IPv6, if a processing node does not recogniz
e NSH it should follow the procedures described in section 4 of <xref target="RF
C8200"></xref>. For SR-MPLS, if a
processing node does not recognize NSH it should foll
ow the procedures laid out in section 3.18 of <xref target="RFC3031"></xref>.
</t>
</section>
<section title="Caching Considerations">
<t>The cache mechanism must remove cached entries at an appropri
ate time determined by the implementation. Further, an implementation MAY allow
network operators to set the said time value.
In the case a packet arriving from an SF does not have a matc
hing cached entry, the SFF SHOULD log this event, and MUST drop the packet. </t>
</section>
<section title="MTU Considerations"> </t>
<t> </section>
Aligned with Section 5 of [RFC8300] and Section <section anchor="IANA" numbered="true" toc="default">
5.3 of <xref target="RFC8754"></xref>, it is RECOMMENDED for network operators t <name>IANA Considerations</name>
o increase the underlying MTU so that SR/NSH traffic is forwarded <section anchor="NSHPROTO" numbered="true" toc="default">
within an SR domain without fragmentation. <name>Protocol Number for the NSH</name>
<t>IANA has assigned protocol number 145 for the NSH
<xref target="RFC8300" format="default"/> in the "Assigned Internet
Protocol Numbers" registry
<eref target="https://www.iana.org/assignments/protocol-numbers/" bracket
s="angle"/>.</t>
<table anchor="iana-1" align="center">
<name>Assigned Internet Protocol Numbers Registry</name>
<thead>
<tr>
<th>Decimal</th>
<th>Keyword</th>
<th>Protocol</th>
<th>IPv6 Extension Header</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>145</td>
<td>NSH</td>
<td>Network Service Header</td>
<td>N</td>
<td>RFC 9491</td>
</tr>
</tbody>
</table>
</t> </section>
</section> <section anchor="NSHEPB" numbered="true" toc="default">
<name>SRv6 Endpoint Behavior for the NSH</name>
<section anchor="IANA" title="IANA Considerations"> <t>IANA has allocated the following value in the "SRv6 Endpoint
Behaviors" subregistry under the "Segment Routing" registry:</t>
<section anchor="NSHPROTO" title="Protocol Number for NSH"> <table anchor="iana-2" align="center">
<figure><artwork>IANA is requested to assign a protocol number TBA1 for t <name>SRv6 Endpoint Behaviors Subregistry</name>
he NSH [RFC8300] from the <thead>
"Assigned Internet Protocol Numbers" registry available at <tr>
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml <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 - NSH Segment</td>
<td>RFC 9491</td>
<td>IETF</td>
</tr>
</tbody>
</table>
+---------+---------+--------------+---------------+----------------+ </section>
| Decimal | Keyword | Protocol | IPv6 | Reference | </section>
| | | | Extension | |
| | | | Header | |
+---------+---------+--------------+---------------+----------------+
| TBA1 | NSH | Network | N | [This Document]|
| | | Service | | |
| | | Header | | |
+---------+---------+--------------+---------------+----------------+
</artwork></figure>
</section>
<section anchor="NSHEPB" title="SRv6 Endpoint Behavior for NSH">
<figure><artwork>This I-D requests IANA to allocate, within the "SRv6 End
point Behaviors"
sub-registry belonging to the top-level "Segment-routing with IPv6 data
plane (SRv6) Parameters" registry, the following allocations:
Value Description Reference </middle>
-------------------------------------------------------------- <back>
TBA2 End.NSH - NSH Segment [This.ID]
</artwork></figure> <displayreference target="I-D.ietf-spring-sr-service-programming" to="SERVICE-PR
</section> OGRAMMING"/>
</section>
<section anchor="Contributors" title="Contributing Authors"> <references>
<t><figure><artwork> <name>References</name>
The following co-authors, along with their respective affiliations at <references>
the time of publication, provided valuable inputs and text contributions <name>Normative References</name>
to this document. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
663.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
665.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
667.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
031.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
498.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
665.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
596.xml"/>
Mohamed Boucadair <reference anchor="I-D.ietf-spring-sr-service-programming">
Orange <front>
mohamed.boucadair@orange.com <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&amp;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-programmin
g-08"/>
</reference>
</references>
</references>
Joel Halpern <section anchor="Contributors" numbered="false" toc="default">
Ericsson <name>Contributors</name>
joel.halpern@ericsson.com <t>The following coauthors provided valuable inputs and text
contributions to this document.</t>
Syed Hassan <contact fullname="Mohamed Boucadair">
Cisco System, inc. <organization>Orange</organization>
shassan@cisco.com <address>
<email>mohamed.boucadair@orange.com</email>
</address>
</contact>
Wim Henderickx <contact fullname="Joel Halpern">
Nokia <organization>Ericsson</organization>
wim.henderickx@nokia.com <address>
<email>joel.halpern@ericsson.com</email>
</address>
</contact>
Haoyu Song <contact fullname="Syed Hassan">
Futurewei Technologies <organization>Cisco System, inc.</organization>
haoyu.song@futurewei.com <address>
</artwork></figure></t> <email>shassan@cisco.com</email>
</section> </address>
</contact>
</middle> <contact fullname="Wim Henderickx">
<organization>Nokia</organization>
<address>
<email>wim.henderickx@nokia.com</email>
</address>
</contact>
<back> <contact fullname="Haoyu Song">
<references title="Normative References"> <organization>Futurewei Technologies</organization>
&RFC2119; <address>
&RFC8174; <email>haoyu.song@futurewei.com</email>
&RFC8402; </address>
&NSH; </contact>
&RFC8754;
&RFC8660;
&RFC8663;
&RFC8665;
&RFC8667;
&RFC3031;
&RFC8200;
</references>
<references title="Informative References">
&SFCSTATE;
&SFCARCH;
&RFC8596;
&SRSPGM;
</references> </section>
</back>
</back>
</rfc> </rfc>
 End of changes. 35 change blocks. 
726 lines changed or deleted 701 lines changed or added

This html diff was produced by rfcdiff 1.48.