Service Function
Chaining: Subscriber and Performance Policy Identification Variable-Length
Network Service Header (NSH) Context HeadersDenpel Informatiquesarikaya@ieee.orgDeutsche TelekomT-Online-Allee 1D-64295 DarmstadtGermanyDirk.von-Hugo@telekom.deOrangeRennes 3500Francemohamed.boucadair@orange.comSFCThis document defines Subscriber and Performance Policy Identifiers
Network Service Header Variable-Length Context Headers to inform Service
Functions about subscriber- and service-related information for the sake
of policy enforcement and appropriate service function chaining
operations. The structure of each context header is defined, their use
and processing instructions by SFC-aware nodes are explained.This document discusses how to inform Service Functions (SFs, ) about subscriber- and service-related
information, when required, for the sake of policy enforcement within a
single administrative domain. Particularly, subscriber-related
information may be required to enforce subscriber-specific SFC-based
traffic policies. Nevertheless, the information carried in packets may
not be sufficient to unambiguously identify a subscriber. This document
fills this void by specifying a new Network Service Header (NSH) context header to convey and disseminate such
information within the boundaries of a single administrative domain.Also, the enforcement of SFC-based differentiated traffic policies
may be inferred, for example, by QoS (Quality of Service)
considerations. Typically, QoS information may serve as an input to the
Service Function Path (SFP) for path computation, establishment, and
selection. Furthermore, the dynamic structuring of service function
chains and their subsequent enforcement may be conditioned by QoS
requirements that will affect SF instance identification, location, and
sequencing. Hence, the need to supply a performance policy identifier to
upstream SFs to appropriately meet the service requirements arises.SFs and SF Forwarders (SFFs) involved in a service chain have to
contribute to the respective service policy (QoS, for example)
requirements characterized by low transmission delay between each other,
by exposing a high availability of resources to process function tasks,
or by redundancy provided by stand-by machines for seamless execution
continuation in case of failures. These requirements may be satisfied by
means of control plane protocols, but in some contexts, e.g., in
networks where resources are very much constrained, carrying QoS-related
information directly in packets may improve the overall SFC operation
instead of relying upon the potential complexity or adding overhead
introduced by some SFC control plane features. This information is
typically included as a context header in the NSH.The context information defined in this document can be applicable in
the context of mobile networks (particularly, in the 3GPP defined (S)Gi
Interface) .
Typically, because of the widespread use of private addressing in those
networks, if SFs to be invoked are located after a NAT function, the
identification based on the internal IP address is not possible once the
NAT has been crossed. NAT functionality can reside in a distinct node
which for 3GPP network can be the Packet Data Network (PDN) Gateway
(PGW) as specified in in case of 4G or
the User Plane Function (UPF) facing the external Data Network (DN)
in case of 5G, respectively. As such,
means to allow passing the internal information may optimise packet
traversal within an SFC-enabled mobile network domain. Furthermore, some
SFs that are not enabled on the PGW/UPF may require a subscriber
identifier to properly operate. As such identifier one of already
specified 3GPP identifiers may serve (see, for example, those listed in
), but it is out of scope of this document
to include a comprehensive list of deployment contexts which may make
use of the context headers defined in the document.This document does not make any assumption about the structure of
subscriber or performance policy identifiers; each such identifier is
treated as an opaque value. The semantics and validation of these
identifiers are up to the control plane used for SFC within an
SFC-enabled domain. Expectations to SFC control plane protocols are laid
down, e.g., in , but specifications of SFC
control plane functions are also discussed in, for example, . Control plane
related considerations are out of scope.This document assumes the NSH is used exclusively within a single
administrative domain.This document adheres to the architecture defined in . This document assumes the reader is familiar
with .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here.The reader should be familiar with the terms defined in .Subscriber Identifier is defined as an optional variable-length NSH
context header. Its structure is shown in .
The description of the fields is as follows:Metadata Class: MUST be set to 0x0 .Type: TBD1 (See ).U bit: Unassigned bit (see Section 2.5.1 of ).Length: Indicates the length of the Subscriber Identifier, in
bytes (see Section 2.5.1 of ).Subscriber Identifier: Carries an opaque subscriber
identifier.The subscriber identifier is used to convey an identifier assigned by
the service provider to uniquely identify a subscriber. This subscriber
identifier can be used by service functions to enforce per-subscriber
policies (e.g., apply resource quota).The classifier and SFC-aware SFs MAY be instructed via a control
interface to inject or strip a subscriber identifier context header.
Also, the data to be injected in such header SHOULD be configured to
nodes authorized to inject such headers. Typically, a node can be
instructed to insert such data following a type/set scheme (e.g., node X
should inject subscriber ID type Y). Other schemes may be envisaged.Failures to inject such headers SHOULD be logged locally while a
notification alarm MAY be sent to a Control Element. The details of
sending notification alarms (i.e., the parameters affecting the
transmission of the notification alarms depend on the information in the
context header such as frequency, thresholds, and content of the alarm
(full header, timestamp, etc.)) SHOULD be configurable by the control
plane.This document adheres to the recommendations in for handling the context headers at both
ingress and egress SFC boundary nodes. That is, to strip such context
headers. Revealing any personal and subscriber-related information to
third parties is avoided by design to prevent privacy breaches in terms
of user tracking.SFC-aware SFs and proxies MAY be instructed to strip a subscriber
identifier context header from the packet or to pass the data to the
next SF in the service chain after processing the content of the context
headers. If no instruction is provided, the default behavior for
intermediary SFC-aware nodes is to maintain such context headers so that
the information can be passed to next SFC-aware hops.SFC-aware SFs MAY be instructed via the control plane about the
validation checks to run on the content of these context headers (e.g.,
accept only some lengths) and the behavior to adopt. For example,
SFC-aware SFs may be instructed to ignore the context header, to remove
the context header from the packet, etc. Nevertheless, this
specification does not require nor preclude such additional validation
checks. These validation checks are deployment-specific. If validation
checks fail on a subscriber identifier context header, an SFC-aware SF
MUST ignore that context header. The event SHOULD be logged locally
while a notification alarm MAY be sent to a Control Element if the
SFC-aware SF is instructed to do so.Multiple subscriber Identifier context TLVs MAY be present in the NSH
each carrying a distinct opaque value but all pointing to the same
subscriber. When multiple subscriber identifier context TLVs are present
and an SF is instructed to strip the subscriber identifier context
header, that SF has to remove all subscriber identifier context
TLVs.Dedicated service-specific performance identifier is defined to
differentiate between services requiring specific treatment to exhibit a
performance characterized by, e.g., ultra-low latency (ULL) or
ultra-high reliability (UHR). Other policies can be considered when
instantiating a service function chain within an SFC-enabled domain.
They are conveyed in the Performance Policy Identifier context
header.The performance policy identifier is inserted in an NSH packet so
that upstream SFC-aware nodes can make use of the performance
information for proper distributed SFC path selection, SF instance
selection, or policy selection at SFs. Note that the use of performance
policy identifier is not helpful if the path computation is centralized
and a strict SFP is passed by means of SFC control plane to SFFs.The performance policy identifier allows for the distributed
enforcement of a per-service policy such as a service function path to
only include specific SFs instances (e.g., SFs located within the same
DC or those that are exposing the shortest delay from an SFF). Details
of this process are implementation-specific. For illustration purposes,
an SFF may retrieve the details of usable SFs based upon the
corresponding performance policy identifier. Typical criteria for
instantiating specific SFs include location, performance, or proximity
considerations. For the particular case of UHR services, the stand-by
operation of back-up capacity or the deployment of multiple SF instances
may be requested.In an environment characterised by frequent changes of link and path
behaviour, for example due to variable load or availablility caused by
propagation conditions on a wireless link, the SFP may have to be
adapted dynamically by on-the move SFC path and SF instance selection.
Performance Policy Identifier is defined as optional variable length
context header. Its structure is shown in .Similar control plane considerations as those discussed in are to be followed.Multiple performance policy identifier context headers MAY be present
in the NSH; each carrying a distinct opaque value but all are pointing
to policies that need to be enforced for a flow. It is up to the control
plane to ensure that these policies are not conflicting. When such
conflict is detected by an SFC-aware node, the default behavior of the
node is to discard the packet and send a notification alarm to a Control
Element.The description of the fields is as follows:Metadata Class: MUST be set to 0x0 .Type: TBD2 (See ).U bit: Unassigned bit (see Section 2.5.1 of ).Length: Indicates the length of the Performance Policy
Identifier, in bytes (see Section 2.5.1 of ).Performance Policy Identifier: Represents an opaque value
pointing to specific performance policy to be enforced. The
structure and semantic of this field is deployment-specific.This document requests IANA to assign the following types from the
"NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000
IETF Base NSH MD Class) registry available at:
https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types.ValueDescriptionReferenceTBD1Subscriber Identifier[ThisDocument]TBD2Performance Policy Identifier[ThisDocument]Data plane SFC-related security considerations, including privacy,
are discussed in and .Nodes that are involved in an SFC-enabled domain are assumed to be
trusted (). Means to check that only
authorized nodes are solicited when a packet is crossing an SFC-enabled
domain are out of scope of this document.A misbehaving node within from the SFC-enabled domain may alter the
content of Subscriber and Performance Policy TLVs which may lead to
service disruption. Such attach is not unique to the TLVs documents
defined in the document; measures discussed in are to be followed. Also, integrity checks
offered by the transport encapsulation can be used to detect
anomalies.An SF maintaining logs for operational reasons MUST NOT log the
content of Subscriber and Performance Policy context headers received in
NSH packets if the SF does not use the content of that header for its
operation.Comments from Joel Halpern on a previous version and by Carlos
Bernardos are appreciated.Contributions and review by Christian Jacquenet, Danny Lachos,
Debashish Purkayastha, Christian Esteve Rothenberg, Kyle Larose, Donald
Eastlake, Qin Wu, and Shunsuke Homma are thankfully acknowledged.General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access,3GPP 23.401 16.5.0System architecture for the 5G System (5GS),3GPP 23.501 16.3.0