|Internet-Draft||SR with MPLS Extension Header||November 2022|
|Song||Expires 20 May 2023||[Page]|
- Network Working Group
- Intended Status:
- Standards Track
Segment Routing with MPLS Extension Header
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:¶
- The SID label stack may be deep, which can hurt the forwarding performance when the bottom of stack needs to be accessed or deep packet inspection needs to be performed. For example, network load balancing based on entropy label [RFC6790] or IP header, and other network services such as In-situ OAM [I-D.ietf-ippm-ioam-data], rely on headers deeply embedded in a packet. A deep MPLS label stack is unfavorable in such occasions.¶
- While the compactness of an MPLS label helps to reduce the header overhead, it leaves no room to encode extra information other than SID. Because of this, a noticeable missing feature of SR-MPLS is the network programming [RFC8986]. Network programming is a powerful feature of SRv6. It enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Obviously, it is preferred for SR-MPLS to support the same feature as well.¶
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.¶
The format of the extension header for the SID list, or the Segment Routing Header (SRH), is shown in Figure 2.¶
The meaning of the fields in an SRH is as follows:¶
- As defined in [I-D.song-mpls-extension-header].¶
- As defined in [I-D.song-mpls-extension-header].¶
- Segment Count:
- 8-bit unsigned integer for the number of SIDs in the segment list.¶
- Segment Pointer:
- 8-bit index (zero based) of the current SID in the segment list.¶
- The i-th 20-bit SID. SID is the first segment of the path.¶
- FUNCT and ARGS[i]:
- The i-th 108-bit instructions and parameters for network programming at the i-th segment.¶
- Optional Type-Length-Value, TBD.¶
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 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.¶
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-17, , <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-data-17.txt>.
- Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Network Actions Framework", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-fwk-02, , <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-fwk-02.txt>.
- Guichard, N. and J. Tantsura, "Integration of Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)", Work in Progress, Internet-Draft, draft-ietf-spring-nsh-sr-11, , <https://www.ietf.org/archive/id/draft-ietf-spring-nsh-sr-11.txt>.
- Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr-service-programming-06, , <https://www.ietf.org/archive/id/draft-ietf-spring-sr-service-programming-06.txt>.
- Song, H., Zhou, T., Andersson, L., Zhang, Z. J., and R. Gandhi, "MPLS Network Actions using Post-Stack Extension Headers", Work in Progress, Internet-Draft, draft-song-mpls-extension-header-11, , <https://www.ietf.org/archive/id/draft-song-mpls-extension-header-11.txt>.
- Kompella, K., Drake, J., Amante, S., Henderickx, W., Yong, L., and RFC Publisher, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, , <https://www.rfc-editor.org/info/rfc6790>.
- Halpern, J., Ed., Pignataro, C., Ed., and RFC Publisher, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, , <https://www.rfc-editor.org/info/rfc7665>.
- Quinn, P., Ed., Elzur, U., Ed., Pignataro, C., Ed., and RFC Publisher, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, , <https://www.rfc-editor.org/info/rfc8300>.
- Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., Shakir, R., and RFC Publisher, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
- Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., Shakir, R., and RFC Publisher, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, , <https://www.rfc-editor.org/info/rfc8660>.
- Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., Voyer, D., and RFC Publisher, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://www.rfc-editor.org/info/rfc8754>.
- Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., Li, Z., and RFC Publisher, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.