| Internet-Draft | SR with MPLS Extension Header | November 2022 |
| Song | Expires 20 May 2023 | [Page] |
This document describes an alternative approach to implement segment routing in MPLS networks with the use of a post-stack MPLS extension header under the MPLS network action framework. The new approach reduces the MPLS label stack depth and provide supports for advanced functions such as network programming similar to SRv6.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
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 20 May 2023.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Segment Routing (SR) [RFC8402] allows a node to steer a packet based on an ordered list of segments. It can be applied on an MPLS data plane (i.e., SR-MPLS) or an IPv6 data plane (i.e., SRv6). In SR-MPLS, each segment identifier (SID) is encoded in an MPLS label [RFC8660]. The SID list forms an MPLS label stack. Each hop will pop the top label from a packet's label stack and forward the packet based on the SID encoded in the label.¶
MPLS has a wide deployment base and SR-MPLS can be directly applied on an MPLS data plane without any change. Meanwhile, SR-MPLS's SID overhead is small and each SID in SR-MPLS is only 4 bytes.¶
However, SR-MPLS has several drawbacks:¶
In MPLS networks, MPLS Network Action (MNA) [I-D.ietf-mpls-mna-fwk] extends the MPLS label stack by supporting extra network actions encoded both in stack and post stack. The post-stack actions are encapsulated in MPLS extension headers [I-D.song-mpls-extension-header]. SR in MPLS can be implemented with an extension header. The new approach not only retains MPLS's advantages but also overcomes its drawbacks.¶
With the presence of MPLS extension header, the SID label stack is kept in an extension header. Only the current SID label is copied to the top of the MPLS label stack. An example for the packet format is shown in Figure 1.¶
0 31 +--------+--------+--------+--------+ - | SID Label | ^ +--------+--------+--------+--------+ | MPLS Label Stack | Post-stack MNA Indicator | | ~ ~ V +--------+--------+--------+--------+ - | HEH | NH=SR | ^ +--------+--------+--------+--------+ | | | | MPLS SR Extension Header ~ Segment Routing Header (SRH) ~ | | | V +--------+--------+--------+--------+ - | | ^ ~ Upper Layer Protocols/Payload ~ | Upper Layer Packet | | V +--------+--------+--------+--------+ -
The format of the extension header for the SID list, or the Segment Routing Header (SRH), is shown in Figure 2.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH=UL | HLEN | Segment Count |Segment Pointer|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID[0] | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FUNCT and ARGS [0] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID[n-1] | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FUNCT and ARGS [n-1] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Optional TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields in an SRH is as follows:¶
The operator is free to partition the FUNCT and ARGS field to encode the function and parameters at a segment.¶
The SR source node generates the SRH. The Segment Pointer field of the SRH is initialized to 0. The SRH is inserted into the MPLS packet as an MPLS extension header. The SID[0] in the SRH is copied into an MPLS label. The TTL field in the label is initialized to a configured value. The label is pushed to the top of the label stack. The packet is then forwarded based on the top label.¶
At each node, if the SID in the top label matches the local SID, the function associated with the SID in the SRH is executed. If there are still segment(s) left in the segment list (i.e., Segment Count > Segment Pointer + 1), then the Segment Pointer in the SRH is incremented by 1, and the SID pointed by the Segment Pointer is copied to the top label in the MPLS label stack. The TTL field in the top label is decremented by 1. The packet is then forwarded based on the top label.¶
If the current segment is the last segment, the top label is popped and the SRH extension header is deleted. The packet is then forwarded based on the header of the remaining packet.¶
The document [I-D.ietf-spring-sr-service-programming] describes how the SFC [RFC7665] can be achieved through SR-MPLS. Similarly, the Segment Routing with MPLS Extension Header can also realize the service chaining, with additional advantages over the previous proposal.¶
A noticeable issue of the SR-MPLS based SFC is its lack of metadata carrying capability. Metadata may be critical for message passing and information sharing between service functions. This drawback limits the applicability of SR-MPLS for SFC. In our solution, the metadata can be carried in the optional TLVs in the SRH.¶
Another document [I-D.ietf-spring-nsh-sr] proposes to integrate the SR and the NSH [RFC8300] to better support SFC, in which NSH provides a service plane and SR supports transport. Again, in our proposal, the NSH can be encapsulated into a TLV in the SRH.¶
This document shares the same security considerations with the SR-MPLS, network-programming, and SFC.¶
This document requires IANA to assign a new protocol number (TBA1) to indicate the SID list.¶
TBD.¶
TBD.¶