Service Function Chaining Metadata Type 1 and Type 2

Network Service Header (NSH) is the Service Function Chaining (SFC) data plane protocol. The SFC architecture is defined in . NSH has the function of carrying context data in the form of context header. NSH metadata Type 1 is composed of a 4-byte base header, 4-byte service path header. It contains four mandatory Context Headers, 4-byte each which can be combined into one context header of 16 octets in the latest version. For additional metadata that needs to be carried, NSH metadata type 2 is defined. Type 2 metadata is composed of a 4-byte base header carrying Type value of 0x02, 4-byte service path header followed by variable length context headers in the form of metadata class type-length-value or TLV. Optional variable length metadata definition includes 16-bit metadata class and 7-bit type fields. It is an issue if such a long metadata class field is needed and whether the type field length should be increased. Many context headers were proposed by many documents. In this document we survey existing drafts that propose new context metadata and then discuss different options that can be taken to standardize this work. The reader should be familiar with the terms defined in and .

addresses metadata allocation that seems to be relevant when NSH is used for SFC within a data center. The use cases that demonstrate the applicability of SFC within a data center environment are described in . This document defines meta data Type 1 for several IDs of Source Node, Source Interface and Tenant. It defines destination and source class to classify the destination and source of the traffic for the purposes of applying policy. It defines Opaque Service Class in the 4th word. supports use cases in . This document defines meta data Type 1 with endpoint ID, e.g. for IMSI or MSISDN or wireline subscriber ID with 64-bit length. It also defines ServiceTag to identify that the Service Information field contains information related to the Access Network (AN) for the subscriber. Service information could contain IP-CAN type, QoS class, congestion level, etc. for a 3GPP Radio Access Network (RAN). Context ID field allows the subscriber/endpoint ID field to be scoped. Context ID contains the incoming VRF, VxLAN VNID, VLAN, or policy identifier within which the Subscriber/Endpoint ID field is defined. In addition, the document defines a meta data Type 2 TLV to be associated with 3GPP registry. The intent here is to offer this TLV for the use of 3GPP to extend the meta data to meet the needs of 3GPP use cases. However, it was not stated if 3GPP requested such an allocation. addresses the use cases for network security defined in . It defines a recommended security context allocation as a meta data Type 1 TLV. It is intended to define session ID, tenant ID, destination/ source class for the logical classification of the destination/ source of the traffic, destination/ source score which contains security classification results for communicating immediate actions and accumulated verdicts to downstream Service Functions. also mentions that the security context allocation, although defined as Type 1, it may also form a MD-Type 2 metadata TLV, possibly implying that the sizes of data such as session/ tenant ID, etc. may need to become longer. As a result, they may need to become variable length data as in Type 2 meta data TLVs. This document defines network security allocation specifics, basically explaining the semantics of the metadata they define in the document. defines Type 1 metadata called Broadband Context Allocation support service function chaining in a broadband service provider network. It defines Source Node, Source Interface, User and VLAN IDs. addresses use cases that require revealing host and/ or subscriber related information to upstream SFs as well as extreme low latency service and ultra-high reliability applications use cases. From the analysed use cases, there comes the need to come up with definition of host, subscriber, slice identifier and service identifier SFC meta data Type 2 TLVs. Apart from defining these TLVs, the document gives details of post processing in various nodes such as ingress/egress border nodes, SFC-aware Service Functions and Proxies. Such post processing is defined as normative behavior. Since host and subscriber identifiers may reveal private information about the host and/or the subscriber, the document also defines normative behavior needed to protect the privacy of the hosts and subscribers in an operator network. is unique among the documents discussed in this document because it defines the post processing normative behavior related to the host and subscriber identifier meta data Type 2 TLVs. Also the use cases are defined in the same document not as a separate document as in the other cases. addresses the problem of sending packets in the reverse direction to the source of the current in-process packet/flow. It defines SF Reverse Packet Request as Type 1 metadata. This is defined as Version 1 (as opposed to Version 0 of NSH MD-type 1 in ) with OAM Protocol replacing the next protocol field and with Reverse Packet Request added to the end of mandatory context header octets for SFC as an additional 4-octet for OAM. This document also proposes 5 new metadata on service-path invariants, service-path default, bidirectional clonable, unidirectional clonable and service-function-mastered metadata. Their structure specifics are not specified. gives a detailed explaination of the use of the metadata defined, all the semantic information, pre and post processing details at various nodes. defines NSH metadata Type 2 TLVs such as forwarding context, subscriber/user info, tenant, application ID, content type, ingress network information, flow ID, source and/or destination groups, universal resource identifier (URI). Some of these TLVs are defined in other documents, like App ID, Context ID in . Also for Application ID, even though the document references , seems to mean Classification Engine ID and Selector ID for the Application ID. The purpose of is to document syntactic structure of the TLVs for the purpose of setting up a registry of Type 2 metadata. No other additional information about the metadata processing is within the scope of this document. The document mentions no use cases in which the TLVs defined are needed. An implementer will need to refer to other documents to understand the exact behavior for handling those contexts. This document does not define the normative behavior for processing the defined TLVs. This is key for interoperability. does not define any Type 1 or Type 2 meta data TLVs, viewing such meta data as conveying preprocessing information about the packet, this document attempts to formally defines the post processing information. To that end, it defines a vocabulary and information model for metadata. The document gives metadata information model example definitions for routing domain, IP endpoint, flow and traffic policy indication.

Some options are discussed below for processing NSH TLVs: List the structure of meta data in one single document as a registry. The document is not supposed to contain any post processing information. attempts this choice for some Type 2 TLVs. Currently there is no such document for Type 1 TLVs. Note that in the case of keeping a registry document, it is not clear how the post processing behavior (normative or optional) will be specified for the TLVs. One option is to keep such information in separate document. If such a strategy is adopted then the advantages obtained from documenting all TLVs in one document disappears because the implementers would need to consult many documents instead of only one. All documents defining new meta data Type 1 and Type 2 TLVs are treated individually for standardization. This approach has the advantage of keeping all meta data Type 1 and Type 2 TLVs in separate and dedicated documents together with all the information that the implementers may need. This could be a strong positive especially if we consider the fact that the meta data are being defined for very many use cases and scenarios. It is unlikely that one implementer would need to implement a large number of these TLVs, thereby defeating the need for combining them in a single document. Together with choice 1 above, while combining all TLVs in one document, it could be possible to keep post processing information related to the meta data can be considered individually for standardization. Together with choice 2 above, Type 1 TLVs can combined in one document but all Type 2 TLVs can be considered individually in separate dedicated documents. A document intended to keep a registry of all TLVs can be an informational document. Companion documents defining semantics of Type 1 and Type 2 metadata needs to be standard track in order to take the recommendations on processing the data into effect. Another issue is the importance of Type 1 metadata and Type 2 metadata. It seems to be difficult to argue that Type 1 metadata is more important. The metadata defined in is a good example as it can be defined either as Type 1 or Type 2. The same considerations could possible be made for other documents. It is recommended that the metadata defined be given serious consideration as to the merit of the use case that needs the metadata to the Service Function Chaining rather than syntactic considerations of Type 1 or Type 2.

None.

This document does not introduce any security issues.

TBD.