rfc8979xml2.original.xml   rfc8979.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-sfc-serviceid-header-14"
ipr="trust200902">
<front>
<title abbrev="NSH Subscriber/Performance Policy TLVs">Service Function
Chaining: Subscriber and Performance Policy Identification Variable-Length
Network Service Header (NSH) Context Headers</title>
<author fullname="Behcet Sarikaya" initials="B.S." surname="Sarikaya"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization></organization>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sfc-servicei
d-header-14"
number="8979" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" ca
tegory="std"
consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sor
tRefs="true"
version="3">
<front>
<title abbrev="Subscriber/Performance Policy Headers">Subscriber and Perform
ance Policy Identifier Context Headers in the Network Service Header (NSH)</titl
e>
<seriesInfo name="RFC" value="8979"/>
<author fullname="Behcet Sarikaya" initials="B." surname="Sarikaya">
<organization/>
<address> <address>
<postal> <postal>
<street></street> <street/>
<street/>
<street></street> <city/>
<region/>
<city></city> <code/>
<region></region>
<code></code>
</postal> </postal>
<email>sarikaya@ieee.org</email> <email>sarikaya@ieee.org</email>
</address> </address>
</author> </author>
<author fullname="Dirk von Hugo" initials="D." surname="von Hugo">
<author fullname="Dirk von Hugo" initials="D.H." surname="von Hugo">
<organization abbrev="Deutsche Telekom">Deutsche Telekom</organization> <organization abbrev="Deutsche Telekom">Deutsche Telekom</organization>
<address> <address>
<postal> <postal>
<street>Deutsche-Telekom-Allee 9</street> <street>Deutsche-Telekom-Allee 9</street>
<city>Darmstadt</city>
<city>D-64295 Darmstadt</city> <code>D-64295</code>
<code></code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone/>
<phone></phone>
<email>Dirk.von-Hugo@telekom.de</email> <email>Dirk.von-Hugo@telekom.de</email>
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<street/>
<street></street> <city>Rennes</city>
<region/>
<city>Rennes 3500</city> <code>3500</code>
<region></region>
<code></code>
<country>France</country> <country>France</country>
</postal> </postal>
<phone/>
<phone></phone>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<date year="2021" month="February" />
<date year="2020" />
<workgroup>SFC</workgroup> <workgroup>SFC</workgroup>
<keyword>subscriber policy</keyword> <keyword>subscriber policy</keyword>
<keyword>policy enforcement</keyword> <keyword>policy enforcement</keyword>
<keyword>subscriber</keyword> <keyword>subscriber</keyword>
<keyword>policy</keyword> <keyword>policy</keyword>
<keyword>quota</keyword> <keyword>quota</keyword>
<keyword>identification</keyword> <keyword>identification</keyword>
<keyword>implicit identification</keyword> <keyword>implicit identification</keyword>
<keyword>service chain</keyword> <keyword>service chain</keyword>
<keyword>service function chain</keyword> <keyword>service function chain</keyword>
<keyword>sfc</keyword> <keyword>sfc</keyword>
<keyword>SFP</keyword> <keyword>SFP</keyword>
<keyword>service function path</keyword> <keyword>service function path</keyword>
<keyword>classification</keyword> <keyword>classification</keyword>
<keyword>5G</keyword> <keyword>5G</keyword>
<keyword>traffic steering</keyword> <keyword>traffic steering</keyword>
<abstract> <abstract>
<t>This document defines two Variable-Length Context Headers that can be <t>This document defines the Subscriber and Performance Policy Identifier
carried in the Network Service Header: the Subscriber and Performance Context Headers. These Variable-Length Context Headers can be
Policy Identifiers. These Context Headers are used to inform Service carried in the Network Service Header (NSH) and are used to inform Service
Functions of subscriber- and performance-related information for the Functions (SFs) of subscriber- and performance-related information for the
sake of policy enforcement and appropriate service function chaining sake of policy enforcement and appropriate Service Function Chaining (SFC)
operations. The structure of each Context Header, and their use and operations. The structure of each Context Header and their use and
processing by NSH-aware nodes, are described.</t> processing by NSH-aware nodes are described.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>This document discusses how to inform Service Functions (SFs) <xref <name>Introduction</name>
target="RFC7665"></xref> about subscriber and service policy <t>This document discusses how to inform Service Functions (SFs) <xref tar
information, when required for the sake of policy enforcement within a get="RFC7665" format="default"/> about subscriber and service policy
information when required for the sake of policy enforcement within a
single administrative domain. In particular, subscriber-related single administrative domain. In particular, subscriber-related
information may be required to enforce subscriber-specific SFC-based information may be required to enforce subscriber-specific SFC-based
traffic policies. However, the information carried in packets may not be traffic policies. However, the information carried in packets may not be
sufficient to unambiguously identify a subscriber. This document fills sufficient to unambiguously identify a subscriber.
this void by specifying a new Network Service Header (NSH) <xref
target="RFC8300"></xref> Context Header to convey and disseminate such This document fills
this void by specifying a new Network Service Header (NSH) <xref target="R
FC8300" format="default"/> Context Header to convey and disseminate such
information within the boundaries of a single administrative domain. As information within the boundaries of a single administrative domain. As
discussed in <xref target="solutions"></xref>, the use of obfuscated and discussed in <xref target="solutions" format="default"/>, the use of obfus cated and
non-persistent identifiers is recommended.</t> non-persistent identifiers is recommended.</t>
<t>Also, traffic steering by means of SFC may be driven, for example, by <t>Also, traffic steering by means of SFC may be driven, for example, by
QoS (Quality of Service) considerations. Typically, QoS information may Quality of Service (QoS) considerations. Typically, QoS information may
serve as an input for the computation, establishment, and selection of serve as an input for the computation, establishment, and selection of
the Service Function Path (SFP). Furthermore, the dynamic structuring of the Service Function Path (SFP). Furthermore, the dynamic structuring of
service function chains and their subsequent SFPs may be conditioned by Service Function Chains and their subsequent SFPs may be conditioned by
QoS requirements that will affect SF instance(s) identification, QoS requirements that will affect the identification,
location, and sequencing. Hence, the need arises to provide downstream location, and sequencing of SF instances.
Hence, the need arises to provide downstream
SFs with a performance policy identifier in order for them to SFs with a performance policy identifier in order for them to
appropriately meet the QoS service requirements. This document also appropriately meet the QoS requirements. This document also
specifies a new NSH Context Header (<xref target="sol2"></xref>) to specifies a new NSH Context Header (<xref target="sol2" format="default"/>
) to
convey such policy identifiers.</t> convey such policy identifiers.</t>
<t>The context information defined in this document can be applicable in <t>The context information defined in this document can be applicable in
the context of mobile networks (particularly, in the 3GPP defined (S)Gi the context of mobile networks (particularly in the 3GPP-defined (S)Gi
Interface) <xref target="I-D.ietf-sfc-use-case-mobility"></xref>. interface) <xref target="I-D.ietf-sfc-use-case-mobility" format="default"/
>.
Typically, because of the widespread use of private IPv4 addresses in Typically, because of the widespread use of private IPv4 addresses in
those networks, if the SFs to be invoked are located after a NAT those networks, if the SFs to be invoked are located after a NAT
function, the identification based on the internal IPv4 address is not function, the identification based on the internal IPv4 address is not
possible once the NAT has been crossed. NAT functionality can reside in possible once the NAT has been crossed. NAT functionality can reside in
a distinct node. For a 4G 3GPP network, that node can be the Packet Data a distinct node. For a 4G 3GPP network, that node can be the Packet Data
Network (PDN) Gateway (PGW) as specified in <xref Network (PDN) Gateway (PGW) as specified in <xref target="TS23401" format=
target="TS23401"></xref>. For a 5G 3GPP network, it can be the User "default"/>. For a 5G 3GPP network, it can be the User
Plane Function (UPF) facing the external Data Network (DN) <xref Plane Function (UPF) facing the external Data Network (DN) <xref target="T
target="TS23501"></xref>. As such, a mechanism to pass the internal S23501" format="default"/>. As such, a mechanism to pass the internal
information past the NAT boundary may optimise packet traversal within information past the NAT boundary may optimize packet traversal within
an SFC-enabled mobile network domain. Furthermore, some SFs that are not an SFC-enabled mobile network domain. Furthermore, some SFs that are not
enabled on the PGW/UPF may require a subscriber identifier to properly enabled on the PGW/UPF may require a subscriber identifier to properly
operate (see, for example, those listed in <xref operate (see, for example, those listed in <xref target="RFC8371" format="
target="RFC8371"></xref>). It is outside the scope of this document to default"/>). It is outside the scope of this document to
include a comprehensive list of deployments which may make use of the include a comprehensive list of deployments that may make use of the
Context Headers defined in the document.</t> Context Headers defined in the document.</t>
<t>Since subscriber identifiers are distinct from those used to identify <t>Since subscriber identifiers are distinct from those used to identify
a performance policy and given that multiple policies may be associated a performance policy and given that multiple policies may be associated
with a single subscriber within a service function chain, these with a single subscriber within a Service Function Chain, these
identifiers are carried in distinct Context Headers rather than identifiers are carried in distinct Context Headers rather than
multiplexing them in one single Context Header. This approach avoids a being multiplexed in one single Context Header. This approach avoids a
requirement for additional internal structure in the Context Headers to requirement for additional internal structure in the Context Headers to
specify whether an identifier refers to a subscriber or to a policy.</t> specify whether an identifier refers to a subscriber or to a policy.</t>
<t>This document does not make any assumptions about the structure of
<t>This document does not make any assumption about the structure of
subscriber or performance policy identifiers; each such identifier is subscriber or performance policy identifiers; each such identifier is
treated as an opaque value. The semantics and validation of these treated as an opaque value. The semantics and validation of these
identifiers are policies local to each SFC-enabled domain. This document identifiers are policies local to each SFC-enabled domain. This document
focuses on the data plane behaviour. Control plane considerations are focuses on the data plane behavior. Control plane considerations are
out of the scope.</t> out of the scope.</t>
<t>This document adheres to the SFC data plane architecture defined in <t>This document adheres to the SFC data plane architecture defined in
<xref target="RFC7665"></xref>. This document assumes the reader is <xref target="RFC7665" format="default"/>. This document assumes the reade
familiar with <xref target="RFC8300"></xref>.</t> r is
familiar with <xref target="RFC8300" format="default"/>.</t>
<t>This document assumes the NSH is used exclusively within a single <t>This document assumes the NSH is used exclusively within a single
administrative domain. This document follows the recommendations in administrative domain. This document follows the recommendations in
<xref target="RFC8300"></xref> for handling the Context Headers at both <xref target="RFC8300" format="default"/> for handling the Context Headers at both
ingress and egress SFC boundary nodes (i.e., to strip the entire NSH, ingress and egress SFC boundary nodes (i.e., to strip the entire NSH,
including Context Headers). Revealing any subscriber-related information including Context Headers). Revealing any subscriber-related information
to parties outside the SFC-enabled domain is avoided by design. to parties outside the SFC-enabled domain is avoided by design.
Accordingly, the scope for privacy breaches and user tracking is limited Accordingly, the scope for privacy breaches and user tracking is limited
to within the SFC-enabled domain where the NSH is used. It is assumed to within the SFC-enabled domain where the NSH is used. It is assumed
that appropriate mechanisms to monitor and audit an SFC-enabled domain that appropriate mechanisms to monitor and audit an SFC-enabled domain
to detect misbehavior and to deter misuse are in place.</t> to detect misbehavior and to deter misuse are in place.</t>
<t>MTU considerations are discussed in <xref target="MTU" format="default"
<t>MTU considerations are discussed in <xref target="MTU"></xref>.</t> />.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Conventions and Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 title="Conventions and Terminology"> <t>The reader should be familiar with the terms defined in <xref target="R
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", FC7665" format="default"/>.</t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>"SFC Control Element" refers to a logical entity that instructs one or
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and
only when, they appear in all capitals, as shown here.</t>
<t>The reader should be familiar with the terms defined in <xref
target="RFC7665"></xref>.</t>
<t>SFC Control Element refers to a logical entity that instructs one or
more SFC data plane functional elements on how to process packets within more SFC data plane functional elements on how to process packets within
an SFC-enabled domain.</t> an SFC-enabled domain.</t>
</section> </section>
<section anchor="solutions" numbered="true" toc="default">
<section anchor="solutions" <name>Subscriber Identifier NSH Variable-Length Context Header</name>
title="Subscriber Identification NSH Variable-Length Context Header <t>Subscriber Identifier is defined as an optional Variable-Length NSH
"> Context Header. Its structure is shown in <xref target="arch7" format="def
<t>Subscriber Identifier is defined as an optional variable-length NSH ault"/>.
Context Header. Its structure is shown in <xref target="arch7"></xref>. </t>
<figure anchor="arch7" <figure anchor="arch7">
title="Subscriber Identifier Variable-Length Context Header"> <name>Subscriber Identifier Variable-Length Context Header</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length | | Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Subscriber Identifier ~ ~ Subscriber Identifier ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The fields are described as follows:</t>
<t>The description of the fields is as follows:</t> <dl spacing="normal">
<dt>Metadata Class:</dt><dd><bcp14>MUST</bcp14> be set to 0x0 <xref targ
<t><list style="symbols"> et="RFC8300" format="default"/>.</dd>
<t>Metadata Class: MUST be set to 0x0 <xref <dt>Type:</dt><dd>0x00 (see <xref target="IANA" format="default"/>).</dd
target="RFC8300"></xref>.</t> >
<dt>U bit:</dt><dd>Unassigned bit (see <xref target="RFC8300" sectionFor
<t>Type: TBD1 (See <xref target="IANA"></xref>).</t> mat="of" section="2.5.1"/>).</dd>
<dt>Length:</dt><dd>Indicates the length of the Subscriber Identifier, i
<t>U bit: Unassigned bit (see Section 2.5.1 of <xref n
target="RFC8300"></xref>).</t> bytes (see <xref target="RFC8300" sectionFormat="of" section="2.5.1"/>
).</dd>
<t>Length: Indicates the length of the Subscriber Identifier, in
bytes (see Section 2.5.1 of <xref target="RFC8300"></xref>).</t>
<t>Subscriber Identifier: Carries an opaque local identifier that is <dt>Subscriber Identifier:</dt><dd><t>Carries an opaque local identifi
assigned to a subscriber by a network operator.<vspace er that is
blankLines="1" />While this document does not specify an internal assigned to a subscriber by a network operator.</t>
<t>While this document does not specify an internal
structure for these identifiers, it also does not provide any structure for these identifiers, it also does not provide any
cryptographic protection for them; any internal structure to the cryptographic protection for them; any internal structure to the
identifier values chosen will thus be visible on the wire if no identifier values chosen will thus be visible on the wire if no
secure transport encapsulation is used. Accordingly, in alignment secure transport encapsulation is used. Accordingly, in alignment
with Section 8.2.2 of <xref target="RFC8300"></xref>, identifier with <xref target="RFC8300" sectionFormat="of" section="8.2.2"/>, iden
values SHOULD be obfuscated.</t> tifier
</list></t> values <bcp14>SHOULD</bcp14> be obfuscated.</t>
</dd>
<t>The Subscriber Identifier Context Header is used by service functions </dl>
<t>The Subscriber Identifier Context Header is used by SFs
to enforce per-subscriber policies (e.g., resource quota, customized to enforce per-subscriber policies (e.g., resource quota, customized
filtering profile, accounting). To that aim, network operators may rely filtering profile, accounting). To that aim, network operators may rely
on identifiers that are generated from those used in legacy deployments on identifiers that are generated from those used in legacy deployments
(e.g., Section 3.3 of <xref (e.g., <xref target="I-D.ietf-sfc-use-case-mobility" sectionFormat="of" se
target="I-D.ietf-sfc-use-case-mobility"></xref>). Alternatively, network ction="3.3"/>). Alternatively, network
operators may use identifiers that are associated with customized policy operators may use identifiers that are associated with customized policy
profiles that are preconfigured on SFs using an out of band mechanism. profiles that are preconfigured on SFs using an out-of-band mechanism.
Such mechanism can be used to rotate the identifiers allowing thus for Such a mechanism can be used to rotate the identifiers, thus allowing for
better unlinkability (Section 3.2 of <xref target="RFC6973"></xref>). better unlinkability (<xref target="RFC6973" sectionFormat="of" section="3
.2"/>).
Such alternative methods may be suboptimal (e.g., scalability issues Such alternative methods may be suboptimal (e.g., scalability issues
induced by maintaining and processing finer granular profiles) or induced by maintaining and processing finer granular profiles) or
inadequate to provide some per-subscriber policies. The assessment of inadequate for providing some per-subscriber policies. The assessment of
whether a method for defining a subscriber identifier provides the whether a method for defining a subscriber identifier provides the
required functionality and whether required functionality and whether
it is compatible with the capabilities of the SFs to it is compatible with the capabilities of the SFs at
the intended performance level, is deployment specific.</t> the intended performance level is deployment specific.</t>
<t>The classifier and NSH-aware SFs <bcp14>MAY</bcp14> inject a Subscriber
<t>The classifier and NSH-aware SFs MAY inject a Subscriber Identifier Identifier
Context Header as a function of a local policy. This local policy should Context Header as a function of a local policy. This local policy should
indicate the SFP(s) for which the Subscriber Identifier Context Header indicate the SFP(s) for which the Subscriber Identifier Context Header
will be added. In order to prevent interoperability issues, the type and will be added. In order to prevent interoperability issues, the type and
format of the identifiers to be injected in a Subscriber Identifier format of the identifiers to be injected in a Subscriber Identifier
Context Header should be configured to nodes authorized to inject and Context Header should be configured to nodes authorized to inject and
consume such headers. For example, a node can be instructed to insert consume such headers. For example, a node can be instructed to insert
such data following a type/set scheme (e.g., node X should inject such data following a type/set scheme (e.g., node X should inject
subscriber ID type Y). Other schemes may be envisaged.</t> subscriber ID type Y). Other schemes may be envisaged.</t>
<t>Failures to inject such headers should be logged locally, while a
<t>Failures to inject such headers should be logged locally while a
notification alarm may be sent to a Control Element. The details of notification alarm may be sent to a Control Element. The details of
sending notification alarms (i.e., the parameters affecting the sending notification alarms (i.e., the parameters affecting the
transmission of the notification alarms) might depend on the nature of transmission of the notification alarms) might depend on the nature of
the information in the Context Header. Parameters for sending alarms, the information in the Context Header. Parameters for sending alarms,
such as frequency, thresholds, and content of the alarm, should be such as frequency, thresholds, and content of the alarm, should be
configurable.</t> configurable.</t>
<t>The default behavior of intermediary NSH-aware nodes is to preserve <t>The default behavior of intermediary NSH-aware nodes is to preserve
Subscriber Identifier Context Headers (i.e., the information can be Subscriber Identifier Context Headers (i.e., the information can be
passed to next hop NSH-aware nodes), but local policy may require an passed to next-hop NSH-aware nodes), but local policy may require an
intermediary NSH-aware node to strip a Subscriber Identifier Context intermediary NSH-aware node to strip a Subscriber Identifier Context
Header after processing it.</t> Header after processing it.</t>
<t>NSH-aware SFs <bcp14>MUST</bcp14> ignore Context Headers carrying unkno
<t>NSH-aware SFs MUST ignore Context Headers carrying unknown subscriber wn subscriber
identifiers.</t> identifiers.</t>
<t>Local policies at NSH-aware SFs may require running additional <t>Local policies at NSH-aware SFs may require running additional
validation checks on the content of these Context Headers (e.g., accept validation checks on the content of these Context Headers (e.g., accepting
only some lengths or types). These policies may also indicate the only some lengths or types). These policies may also indicate the
behavior to be followed by an NSH-aware SF if the validation checks fail behavior to be followed by an NSH-aware SF if the validation checks fail
(e.g., remove the Context Header from the packet). These additional (e.g., removing the Context Header from the packet). These additional
validation checks are deployment-specific. If validation checks fail on validation checks are deployment specific. If validation checks fail on
a Subscriber Identifier Context Header, an NSH-aware SF MUST ignore that a Subscriber Identifier Context Header, an NSH-aware SF <bcp14>MUST</bcp14
Context Header. The event should be logged locally while a notification > ignore that
Context Header. The event should be logged locally, while a notification
alarm may be sent to a Control Element if the NSH-aware SF is instructed alarm may be sent to a Control Element if the NSH-aware SF is instructed
to do so. For example, an SF will discard Subscriber Identifier to do so. For example, an SF will discard Subscriber Identifier
Context Headers conveying identifiers in all formats different from the Context Headers conveying identifiers in all formats that are different fr om the
one the SF is instructed to expect.</t> one the SF is instructed to expect.</t>
<t>Multiple Subscriber Identifier Context Headers <bcp14>MAY</bcp14> be pr
<t>Multiple Subscriber Identifier Context Headers MAY be present in the esent in the
NSH, each carrying a distinct opaque value but all pointing to the same NSH, each carrying a distinct opaque value but all pointing to the same
subscriber. This may be required, e.g., by policy enforcement mechanisms subscriber. This may be required, e.g., by policy enforcement mechanisms
in a mobile network where some SFs rely on IP addresses as subscriber in a mobile network where some SFs rely on IP addresses as subscriber
Identifiers, while others use non-IP specific identifiers such as those identifiers, while others use non-IP-specific identifiers such as those
listed in <xref target="RFC8371"></xref> and Section 3.3.2 of <xref listed in <xref target="RFC8371" format="default"/> and <xref target="I-D.
target="I-D.ietf-sfc-use-case-mobility"></xref>. When multiple ietf-sfc-use-case-mobility" sectionFormat="of" section="3.3.2"/>. When multiple
subscriber identifier Context Headers are present and an SF is Subscriber Identifier Context Headers are present and an SF is
instructed to strip the Subscriber Identifier Context Header, that SF instructed to strip the Subscriber Identifier Context Header, that SF
MUST remove all Subscriber Identifier Context Headers.</t> <bcp14>MUST</bcp14> remove all Subscriber Identifier Context Headers.</t>
</section> </section>
<section anchor="sol2" numbered="true" toc="default">
<section anchor="sol2" <name>Performance Policy Identifier NSH Variable-Length Context Headers</n
title="Performance Policy Identification NSH Variable-Length Contex ame>
t Headers">
<t>Dedicated service-specific performance identifiers are defined to <t>Dedicated service-specific performance identifiers are defined to
differentiate between services that require specific treatment in order differentiate between services that require specific treatment in order
to exhibit a performance characterized by, e.g., ultra-low latency (ULL) to exhibit a performance characterized by, e.g., ultra-low latency (ULL)
or ultra-high reliability (UHR). Other policies can be considered when or ultra-high reliability (UHR). Other policies can be considered when
instantiating a service function chain within an SFC-enabled domain. instantiating a Service Function Chain within an SFC-enabled domain.
They are conveyed in the Performance Policy Identifier Context They are conveyed in the Performance Policy Identifier Context
Header.</t> Header.</t>
<t>The Performance Policy Identifier Context Header is inserted in an <t>The Performance Policy Identifier Context Header is inserted in an NSH
NSH packet so that downstream NSH-aware nodes can make use of the packet so that downstream NSH-aware nodes can make use of the performance inform
performance information for proper distributed SFC path selection, SF ation for proper selection of suitably distributed SFC paths, SF instances, or a
instance selection, or policy selection at SFs. Note that the use of the pplicable policy at SFs. Note that the use of the performance policy identifier
Performance Policy Identifier is not helpful if the path computation is is not helpful if the path computation is
centralized and a strict SFP is presented as local policy to SF centralized and a strict SFP is presented as local policy to SF
Forwarders (SFFs).</t> Forwarders (SFFs).</t>
<t>The Performance Policy Identifier Context Header allows for the distrib
<t>The Performance Policy Identifier allows for the distributed uted
enforcement of a per-service policy such as requiring enforcement of a per-service policy such as requiring
a service function path to an SFP to
only include specific SFs instances (e.g., SFs located within the same only include specific SF instances (e.g., SFs located within the same
DC or those that are exposing the shortest delay from an SFF). Details Data Center (DC) or those that are exposing the shortest delay from an SFF
of this process are implementation-specific. For illustration purposes, ). Details
of this process are implementation specific. For illustration purposes,
an SFF may retrieve the details of usable SFs based upon the an SFF may retrieve the details of usable SFs based upon the
corresponding performance policy identifier. Typical criteria for corresponding performance policy identifier. Typical criteria for
instantiating specific SFs include location, performance, or proximity instantiating specific SFs include location, performance, or proximity
considerations. For the particular case of UHR services, the stand-by considerations. For the particular case of UHR services, the standby
operation of back-up capacity or the presence of SFs deployed in operation of backup capacity or the presence of SFs deployed in
multiple instances may be requested.</t> multiple instances may be requested.</t>
<t>In an environment characterized by frequent changes of link and path
<t>In an environment characterised by frequent changes of link and path behavior (for example, due to variable load or availability caused by
behaviour, for example due to variable load or availability caused by propagation conditions on a wireless link), the SFP may have to be
propagation conditions on a wireless link, the SFP may have to be
adapted dynamically by on-the-move SFC path and SF instance adapted dynamically by on-the-move SFC path and SF instance
selection.</t> selection.</t>
<t>Performance Policy Identifier is defined as an optional Variable-Length
<t>Performance Policy Identifier is defined as an optional variable Context Header. Its structure is shown in <xref target="arch9" format="default"
length Context Header. Its structure is shown in <xref />.</t>
target="arch9"></xref>.</t>
<t>The default behavior of intermediary NSH-aware nodes is to preserve <t>The default behavior of intermediary NSH-aware nodes is to preserve
such Context Headers (i.e., the information can be passed to next hop such Context Headers (i.e., the information can be passed to next-hop
NSH-aware nodes), but local policy may require an intermediary NSH-aware NSH-aware nodes), but local policy may require an intermediary NSH-aware
node to strip one after processing it.</t> node to strip one Context Header after processing it.</t>
<t>Multiple Performance Policy Identifier Context Headers <bcp14>MAY</bcp1
<t>Multiple Performance Policy Identifier Context Headers MAY be present 4> be present
in the NSH, each carrying an opaque value for a distinct policy that in the NSH, each carrying an opaque value for a distinct policy that
need to be enforced for a flow. Supplying conflicting policies may needs to be enforced for a flow. Supplying conflicting policies may
complicate the SFP computation and SF instance location. Corresponding complicate the SFP computation and SF instance location. Corresponding
rules to detect conflicting policies may be provided as a local policy rules to detect conflicting policies may be provided as a local policy
to the NSH-aware nodes. When such conflict is detected by an NSH-aware to the NSH-aware nodes. When such conflict is detected by an NSH-aware
node, the default behavior of the node is to discard the packet and send node, the default behavior of the node is to discard the packet and send
a notification alarm to a Control Element.</t> a notification alarm to a Control Element.</t>
<figure anchor="arch9">
<figure anchor="arch9" <name>Performance Policy Identifier Variable-Length Context Header</name
title="Performance Policy Identifier Variable-Length Context Heade >
r"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length | | Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Performance Policy Identifier ~ ~ Performance Policy Identifier ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The fields are described as follows:</t>
<t>The description of the fields is as follows:<list style="symbols"> <dl spacing="normal">
<t>Metadata Class: MUST be set to 0x0 <xref <dt>Metadata Class:</dt><dd><bcp14>MUST</bcp14> be set to 0x0 <xref targ
target="RFC8300"></xref>.</t> et="RFC8300" format="default"/>.</dd>
<dt>Type:</dt><dd>0x01 (see <xref target="IANA" format="default"/>).</dd
<t>Type: TBD2 (See <xref target="IANA"></xref>).</t> >
<dt>U bit:</dt><dd>Unassigned bit (see <xref target="RFC8300" sectionFor
<t>U bit: Unassigned bit (see Section 2.5.1 of <xref mat="of" section="2.5.1"/>).</dd>
target="RFC8300"></xref>).</t> <dt>Length:</dt><dd>Indicates the length of the Performance Policy
Identifier, in bytes (see <xref target="RFC8300" sectionFormat="of" se
<t>Length: Indicates the length of the Performance Policy ction="2.5.1"/>).</dd>
Identifier, in bytes (see Section 2.5.1 of <xref <dt>Performance Policy Identifier:</dt><dd>Represents an opaque value
target="RFC8300"></xref>).</t> pointing to a specific performance policy to be enforced. The
structure and semantics of this field are deployment specific.</dd>
<t>Performance Policy Identifier: Represents an opaque value </dl>
pointing to specific performance policy to be enforced. The
structure and semantics of this field are deployment-specific.</t>
</list></t>
</section> </section>
<section anchor="MTU" numbered="true" toc="default">
<section anchor="MTU" title="MTU Considerations"> <name>MTU Considerations</name>
<t>As discussed in Section 5.6 of <xref target="RFC7665"></xref>, the <t>As discussed in <xref target="RFC7665" sectionFormat="of" section="5.6"
/>, the
SFC architecture prescribes that additional information be added to SFC architecture prescribes that additional information be added to
packets to: <list style="symbols"> packets to: </t>
<t>Identify SFPs: this is typically the NSH Base Header (Section 2.2 <ul spacing="normal">
of <xref target="RFC8300"></xref>) and Service Path Header (Section <li>Identify SFPs. This is typically the NSH Base Header (<xref target="
2.3 of <xref target="RFC8300"></xref>).</t> RFC8300" sectionFormat="of" section="2.2"/>) and Service Path Header (<xref targ
et="RFC8300" sectionFormat="of" section="2.3"/>).</li>
<t>Carry metadata such those defined in Sections <xref <li>Carry metadata such those defined in Sections <xref format="counter"
format="counter" target="solutions"></xref> and <xref target="solutions"/> and <xref format="counter" target="sol2"/>.</li>
format="counter" target="sol2"></xref>.</t> <li>Steer the traffic along the SFPs: This is realized by means of trans
port encapsulation.</li>
<t>Steer the traffic along the SFPs: transport encapsulation.</t> </ul>
</list></t>
<t>This added information increases the size of the packet to be carried <t>This added information increases the size of the packet to be carried
along an SFP.</t> along an SFP.</t>
<t>Aligned with <xref target="RFC8300" sectionFormat="of" section="5"/>, i
<t>Aligned with Section 5 of <xref target="RFC8300"></xref>, it is t is
RECOMMENDED for network operators to increase the underlying MTU so that <bcp14>RECOMMENDED</bcp14> for network operators to increase the underlyin
g MTU so that
NSH traffic is forwarded within an SFC-enabled domain without NSH traffic is forwarded within an SFC-enabled domain without
fragmentation. The available underlying MTU should be taken into account fragmentation. The available underlying MTU should be taken into account
by network operators when providing SFs with the required Context by network operators when providing SFs with the required Context
Headers to be injected per SFP and the size of the data to be carried in Headers to be injected per SFP and the size of the data to be carried in
these Context Headers.</t> these Context Headers.</t>
<t>If the underlying MTU cannot be increased to accommodate the NSH <t>If the underlying MTU cannot be increased to accommodate the NSH
overhead, network operators may rely upon a transport encapsulation overhead, network operators may rely upon a transport encapsulation
protocol with the required fragmentation handling. The impact of protocol with the required fragmentation handling. The impact of
activating such feature on SFFs should be carefully assessed by network activating such feature on SFFs should be carefully assessed by network
operators (Section 5.6 of <xref target="RFC7665"></xref>).</t> operators (<xref target="RFC7665" sectionFormat="of" section="5.6"/>).</t>
<t>When dealing with MTU issues, network operators should consider the <t>When dealing with MTU issues, network operators should consider the
limitations of various transport encapsulations such as those discussed limitations of various transport encapsulations such as those discussed
in <xref target="I-D.ietf-intarea-tunnels"></xref>.</t> in <xref target="I-D.ietf-intarea-tunnels" format="default"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations "> <name>IANA Considerations</name>
<t>This document requests IANA to assign the following types from the <t>IANA has assigned the following types from the
"NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000 "NSH IETF-Assigned Optional Variable-Length Metadata Types" subregistry (0
IETF Base NSH MD Class) registry available at: x0000
https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-me IETF Base NSH MD Class) available at:
tadata-types.</t> <eref brackets="angle" target="https://www.iana.org/assignments/nsh"/>.</t
>
<texttable> <table align="center">
<ttcol>Value</ttcol> <name>NSH IETF-Assigned Optional Variable-Length Metadata Types Additions
</name>
<ttcol>Description</ttcol> <thead>
<tr>
<ttcol>Reference</ttcol> <th align="left">Value</th>
<th align="left">Description</th>
<c>TBD1</c> <th align="left">Reference</th>
</tr>
<c>Subscriber Identifier</c> </thead>
<tbody>
<c>[ThisDocument]</c> <tr>
<td align="left">0x00</td>
<c>TBD2</c> <td align="left">Subscriber Identifier</td>
<td align="left">[RFC8979]</td>
<c>Performance Policy Identifier</c> </tr>
<tr>
<c>[ThisDocument]</c> <td align="left">0x01</td>
</texttable> <td align="left">Performance Policy Identifier</td>
<td align="left">[RFC8979]</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Data plane SFC-related security considerations, including privacy, <t>Data plane SFC-related security considerations, including privacy,
are discussed in Section 6 of <xref target="RFC7665"></xref> and Section are discussed in <xref target="RFC7665" sectionFormat="of" section="6"/> a
8 of <xref target="RFC8300"></xref>. In particular, Section 8.2.2 of nd <xref target="RFC8300" sectionFormat="of" section="8"/>. In particular, <xref
<xref target="RFC8300"></xref> states that attached metadata (i.e., target="RFC8300" sectionFormat="of" section="8.2.2"/> states that attached meta
data (i.e.,
Context Headers) should be limited to that necessary for correct Context Headers) should be limited to that necessary for correct
operation of the SFP. That section indicates that metadata operation of the SFP. <xref target="RFC8300" sectionFormat="of" section="8 .2.2"/> indicates that metadata
considerations that operators can take into account when using NSH are considerations that operators can take into account when using NSH are
discussed in <xref target="RFC8165"></xref>.</t> discussed in <xref target="RFC8165" format="default"/>.</t>
<t>As specified in <xref target="RFC8300" format="default"/>, means to pre
<t>As specified in <xref target="RFC8300"></xref>, means to prevent vent
leaking privacy-related information outside an SFC-enabled domain are leaking privacy-related information outside an SFC-enabled domain are
natively supported by the NSH given that the last SFF of an SFP will natively supported by the NSH given that the last SFF of an SFP will
systematically remove the NSH (and therefore the identifiers defined in systematically remove the NSH (and therefore the identifiers defined in
this specification) before forwarding a packet exiting the SFP.</t> this specification) before forwarding a packet exiting the SFP.</t>
<t>Nodes that are involved in an SFC-enabled domain are assumed to be <t>Nodes that are involved in an SFC-enabled domain are assumed to be
trusted (Section 1.1 of <xref target="RFC8300"> </xref>). Means to check trusted (<xref target="RFC8300" sectionFormat="of" section="1.1"> </xref>) . Discussion of means to check
that only authorized nodes are traversed when a packet is crossing an that only authorized nodes are traversed when a packet is crossing an
SFC-enabled domain are out of scope of this document.</t> SFC-enabled domain is out of scope of this document.</t>
<t>Both Subscriber Identifier and Performance Policy Context Headers <t>Both Subscriber Identifier and Performance Policy Identifier Context He
carry opaque data. This identifier is locally assigned by a network aders
carry opaque data. In particular, the Subscriber Identifier Context Header
is locally assigned by a network
provider and can be generated from some of the information that is provider and can be generated from some of the information that is
already conveyed in the original packets from a host (e.g., internal IP already conveyed in the original packets from a host (e.g., internal IP
address) or other information that is collected from various sources address) or other information that is collected from various sources
within an SFC-enabled domain (e.g., line identifier). The structure of within an SFC-enabled domain (e.g., line identifier). The structure of
the identifiers conveyed in these Context Headers is communicated only the identifiers conveyed in these Context Headers is communicated only
to entitled NSH-aware nodes. Nevertheless, some structures may be easily to entitled NSH-aware nodes. Nevertheless, some structures may be easily
inferred from the headers if trivial structures are used (e.g., IP inferred from the headers if trivial structures are used (e.g., IP
addresses). As persistent identifiers facilitate tracking over time, the addresses). As persistent identifiers facilitate tracking over time, the
use of indirect and non-persistent identification is thus use of indirect and non-persistent identification is thus
RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
<t>Moreover, the presence of multiple Subscriber Identifier Context <t>Moreover, the presence of multiple Subscriber Identifier Context
Headers in the same NSH allows a misbehaving node from within the Headers in the same NSH allows a misbehaving node from within the
SFC-enabled domain to bind these identifiers to the same subscriber. SFC-enabled domain to bind these identifiers to the same subscriber.
This can be used to track that subscriber more effectively. This can be used to track that subscriber more effectively.
The use of non persistent (e.g., regularly randomized) identifiers as
The use of non-persistent (e.g., regularly randomized) identifiers as
well as the removal of the Subscriber Identifier Context Headers from well as the removal of the Subscriber Identifier Context Headers from
the NSH by the last SF making use of such headers soften this issue the NSH by the last SF making use of such headers soften this issue
(see "data minimization" discussed in Section 3 of [RFC8165]). (see "data minimization" discussed in <xref
Such behavior is especially strongly recommended, in case no target="RFC8165" sectionFormat="of" section="3"/>).
Such behavior is especially strongly recommended in case no
encryption is enabled.</t> encryption is enabled.</t>
<t>A misbehaving node from within the SFC-enabled domain may alter the <t>A misbehaving node from within the SFC-enabled domain may alter the
content of Subscriber Identifier and Performance Policy Context Headers content of Subscriber Identifier and Performance Policy Identifier Context
which may lead to service disruption. Such attack is not unique to the Headers,
Context Headers defined in this document; measures discussed in Section which may lead to service disruption. Such an attack is not unique to the
8 of <xref target="RFC8300"></xref> are to be followed. A mechanism for Context Headers defined in this document; measures discussed in <xref
NSH integrity is specified in <xref target="RFC8300" sectionFormat="of" section="8"/> are to be followed. A mechanis
target="I-D.ietf-sfc-nsh-integrity"></xref>.</t> m for
NSH integrity is specified in <xref target="I-D.ietf-sfc-nsh-integrity" fo
rmat="default"/>.</t>
<t>If no secure transport encapsulation is enabled, the use of trivial <t>If no secure transport encapsulation is enabled, the use of trivial
subscriber identifier structures together with the presence of specific subscriber identifier structures, together with the presence of specific
SFs in a service function chain may reveal sensitive information to SFs in a Service Function Chain, may reveal sensitive information to
every on-path device. Also operational staff in every on-path device. Also, operational staff in
teams managing these teams managing these
devices could gain access to such user privacy affecting data. devices could gain access to such user privacy-affecting data.
Such Such
disclosure can be a violation of legal requirements because such disclosure can be a violation of legal requirements because such
information should be available to very few network operator personnel. information should be available to very few network operator personnel.
Furthermore, access to subscriber data usually requires specific access Furthermore, access to subscriber data usually requires specific access
privilege levels. To maintain that protection, an SF keeping operational privilege levels. To maintain that protection, an SF keeping operational
logs should not log the content of a Subscriber and Performance Policy logs should not log the content of Subscriber and Performance Policy
Context Headers unless the SF actually uses the content of these headers Identifier Context Headers unless the SF actually uses the content of thes
for its operation. As discussed in Section 8.2.2 of <xref e headers
target="RFC8300"></xref>, subscriber-identifying information should be for its operation. As discussed in <xref target="RFC8300" sectionFormat="o
obfuscated and, if an operator deems cryptographic integrity protection f" section="8.2.2"/>, subscriber-identifying information should be
needed, security features in the transport encapsulation protocol (such obfuscated, and, if an operator deems cryptographic integrity protection i
s needed, security features in the transport encapsulation protocol (such
as IPsec) must be used. A mechanism for encrypting sensitive NSH data is as IPsec) must be used. A mechanism for encrypting sensitive NSH data is
specified in <xref target="I-D.ietf-sfc-nsh-integrity"></xref>. This specified in <xref target="I-D.ietf-sfc-nsh-integrity" format="default"/>. This
mechanism can be considered by network operators when enhanced SF-to-SF mechanism can be considered by network operators when enhanced SF-to-SF
security protection of NSH metadata is required (e.g., protect against security protection of NSH metadata is required (e.g., to protect against
compromised SFFs).</t> compromised SFFs).</t>
<t>Some events are logged locally with notification alerts sent by <t>Some events are logged locally with notification alerts sent by
NSH-aware nodes to a Control Element. These events SHOULD be rate NSH-aware nodes to a Control Element. These events <bcp14>SHOULD</bcp14> b e rate
limited.</t> limited.</t>
</section> </section>
<section title="Acknowledgements">
<t>Comments from Joel Halpern on a previous version and by Carlos
Bernardos are appreciated.</t>
<t>Contributions and review by Christian Jacquenet, Danny Lachos,
Debashish Purkayastha, Christian Esteve Rothenberg, Kyle Larose, Donald
Eastlake, Qin Wu, Shunsuke Homma, and Greg Mirsky are thankfully
acknowledged.</t>
<t>Many thanks to Robert Sparks for the secdir review.</t>
<t>Thanks to Barry Leiba, Erik Kline, Eric Vyncke, Robert Wilton, and
Magnus Westerlund for the IESG review.</t>
<t>Special thanks to Benjamin Kaduk for the careful review and
suggestions that enhanced this specification.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.8300'?>
<?rfc include='reference.RFC.7665'?>
<?rfc include='reference.RFC.8174'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.8371'?>
<?rfc include='reference.RFC.6973'?>
<?rfc include='reference.RFC.8165'?>
<?rfc include='reference.I-D.ietf-intarea-tunnels'?> <displayreference target="I-D.ietf-intarea-tunnels" to="INTAREA-TUNNELS"/>
<displayreference target="I-D.ietf-sfc-use-case-mobility" to="CASE-MOBILITY"/>
<?rfc include='reference.I-D.ietf-sfc-use-case-mobility'?> <displayreference target="I-D.ietf-sfc-nsh-integrity" to="NSH-INTEGRITY"/>
<?rfc include='reference.I-D.ietf-sfc-nsh-integrity'?>
<reference anchor="TS23401"> <references>
<front> <name>References</name>
<title>General Packet Radio Service (GPRS) enhancements for Evolved <references>
Universal Terrestrial Radio Access Network (E-UTRAN) access,</title> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8300.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7665.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8371.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6973.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8165.xml"/>
<author> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<organization>3GPP 23.401 16.5.0</organization> .ietf-intarea-tunnels.xml"/>
</author>
<date month="December" year="2019" /> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
</front> .ietf-sfc-use-case-mobility.xml"/>
</reference>
<reference anchor="TS23501"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<front> .ietf-sfc-nsh-integrity-03.xml"/>
<title>System architecture for the 5G System (5GS),</title>
<author> <reference anchor="TS23401">
<organization>3GPP 23.501 16.3.0</organization> <front>
</author> <title>General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access, Release 1
6</title>
<author>
<organization>3GPP</organization>
</author>
<date month="December" year="2019"/>
</front>
<seriesInfo name="Version" value="16.5.0"/>
<seriesInfo name="TS" value="23.401"/>
</reference>
<date month="December" year="2019" /> <reference anchor="TS23501">
</front> <front>
</reference> <title>System architecture for the 5G System (5GS), Release 16</titl
e>
<author>
<organization>3GPP</organization>
</author>
<date month="December" year="2019"/>
</front>
<seriesInfo name="Version" value="16.3.0"/>
<seriesInfo name="TS" value="23.501"/>
</reference>
</references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Comments from <contact fullname="Joel Halpern"/> on a previous draft ve
rsion and from <contact fullname="Carlos
Bernardos"/> are appreciated.</t>
<t>Contributions and review by <contact fullname="Christian Jacquenet"/>,
<contact fullname="Danny Lachos"/>,
<contact fullname="Debashish Purkayastha"/>, <contact fullname="Christian
Esteve Rothenberg"/>, <contact fullname="Kyle Larose"/>, <contact fullname="Dona
ld
Eastlake"/>, <contact fullname="Qin Wu"/>, <contact fullname="Shunsuke Hom
ma"/>, and <contact fullname="Greg Mirsky"/> are thankfully
acknowledged.</t>
<t>Many thanks to <contact fullname="Robert Sparks"/> for the secdir revie
w.</t>
<t>Thanks to <contact fullname="Barry Leiba"/>, <contact fullname="Erik Kl
ine"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Robert Wilton"/>,
and
<contact fullname="Magnus Westerlund"/> for the IESG review.</t>
<t>Special thanks to <contact fullname="Benjamin Kaduk"/> for the careful
review and
suggestions that enhanced this specification.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 124 change blocks. 
398 lines changed or deleted 379 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/