NSH Context Header
Allocation for BroadbandCisco Systems, Inc.jenapper@cisco.comIndividual Contributorsurendra.stds@gmail.comNokiapraveen.muley@nokia.comNokiaWim.Henderickx@nokia.comOrangeFrancemohamed.boucadair@orange.comService Function ChainingThis document provides a recommended allocation of Network Service
Header (NSH) context headers within the broadband service provider
network context. Both fixed and mobile deployments are considered.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .Service Function Chaining (SFC)
provides a mechanism for network traffic to be steered through an
ordered list of Service Functions (SFs). Furthermore, SFC allows to
share metadata among involved SFC data functional elements (classifiers
and SFs). Particularly, the Network Service Header (NSH) provides
support for carrying shared metadata either using a fixed context header
or as optional TLVs .This document provides a recommended default allocation scheme for
the fixed-length context header used for SFC within fixed and mobile
broadband service provider networks. Also, the document defines
companion TLV types when MD Type 0x02 is used. The use cases describing
the need for metadata in these contexts are described in .This document does not address control plane mechanisms. The reader
may refer to .This document makes use of the terms as defined in , , and .The NSH is composed of a 4-byte base header (BH1), a 4-byte service
path header (SH1) and a mandatory 16-byte context header in the case of
MD Type 0x01 and optional TLVs in the case of MD Type 0x02 .The following shows the
format of the MD Type 0x01 NSH header.The following shows the MD
Type 0x02 NSH header format.The following header allocations provide information to support
service function chaining in a service provider network, for example as
described for mobility in .The set of metadata headers can be delivered to service functions
that can use the metadata within to enforce policy, communicate between
service functions, provide subscriber information and other
functionality. Several of the headers are typed allowing for different
metadata to be provided to different service functions or even to the
same service function but on different packets within a flow.Which metadata are sent to which service functions is decided in the
SFC control plane and is thus out of the scope of this document.The following provides
a high-level description of the fields in the recommended allocation
of the fixed sixteen byte context headers for a broadband context.
Each four byte word in the sixteen byte context header is referred to
as CH1, CH2, CH3, and CH4, respectively.The intended use for each of the context header fields is as
follows: Reserved.Sub/Endpoint ID type field. These bits
determine the type of the 64-bit Sub/Endpoint ID field that spans
CH2 and CH3. If the Sub field is not set, then the
64-bit Sub/Endpoint ID field is an opaque field that can be
used or ignored by service functions as determined by the
control plane.The Sub/Endpoint ID field contains an IMSI
.The Sub/Endpoint ID field contains an
MSISDN (8-15 digit) .The Sub/Endpoint ID field contains a 64-bit
identifier that can be used to group flows (e.g., in
Machine-to-Machine (M2M) contexts).The Sub/Endpoint IP field contains a
wireline subscriber ID in CH2, and CH3 contains the home
identifier.Reserved.Indicates the type of the Service Information
field in CH4. The following values are defined: If the Tag field is not set, then the
Service Information field in CH4 is an opaque field that can
be used or ignored by SFs as determined by the control
plane.The Service Information field in CH4
contains information related to the Access Network (AN) for
the subscriber. This is shown in for a 3GPP Radio Access Network
(RAN). Note that these values should
correspond to those that can be obtained for the flow from the
corresponding 3GPP PCRF (Policy and Charging Rules Function)
component using Diameter as described in . IP-CAN-Type for IP Connectivity Access
Network (Diameter AVP code 1027).QoS-Class-Identifier AVP (Diameter AVP
code 1028) or Differentiated Services Code Point (DSCP)
marking as described in .Access congestion level. An Access
Congestion level '000' means an unknown/undefined
congestion level. An Access Congestion level '001' means
no congestion. For other values of Access Congestion
level, a higher value indicates a higher level of
congestion.Application ID describing the flow
type. Allocation of IDs is done using the control plane
and is out of the scope of this document.Reserved.Reserved.The Context ID field allows the
Subscriber/Endpoint ID field to be scoped. For example, the
Context ID field may contain the incoming VRF, VxLAN VNID, VLAN,
or policy identifier within which the Subscriber/Endpoint ID field
is defined.64-bit length Subscriber/Endpoint
identifier (e.g., IMSI, MSISDN, or implementation-specific
Endpoint ID) of the corresponding subscriber/machine/application
for the flow.The Service Information field
is a unique identifier that can carry metadata specific to the
flow or subscriber identified in the Sub/Endpoint ID field.The following provides a high-level
description of the fields in the recommended allocation of the
variable length headers for a mobility context.The intended use of the header is for TLVs associated with 3GPP
Radio Access Networks as described in . This TLV can be used by 3GPP to extend the
metadata as per use cases. Having this TLV helps to carry more
information that does not fit within the MD Type 0x01.The Len field carries the total length. Type = 0x01 is reserved. If
set to 0x01, the TLV carries the 4 context headers as defined in .DISCUSSION NOTE: Should we ask for allocating a TLV class or
restrict the document to asking for a TLV code from the IETF TLV
Class 0?This document describes an allocation scheme for both the fixed
context header (MD#1) and optional TLV headers (MD#2) in the context of
broadband service providers. This allocation of headers should be
considered as a guideline and may vary depending on the use case.The control plane aspects of specifying and distributing the
allocation scheme among different service functions within the Service
Function Chaining environment to guarantee consistent semantics for the
metadata is beyond the scope of this document.This specification relies on NSH to share metadata among SFC data
plane elements. Security-related consideration discussed in MUST be followed.The recommended header allocation in this document includes sensitive
information that MUST NOT be revealed outside an SFC-enabled domain.
Those considerations are already discussed in .Furthermore, means to prevent that illegitimate nodes insert spoofed
data MUST be supported. As a reminder, the NSH specification assumes
ingress boundary nodes strip any NSH data that may be present in a
packet. Misbehaving nodes from within an SFC-enabled domain may alter
the content of the NSH data. Such treats are discussed in .This document requests IANA to assign a TLV class for 3GPP to be used
for its use cases.The authors would like to thank Jim Guichard for his assistance
structuring the document.Diameter applications; 3GPP specific codes and
identifiersThe international public telecommunication numbering
plan