Internet-Draft SR with MPLS Extension Header November 2022
Song Expires 20 May 2023 [Page]
Network Working Group
Intended Status:
Standards Track
H. Song, Ed.
Futurewei Technologies

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.

Requirements Language

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].

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

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.

Table of Contents

1. Motivation

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 []. SR in MPLS can be implemented with an extension header. The new approach not only retains MPLS's advantages but also overcomes its drawbacks.

2. Segment Routing with MPLS Extension Header

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
   +--------+--------+--------+--------+  -

Figure 1: SR in MPLS with Extension Header

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                          ~
   |                                                               |

Figure 2: SRH Format

The meaning of the fields in an SRH is as follows:

As defined in [].
As defined in [].
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[0] 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.

3. Segment Routing Data Plane Processing

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.

4. Support SFC using SR with MPLS Extension Header

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.

5. Security Considerations

This document shares the same security considerations with the SR-MPLS, network-programming, and SFC.

6. IANA Considerations

This document requires IANA to assign a new protocol number (TBA1) to indicate the SID list.

7. Contributors


8. Acknowledgments


9. References

9.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.

9.2. Informative References

Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-17, , <>.
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Network Actions Framework", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-fwk-02, , <>.
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, , <>.
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, , <>.
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, , <>.
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, , <>.
Halpern, J., Ed., Pignataro, C., Ed., and RFC Publisher, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, , <>.
Quinn, P., Ed., Elzur, U., Ed., Pignataro, C., Ed., and RFC Publisher, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/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, , <>.
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, , <>.
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, , <>.
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, , <>.

Author's Address

Haoyu Song (editor)
Futurewei Technologies
2330 Central Expressway
Santa Clara,
United States of America