| Internet-Draft | SR based SFC Metadata | September 2021 |
| Liu | Expires 19 March 2022 | [Page] |
This document proposes methods to carry metadata in SR service programming with SR-MPLS data plane.¶
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 19 March 2022.¶
Copyright (c) 2021 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.¶
Service Function Chaining (SFC)[RFC7665] 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 function chaining in SR-enabled MPLS and IPv6 networks.¶
Metadata is defined in [RFC7665] as providing the ability to exchange context information between classifiers and SFs, and among SFs. In the context of Service Function Chaining, metadata provides contextual information about the data packets which traverse a Service Function Chain.¶
For service programming with the SR-MPLS data plane, [I-D.ietf-spring-sr-service-programming] proposes that a SRH inserted between the last MPLS label and the MPLS payload can be used as a metadata container. The SRH does not carry any segment but only the mandatory header fields required for transporting the metadata, which means a new header needs to be defined based on the SRH to carry the metadata. As for the indication the presence of metadata, [I-D.ietf-spring-sr-service-programming] provides two possible methods, one is to add the indication about the presence of metadata in the semantic of the service SIDs, another is to introduce a protocol identifier field within the MPLS packet as described in [I-D.xu-mpls-payload-protocol-identifier].¶
To summarize, there're requirements to carry metadata in SR service programming with SR-MPLS data plane and the methods need to be standardized.¶
To carry metadata in SR-MPLS service programming scenario, this document proposes how to utilize the existing mechanism, and considering the ongoing work in MPLS OPEN DT, a new method is introduced as well.¶
[RFC8595] provides method to realize SFC in an MPLS network by means of using a logical representation of the Network Service Header (NSH) in an MPLS label stack.¶
[RFC8595] chapter 12 describes how metadata is associated with user data packets or programmed in-band by introducing new eSPL and Metadata Label. As specified in [RFC8595], the methods can only be used for carrying metadata that is "per-SFP" or "per-flow" [RFC8393], but cannot support "per-packet" metadata, where the metadata needs to be carried with payload in each packets.¶
If it's not required to carry metadata and payload together in the packet, similar approaches MAY be used for SR-MPLS service programming.¶
The main ideas of the approaches are described in section 2.1.1 and section 2.1.2¶
+-------------------+
~ Other Labels ~
+-------------------+ ------------
| Extension = 15 |
+-------------------+
| MLI=16 | Metadata
+-------------------+ Label Triple
| Metadata Label |
+-------------------+ ------------
~ Other ~
| Metadata |
~ Label Triples ~
+-------------------+
| |
~ Payload ~
| |
+-------------------+
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 value is an index into a table of metadata that is programmed into the network using in-band or out-of-band mechanisms. The metadata itself is not carried in the packet.¶
If this method is used for SR-MPLS service programming, the Metadata Label Triples(i.e, <15,MLI, Metadata Label>) SHOULD be placed at the bottom of the label stack.¶
+-------------------+
~ Other Labels ~
+-------------------+
| Extension = 15 |
+-------------------+
| MPI=17 |
+-------------------+
| Metadata Label |
+-------------------+
| |
~ Metadata ~
| |
+-------------------+
An extended special-purpose label called the Metadata Present Indicator (MPI) (value 17) is defined in [RFC8595]to indicate the presence of the Metadata Label and the metadata field.¶
If this method is used for SR-MPLS service programming, the Metadata Label Triple(i.e, <15,MPI, Metadata Label>) SHOULD be placed in the bottom of the label stack.¶
Instead of user payload data, metadata is included after the bottom of the MPLS label stack. The metadata is formatted as a TLV as defined in [RFC8595].¶
The methods described above can only partially meet the requirements of carrying metadata in SR-MPLS service programming. How to carry the metadata in the user data packets still needs to be solved.¶
This section proposes a method to fulfill the requirements to carry metadata with/without the user payload in the packets for SR-MPLS traffic.¶
Note:There's a an ongoing work in MPLS OPEN DT to figure out the format and processing procedure of the indicator in the label stack and the data carried in/after the bottom of stack. So the method introduced in this section will be modified in the future version to follow the specification of the DT.¶
Firstly, an indicator in the label stack is needed to indicate the presence of metadata after the bottom of stack. This indicator may be an SPL or eSPL.¶
The metadata can be carried for SR-MPLS traffic between the last MPLS label and the MPLS payload, or it can also be carried after the BOS without the payload. In the latter case, the method introduced in section 2.1.2 are no longer necessary.¶
Two types of metadata for SR-MPLS service programming are required: fixed-length metadata and variable-length metadata.¶
The format of fixed-length metadata field is shown in 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Next Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Service Metadata |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 14.¶
Next Header: This field identifies the type of the header immediately following the metadata field¶
Service Metadata: 14-octet field to carry metadata.¶
The variable-length metadata is a container to carry Service Metadata in the form of Variable-Length Metadata as defined in [RFC8300] for NSH MD Type 2. The format is shown in figure 4, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
// Service Metadata //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The total length of the Variable-Length Metadata field.¶
Next Header: This field identifies the type of the header immediately following the metadata field¶
Service Metadata: a list of Service Metadata TLV as defined in [RFC8300] for NSH MD Type 2.¶
A potential requirement is to carry the service function path(SFP) identifier in the packets for SR-MPLS service programming. One possible solution is to carry it in the metadata, another is to carry in the label stack. This will discussed in future versions.¶
This document does not change the underlying security issues inherent in [I-D.ietf-spring-sr-service-programming].¶
TBD¶