Network Service Header Metadata Type 2 Variable-Length Context HeadersZTE CorporationNo.50, Software AvenueNanjing210012Chinawei.yuehua@zte.com.cnInteluri.elzur@intel.comIndividual contributorSum.majee@gmail.comCiscocpignata@cisco.comFuturewei Technologiesd3e3e3@gmail.com
Routing
SFC
Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context Metadata (MD) with each packet. Such Metadata can be of various Types including MD Type 2 variable length context headers. This document specifies several such context headers that can be used within a service function path.
The Network Service Header (NSH) is the
Service Function Chaining (SFC) encapsulation that supports the SFC architecture . As such, the NSH provides following key elements:
Service Function Path (SFP) identification.Indication of location within a Service Function Path.Optional, per-packet metadata (fixed-length or variable-length). further defines two metadata formats (MD Types): 1 and 2. MD
Type 1 defines the fixed-length, 16-octet long metadata, whereas MD Type 2
defines a variable-length context format for metadata. This document defines several common metadata context headers for use with NSH MD Type 2. These supplement the Subscriber Identity and Performance Policy MD Type 2 metadata context headers specified in .
This document does not address metadata usage, updating/chaining of
metadata, or other SFP functions. Those topics are described in .
This document uses the terminology defined in the SFC Architecture and the Network Service Header .
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.
An NSH is composed of a 4-octet Base Header, a 4-octet Service Path
Header and optional Context Headers. The Base Header identifies the MD-Type
in use:
Please refer to NSH for a detailed header description.
When the base header specifies MD Type = 0x2, zero or more Variable
Length Context Headers MAY be added, immediately following the
Service Path Header. below depicts the format of the Context Header
as defined in Section 2.5.1 of .
specifies Metadata Class 0x0000 as IETF Base NSH MD Class. In this document, metadata types are defined for the IETF Base NSH MD Class.
This metadata context carries a network forwarding context, used for
segregation and forwarding scope. Forwarding context can take
several forms depending on the network environment. For example, VXLAN/VXLAN-GPE VNID, VRF identification, or VLAN.
where:
Context Type (CT) is four bits-long field that defines the length and the interpretation of the Forwarding Context field. Please see the IANA Considerations in . This document defines these CT values:
0x0 - 12 bits VLAN identifier . See . 0x1 - 24 bits double tagging identifiers. A service VLAN tag followed by a customer VLAN tag . The two VLAN IDs are concatenated and appear in the same order that they appeared in the payload.
See .0x2 - 20 bits MPLS VPN label()(). See .0x3 - 24 bits virtual network identifier (VNI). See . 0x4 - 32 bits Session ID (). This is called Key in GRE . See .
Reserved bits in the context fields MUST be sent as zero and ignored on receipt.
Tenant identification is often used for segregation within a
multi-tenant environment. Orchestration system-generated tenant
IDs are an example of such data. This context header carries the value of the Tenant identifier. Virtual Tenant Network (VTN) is an application that provides multi-tenant virtual network on an SDN controller.
The fields are described as follows:
Length: Indicates the length of the Tenant ID in octets (see Section 2.5.1 of ).Tenant ID: Represents an opaque value pointing to Orchestration system-generated tenant identifier. The structure and semantics of this field are deployment specific.
This context header carries a Node ID of the ingress network node.
The fields are described as follows:
Length: Indicates the length of the Node ID in octets (see Section 2.5.1 of ).Node ID: Represents an opaque value of the ingress network node ID. The structure and semantics of this field are deployment specific. For example, Node ID may be a 4 octets IPv4 address Node ID, or a 16 octets IPv6 address Node ID, or a 6 octets MAC address, or 8 octets MAC address (EUI-64), etc.This context identifies the ingress interface of the ingress network node. The l2vlan (135), l3ipvlan (136), ipForward (142), mpls (166) in are examples of source interfaces.
The fields are described as follows:
Length: Indicates the length of the Source Interface in octets (see Section 2.5.1 of ).Source Interface: Represents an opaque value of identifier of the ingress interface of the ingress network node.
Flow ID provides a field in the NSH MD Type 2 to label packets belonging to the same flow. For example, defined IPv6 Flow Label as Flow ID, defined an entropy label which is generated based on flow information in the MPLS network is another example of Flow ID. Absence of this field, or
a value of zero denotes that packets have not been labeled.
The fields are described as follows:
Length: Indicates the length of the Flow ID in octets (see Section 2.5.1 of ). For example, IPv6 Flow Label in is 20-bit long. An entropy label in the MPLS network in is also 20-bit long. Flow ID: Represents an opaque value of the Flow ID. The Flow ID is right justified (appears in the least significant bits of the Flow ID word) and is padded on the left with bits which MUST be sent as zero and ignored on receipt.
Intent-based systems can use this data to express the logical
grouping of source and/or destination objects.
and provide examples of such a
system. Each is expressed as a 32-bit opaque object.
Traffic handling policies are often referred to by a system-generated identifier, which
is then used by the devices to look up the policy's content
locally. For example, this identifier could be an index to an
array, a lookup key, a database Id. The identifier allows
enforcement agents or services to look up the content of their
part of the policy.
The fields are described as follows:
Length: Indicates the length of the Policy ID in octets (see Section 2.5.1 of ).Policy ID: Represents an opaque value of the Policy ID.
This policy identifier is a general policy ID, essentially a key to allow Service Functions to know which policies to apply to packets. Those policies generally will not have much to do with performance, but rather with what specific
treatment to apply. It may for example select a URL filter data set for a URL filter, or select a video transcoding policy in a transcoding SF. The Performance Policy Identifier in is described there as having very specific use, and for example says that fully controlled SFPs would not use it. The Policy ID in this document is for cases not covered by .
A misbehaving node from within the SFC-enabled domain may alter the content of the Context Headers, which may lead to service disruption. Such an attack is not unique to the Context Headers defined in this document. Measures discussed in Section 8 of describes the general security considerations for protecting NSH. specifies methods of protecting the integrity of the NSH metadata. If the NSH includes the MAC Context Header, the authentication of the packet MUST be verified before using any data. If the verification fails, the receiver MUST stop processing the variable length context headers and notify an operator.
The authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von Hugo, Mohamed Boucadair, Gregory Mirsky, and Joel Halpern for providing invaluable concepts and content for this document.
IANA is requested to assign the following types () from the "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry available at .
ValueDescriptionReferenceTBA1Forwarding ContextThis documentTBA2Tenant IdentifierThis documentTBA3Ingress Network NodeIDThis documentTBA4Ingress Network InterfaceThis documentTBA5Flow IDThis documentTBA6Source and/or Destination GroupsThis documentTBA7Policy IdentifierThis documentIANA is requested to create a new sub-registry for "Forwarding Context" context types at as follows:
The Registration Policy is IETF ReviewValueForwarding Context Header TypesReference0x012-bit VLAN identifierThis document0x124-bit double tagging identifiersThis document0x220-bit MPLS VPN labelThis document0x324-bit virtual network identifier (VNI)This document0x432-bit Session IDThis document0x5-0xEUnassigned0xFReservedThis documentIEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged NetworksIEEE
NSH IETF-Assigned Optional Variable-Length Metadata Types
IANAOpenDaylight VTNOpenDaylightIANAifTypeIANAGroup Based PolicyOpenStackGroup Based PolicyOpenDaylight