Service Function
Chaining: Subscriber and Policy Identification Variable-Length Network
Service Header (NSH) Context HeadersOrangeRennes 3500Francemohamed.boucadair@orange.comDeutsche TelekomDeutsche-Telekom-Allee 7D-64295 DarmstadtGermanyDirk.von-Hugo@telekom.deDenpel Informatiquesarikaya@ieee.orgSFCThis document discusses how to inform Service Functions about
subscriber- and service-related information for the sake of policy
enforcement and appropriate service function chaining operations.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.Also, the enforcement of SFC-based differentiated traffic policies
may be inferred by QoS considerations. Typically, QoS information may
serve as an input to classification of 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 policy identifier to upstream SFs to appropriately meet the
service requirements.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 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 metadata in the NSH as the SFC encapsulation to
provide the SFP identification.The context information defined in this document can be applicable in
the context of mobile networks (typically, in the 3GPP defined (S)Gi
Interface) .
Because of the widespread use of private addressing in those networks,
if SFs to be invoked are located after a NAT function (that can reside
in the Packet Data Network (PDN) Gateway (PGW) or in a distinct node),
the identification based on the internal IP address is not anymore
possible once the NAT has been crossed. 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 may require a subscriber identifier to properly
operate.This document does not make any assumption about the structure of
subscriber or policy identifiers; each such identifier is treated as an
opaque value by the SFC operations and protocols. The semantics and
validation of these identifiers are up to the control plane used for
SFC. Expectations to SFC control plane protocols are laid down, e.g., in
, but specifications of SFC control plane
functionalities are also discussed in, for example, , , or .The use cases considered in this document assume 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 subscriber identifier is used to convey an identifier already
assigned by the service provider to uniquely identify a subscriber. This
header conveys an opaque subscriber Identifier that can be used by the
service functions to enforce per-subscriber policies.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 in the alarm
(full header, header ID, 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 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.The description of the fields is as follows:Metadata Class: MUST be set to 0x0 .Type: TBD1 (See )Subscriber Identifier: Carries an opaque subscriber
identifier.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 contained in the Policy Identifier context header. The policy identifier is inserted in an NSH packet so that upstream
SFC-aware nodes can make use of the information for proper distributed
SFC path selection, SF instance selection, or policy selection at
SFs.Thus, the policy identifier allows for the distributed enforcement of
a per-service policy such as a service function path to only include
specific SFs instances. Details of this process are
implementation-specific. For illustration purposes, an SFF may retrieve
the details of usable SFs based upon the corresponding 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.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 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 )Policy Identifier: Represents an opaque value pointing to
specific policy to be enforced. The structure and semantic of this
filed 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]TBD2Policy 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.An SF maintaining logs for operational reasons MUST NOT log the
content of subscriber identifier context header 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, and Kyle Larose are thankfully acknowledged.