Metadata in SR Service Programming Considerations
draft-liu-spring-sr-sfc-metadata-00

Abstract

This document discusses different ways to carry metadata in SR service programming data plane.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 2, 2020.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Metadata in SRV6 Data Plane
• 3. Metadata in SR-MPLS Data Plane
• 3.1. Indicating Metadata in User Data Packets
• 3.2. Per Packet Metadata
• 4. Security Considerations
• 5. IANA Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

Service Function Chaining (SFC)[7665] provides support for the creation of composite services that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification. [I-D.ietf-spring-sr-service-programming] describes how a service can be associated with a SID and how to achieve service funtion chaining in SR-enabled MPLS and IPv6 networks. In the context of Service Function Chaining, metadata provides contextual information about the data packets which traverse a Service Function Chain.

Metadata is defined in [RFC7665]as providing "the ability to exchange context information between classifiers and SFs, and among SFs."

This document discusses ways to carry metadata in SR based SFC data plane, including SRv6 and SR-MPLS.

2. Metadata in SRV6 Data Plane

[I-D.ietf-spring-sr-service-programming] defines two SRv6 TLVs, Opaque Metadata TLV and NSH Carrier TLV, which are used to carry metadata in SRH. Another way is to carry metadata via a separate header. [I-D.li-6man-enhanced-extension-header] defines a new IPv6 extension header called metadata header, and [I-D.li-6man-ipv6-sfc-ifit] defines a SFC Service Metadata Option in metadata header.

3. Metadata in SR-MPLS Data Plane

Currently there is no specific solution for MPLS-SR to carry metadata.

3.1. Indicating Metadata in User Data Packets

[RFC8595]chapter 12 describe how metadata is associated with user data packets, when using an MPLS encoding of the logical representation of the NSH. A similar approach can be used in SR-MPLS.

For a better understanding, the main points of the scheme will be described below.

				 -------------------
				~   Other Labels   ~
				+-------------------+
				|   Extension = 15  |
				+-------------------+
				|      MLI=16       |
				+-------------------+
				|  Metadata Label   |
				+-------------------+
				~       Other       ~
				|      Metadata     |
				~   Label Triples   ~
				+-------------------+
				|                   |
				~      Payload      ~
				|                   |
				 -------------------
			

Figure 1: The MPLS SFC Label Stack with Metadata Label

The Extension Label (value 15) is called special-purpose label [RFC7274].

An extended special-purpose label called the Metadata Label Indicator (MLI) (value 16) is defined in [RFC8595]to indicate the presence of the Metadata Label.

The Metadata Label (MLI) value is an index into a table of metadata that is programmed into the network using in-band or out-of-band mechanisms.Therefore, the metadata itself is not carried with the user data packets.

3.2. Per Packet Metadata

The method in section 3.1 can only be used for carrying metadata that is "per-SFP" or "per-flow" [RFC8393], but cannot support "per-packet" metadata, where the metadata must be carried on each data packet.

This document defines how "per-packet" metadata fields are carried with the SR-MPLS encapsulation.

The metadata fields are defined in figure 2 and figure 3, where:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Extension Label = 15                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MD   Indicator Label                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MD-Type    | Length        |    RESERVED                     |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |            Fixed-Length MD Context                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Type 0x1 MD Field

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Extension Label = 15                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  MD   Indicator Label                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+
   |     MD-Type    |     Length    |     Flags     | RESERVED     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //        Variable-Length  MD  Context                         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Type 0x2 MD Field

The Extension Label (value 15) is called special-purpose label [RFC7274].

MD Indicator Label (value TBA1) is used to indicate the presence of the metadata field in the SR-MPLS header.

Fixed-Length MD Context: 16-bytes field to carry metadata.

Variable-Length MD Context: a list of Service Metadata TLV [RFC8300] for NSH MD Type 2 [RFC8300].

It should be noted that MD-Type cannot be 0x4 or 0x6 to prevent the incorrect ECMP [RFC4928].

An example of metadata carrying the in SR-MPLS header with user data packet is shown in Figure 4.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                     Other labels                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Packet as shown in Figure 2 or Figure 3        |
+---------------------------------------------------------------+
|                 Payload(User Data Packet)                     |
+---------------------------------------------------------------+

Figure 4: Metadata Field with User Data Packet

Nodes that care about metadata need to read all the labels in the current label stack to find the corresponding MD Indicator Label and the metadata context behind it.

The packet can also carry metadata without payload. In this case, it can be used in combination with the method mentioned in section 3.1.The MD can carry an index, which can be the same value as the metadata label in 3.1.In this way, the corresponding metadata table can be found through this index.

4. Security Considerations

The security considerations of SR-MPLS are discussed in [RFC8660].

5. IANA Considerations

TBD

6. References

6.1. Normative References

6.2. Informative References

Author's Address