Network Service Header Metadata Type 2 Variable-Length Context Headers

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 specific to the operator's deployment across its operational domain, and are specified and assigned by an orchestration function. The specifics of that orchestration-based assignment are outside the scope of this document.

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. Context Type (CT) is four bits-long field that defines the length and the interpretation of the Flow ID field. Please see the IANA Considerations in . This document defines these CT values: 0x0 - 20 bits IPv6 Flow Label in . See . 0x1 - 20 bits entropy label in the MPLS network in . See . Reserved bits in the context fields 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.

If there is no group information specified for the source group or dest group field, the field MUST be sent as zero and ignored on receipt.

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 . Value Description Reference TBA1 Forwarding Context This document TBA2 Tenant Identifier This document TBA3 Ingress Network NodeID This document TBA4 Ingress Network Interface This document TBA5 Flow ID This document TBA6 Source and/or Destination Groups This document TBA7 Policy Identifier This document

IANA is requested to create a new sub-registry for "Forwarding Context" context types at as follows: The Registration Policy is IETF Review Value Forwarding Context Header Types Reference 0x0 12-bit VLAN identifier This document 0x1 24-bit double tagging identifiers This document 0x2 20-bit MPLS VPN label This document 0x3 24-bit virtual network identifier (VNI) This document 0x4 32-bit Session ID This document 0x5-0xE Unassigned 0xF Reserved This document

IANA is requested to create a new sub-registry for "Flow ID Context" context types at as follows: The Registration Policy is IETF Review Value Flow ID Context Header Types Reference 0x0 20-bit IPv6 Flow Label This document 0x1 20-bit entropy label in the MPLS network This document 0x2-0xE Unassigned 0xF Reserved This document