Traffic Steering Considerations for SR-MPLS and SRv6

Introduction 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) using destination address matching and flow characteristic matching.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here.

SR Policy:: A unidirectional path from a head-end to a tail-end, instantiated either as an SRv6 TE Policy or an SR-MPLS TE Policy.
SRv6 SID / MPLS Label:: The identifier used in the data plane. In SRv6, it is a 128-bit IPv6 address (SID); in SR-MPLS, it is a 20-bit label.
BSID / Binding Label:: An advertisement that allows an SR Policy to be referenced as a single segment (or label) by other nodes. In SRv6, this is the BSID; in SR-MPLS, this is the Binding Label.
Color / Endpoint:: Attributes used to identify a specific SR Policy. In SRv6, a Policy is identified by (Color, Endpoint). In SR-MPLS, the Color extended community is similarly used for policy selection.

General Traffic Steering Architecture Traffic steering towards an SR Policy can be categorized into two primary types:

Steering based on Destination Address: Matching the packet's destination IP address (for IPv6) or the destination prefix (associated with a label) to a specific route.
Steering based on Flow Characteristics: Identifying traffic based on Layer 2 attributes (802.1p), Layer 3 attributes (DSCP), or local service identifiers (Service-class/TE-class) before mapping them to an SR Policy.

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 Steering Based on Destination Address Traffic can typically be steered based on the destination address by matching traffic destination via static routing, PBR, or BGP route import.

BSID / Binding Label Based Steering 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.

SRv6 Implementation:: The packet's destination IPv6 address is set to the BSID. Upon receipt, the head-end decapsulates the packet and processes it through the SRv6 TE Policy associated with that BSID.
SR-MPLS Implementation:: The packet's top MPLS label is set to the Binding Label. Upon receipt, the head-end swaps the top label and processes the packet through the SR-MPLS TE Policy associated with that label.

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.

| RouterD | (EP: 4::4 or 4.4.4.4) +---------+ +---------+ ^ | Dest Addr: 1000::1 (SRv6) or Top Label: 200 (SR-MPLS) ]]>

Color and Endpoint Based Steering 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.

SRv6 Scenario:: BGP advertises prefix 1::1/128 with Next-Hop 4::4 and Color 100. Device checks for an SRv6 TE Policy with Endpoint = 4::4 and Color = 100.
SR-MPLS Scenario:: BGP advertises prefix 1.1.1.0/24 with Next-Hop 4.4.4.4 and Color 100. Device checks for an SR-MPLS TE Policy where the head-end resolves the Next-Hop to a tunnel endpoint and the policy carries the Color 100.

IGP Shortcut Based Steering 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.

Traffic Steering Based on Flow Characteristics This method identifies traffic based on packet attributes independent of the destination address and steers it to an SR Policy.

DSCP-based Steering 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) .

Configuration Logic:: Create a Policy Group for a specific Endpoint. Define a mapping: DSCP Value X -> Color Y. Configure a Tunnel Policy that matches the destination and applies the Policy Group.
Processing:: The ingress router matches the incoming packet's DSCP, maps it to a Color, selects the corresponding SR Policy (SRv6 or SR-MPLS), and encapsulates the packet accordingly.

802.1p-based Steering 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.

Service-class-based Steering 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.

TE-class-based Steering 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.

Traffic steering via BGP-FlowSpec 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.

Steering by BGP FlowSpec , Color 100, Endpoint 4::4, SID List SRv6 Policy 2: BSID <2000::1>, Color 200, Endpoint 4::4, SID List +------------------+ | 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 / | \ / | \ +-/------+ | +------\-+ |RouterA | <--------+ |RouterD | EndPoint: 4::4 +-\\------+ +------/-+ SRv6 Policy 2: \ / BSID<2000::1> \ / Color 200 +-\-------+ +-------/-+ Endpoint 4::4 |RouterE |--------------------|RouterF | SID List +---------+ +---------+ ]]>

Security Considerations 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.

SRv6 Specific:: Protection against unauthorized SRH manipulation and source address spoofing.
SR-MPLS Specific:: Protection against label spoofing and unauthorized label space access.
FlowSpec:: Ensure strict validation of FlowSpec updates to prevent denial-of-service attacks or misrouting.

IANA Considerations 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.