Network Service Header Metadata Type 2 Variable-Length Context HeadersZTE CorporationNo.50, Software AvenueNanjing210012Chinawei.yuehua@zte.com.cnInteluri.elzur@intel.comSum.majee@gmail.comCiscocpignata@cisco.com
Routing
SFC
This draft describes Network Service Header (NSH) Metadata (MD) Type 2 variable-length context headers that can be used within a service function path.
Network Service Header (NSH) is the
Service Function Chaining (SFC) encapsulation required to support the SFC architecture. As such, NSH provides following key elements:
Service Function Path identification.Indication of location within a Service Function Path.Optional, per-packet metadata (fixed-length or variable). 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 draft defines some common metadata contexts for use with NSH MD Type 2.
This draft 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 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. Therefore, Length = 0x2 indicates that only
the Base Header followed by the Service Path Header is present. The
value of the Length field, of optional Variable Length
Context Headers, MUST be an integer indicating the length in 4-octet
words. below depicts the format of the Context Header
as defined in Section 2.5.1 of .
In defined that Metadata Class 0x0000 as IETF Base NSH MD Class. In this
draft, 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 Tenant ID field. Please see the IANA Considerations in . This document defines these CT values:
0x0 - 24 bits VXLAN/LISP virtual network identifier (VNI)0x1 - 20 bits MPLS VPN label0x2 - 12 bits VLAN identifier
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 both the format and
value of the Tenant identifier.
where:
Tenant Type (TT) is four bits-long field that specifies the length of the Tenant ID field.
This document defines the following values for TT:
0x0 - 32 bits-long Tenant ID0x1 - 64 bits-long Tenant ID
This context header carries a Node ID of the ingress network node.
where:
Node ID Type (NIT) is four bits-long field that specifies the length of the Node ID field.
This document defines the following values for NIT:
0x0 - 32 bits-long Node ID0x1 - 128 bits-long Node ID
This context carries 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. Absence of this field, or
a value of zero denotes that packets have not been labeled.
defined IPv6 Flow Label as a 20-bit long unsigned integer.
Also, , which defined the use of an entropy label in the MPLS network,
is 20-bit long. If either IPv6 Flow Label or MPLS entropy label (identified by preceding Entropy Label Indicator) are carried in the Flow ID field,
it occupies 20 least significant bits in the 4-octet long word.
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.
where:
Group Type (GT) is four bits-long field that specifies the interpretation of Source Group
and/or Destination Group fields. This document defines the following values for GT:
0x1 - Group Based Policy (GBP) an end point group (EPG)
where
URI (Universal Resource Identifier) Type is four
bits-long field that specifies the format of the URI field.
This document defines the following values for the URI Type field:
0x1: URI in standard string format as defined in .0x2: URI represented in a compacted hash format.
The policy is 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 lookup up the content of their
part of the policy quite efficiently.
describes the requisite security considerations for protecting
NSH metadata.
The authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von Hugo, Mohamed Boucadair, and Gregory Mirsky for providing invaluable concepts and content for this document.
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
This document defines the following new values () in the Network Service Header (NSH) metadata context Type registry:
ValueDescriptionReferenceTBA1Forwarding ContextThis documentTBA2Tenant IdentifierThis documentTBA4Ingress Network NodeIDThis documentTBA5Ingress Network InterfaceThis documentTBA6Flow IDThis documentTBA7Source and/or Destination GroupsThis documentTBA8Universal Resource Identifier This documentTBA9Policy IdentifierThis documentIANA is requested to create and maintain a new sub-registry for "Forwarding Context" context types at .
ValueContext TypesReference0x024-bits VXLAN/LISP virtual network identifier (VNI)This document0x120-bits MPLS VPN labelThis document0x212-bit VLAN identifierThis document0x3-0xCUnassignedIETF Review0xD-0xEUnassignedExperimental Use0xFReservedThis documentIANA is requested to create and maintain a new sub-registry for "Tenant Identifier" context types at , with the following initial allocation:
ValueTenant Identifier TypesReference0x032 bits-long Tenant IDThis document0x164 bits-long Tenant IDThis documentIANA is requested to create and maintain a new sub-registry for "Node ID" context types at , with the following initial allocation:
ValueNode ID TypesReference0x032 bits-long Node IDThis document0x1128 bits-long Node IDThis documentIANA is requested to create and maintain a new sub-registry for "Group" context types at , with the following initial allocation:
ValueGroup TypesReference0x0ReservedThis document0x1Group Based Policy (GBP) end point group (EPG)This document0x2-0xEUnassignedIETF Review0xFReservedThis documentIANA is requested to create and maintain a new sub-registry for "Group" context types at , with the following initial allocation:
ValueURI TypesReference0x0ReservedThis document0x1URI in standard string format as defined in [RFC3986]This document0x2URI represented in a compacted hash formatThis document0x3-0xEUnassignedIETF Review0xFReservedThis document
NSH IETF-Assigned Optional Variable-Length Metadata Types
IANAGroup Based PolicyOpenStackGroup PolicyOpenDaylight