| Internet-Draft | Traffic Steering for SR-MPLS and SRv6 | November 2026 |
| Cheng, et al. | Expires 6 May 2027 | [Page] |
This document describes traffic steering mechanisms for both Segment Routing over IPv6 (SRv6) and Segment Routing over MPLS (SR-MPLS). It provides an overview of the main traffic steering methods applicable to both architectures, including steering based on destination addresses (BSID/Binding Label, Color/Endpoint, IGP Shortcut) and flow characteristics (DSCP, 802.1p, Service-class, TE-class, BGP-FlowSpec). Furthermore, it discusses the recommended traffic steering methods for various typical scenarios, highlighting the interoperability and specific handling differences between SR-MPLS and SRv6 where necessary.¶
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 5 May 2027.¶
Copyright (c) 2026 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.¶
The general purpose of traffic steering is to optimize the allocation and transmission of network resources, ensure a balanced distribution of network traffic, improve network performance, reduce congestion, and increase available bandwidth to provide users with a better network experience.¶
Segment Routing (SR) has emerged as a key technology for traffic engineering in modern networks. SR can be instantiated over the MPLS data plane (SR-MPLS) or the IPv6 data plane (SRv6). While the underlying data planes differ, the control plane mechanisms for traffic steering exhibit significant convergence.¶
This document outlines the main traffic steering methods for both SRv6 and SR-MPLS. It describes how traffic can be steered into SR Policies (SRv6 TE Policy or SR-MPLS TE Policy) [RFC9256] using destination address matching and flow characteristic matching.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Traffic steering towards an SR Policy can be categorized into two primary types:¶
The means of traffic steering include using static routing, employing Policy-Based Routing (PBR) policies, distributing routes through BGP, utilizing BGP-FlowSpec, and utilizing IGP-Shortcut.¶
Traffic can typically be steered based on the destination address by matching traffic destination via static routing, PBR, or BGP route import.¶
When a device receives a packet whose top label (in SR-MPLS) or top SID (in SRv6) matches the Binding Identifier of an SR Policy, the packet is forwarded according to that Policy.¶
BSID/Binding Label based steering is commonly used in stitching scenarios to reduce header overhead. For example, an SR Policy's BSID/Binding Label can be pushed into the Segment List/Label Stack of another SR Policy.¶
SRv6 Policy 1: BSID=1000::1, Color=100, EP=4::4, Path=B-C-D
SR-MPLS Policy 2: Bind Label=200, Color=200, EP=4.4.4.4, Path=E-F-D
+---------+ +---------+
| RouterB |--------------------| RouterC |
+---------+ +---------+
| |
| (Path B-C-D) |
v v
+---------+ +---------+
| RouterA | <--- Traffic ---> | RouterD | (EP: 4::4 or 4.4.4.4)
+---------+ +---------+
^
|
Dest Addr: 1000::1 (SRv6) or Top Label: 200 (SR-MPLS)
This is a fundamental method for steering traffic into SR Policies using BGP. The BGP protocol advertises a prefix route carrying a Color Extended Community. The device matches this Color and the Next-Hop (Endpoint) against locally configured SR Policies.¶
IGP Shortcut allows the IGP (IS-IS or OSPF) to automatically steer traffic to the best matching SR Policy without explicit BGP configuration for each prefix.¶
When an SR Policy (SRv6 or SR-MPLS) is established and Up, the head-end node generates a host route for the Policy's Endpoint and installs it in the forwarding table pointing to the SR Policy. If the policy goes Down, the route is withdrawn, and traffic falls back to SR BE (Best Effort) calculation.¶
This method identifies traffic based on packet attributes independent of the destination address and steers it to an SR Policy.¶
Packets are routed to an SR Policy based on the DSCP value in the IP header. This typically requires SR Policy Groups (a group of policies sharing the same Endpoint but different Colors) [I-D.ietf-spring-sr-policy-group].¶
Similar to DSCP, but uses the 802.1p priority field in the VLAN tag. The ingress node matches the incoming 802.1p value, maps it to a Color, and selects the corresponding SR Policy.¶
To ensure that all traffic packets can be steered, even if they do not carry DSCP or Dot1p information, the device introduces a local identification called "service-class".¶
The device maps the internal service-class to a Policy Color within an SR Policy Group. This mechanism applies to both SR-MPLS and SRv6.¶
Due to the limited length of the local identifier "service-class", some vendors have introduced the use of "TE class ID" as another local identifier. The TE class ID can have a maximum value of 65535.¶
The basic principle is to route packets to the corresponding SR Policy based on the TE class ID identifier. The TE-class is mapped to a specific Color within a Policy Group.¶
In the scenario illustrated in Figure 2, where a controller is present in the network, fine-grained traffic scheduling can be achieved by the controller distributing traffic steering rules. The controller utilizes BGP Flow-Spec (FS) to distribute rules to the head-end node. These rules can be matched based on the destination address or flow characteristics. By setting the action after matching, the controller can specify the Color attribute and next-hop address for the traffic, thereby achieving traffic steering. BGP FlowSpec enables global traffic scheduling with flexibility.¶
SRv6 Policy 1: BSID <1000::1>, Color 100, Endpoint 4::4,
SID List <B,C,D>
SRv6 Policy 2: BSID <2000::1>, Color 200, Endpoint 4::4,
SID List <E,F,D>
+------------------+
| Controller |
+------------------+
| FlowSpec route to Ingress:
| NLRI: Filter Rules
| Color: 100/200
| Nexthop: 4::4
v
SRv6 Policy 1: +---------+ | +---------+
BSID<1000::1> |RouterB |------)-------------|RouterC |
Color 100 +-/-------+ | +-------\-+
Endpoint 4::4 / | \
SID List<B,C,D> / | \
/ | \
+-/------+ | +------\-+
|RouterA | <--------+ |RouterD | EndPoint: 4::4
+-\\------+ +------/-+
SRv6 Policy 2: \ /
BSID<2000::1> \ /
Color 200 +-\-------+ +-------/-+
Endpoint 4::4 |RouterE |--------------------|RouterF |
SID List<E,F,D> +---------+ +---------+
As with any traffic engineering mechanism, security considerations regarding the injection of routes (via BGP or FlowSpec) and the manipulation of SR Headers (SRH for IPv6 or Label Stack for MPLS) apply.¶
This document makes no request of IANA. However, future extensions regarding specific Color mappings or new TLVs for SR-MPLS/SRv6 interworking may require IANA registry updates.¶