SRv6 for Multipath Traffic Engineering

SRv6 for Multipath Traffic Engineering HPE

Sy. No. 192, Whitefield Road, Mahadevapura Bengaluru Karnataka 560048 India abhishek.chakraborty.ietf@gmail.com

HPE

Sy. No. 192, Whitefield Road, Mahadevapura Bengaluru Karnataka 560048 India jayant.agarwal.ietf@gmail.com

HPE

1133 Innovation Way Sunnyvale CA 94089 United States of America vishnupavan.ietf@gmail.com

Ciena

Ottawa Canada ssivabal@ciena.com

Routing SPRING SRv6 Multipath Traffic Engineering MPTE Segment Routing DAG A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that enables weighted load balancing of unicast traffic across a constrained set of paths optimized for an objective. This document is informational and describes one realization approach for applying SRv6 semantics to MPTE, based on the Multipath Traffic Engineering as described in Internet-Draft (draft-kompella-teas-mpte). It summarizes associated procedures, lifecycle, management, and forwarding behavior. This document applies existing SRv6 architecture and semantics to MPTE without defining new SRv6 Endpoint Behaviors or signaling protocols. It focuses on data-plane realization using existing forwarding instructions.

Introduction The notions of Multipath Traffic Engineering (MPTE) and an MPTE Directed Acyclic Graph (MPTED) tunnel are introduced in . MPTE SRv6 extension points are described in companion documents and aligned here for realization context. This document describes an approach in which each MPTED uses a unique DAG Locator and a unique DAG SID as SRv6 forwarding context to program and operate MPTE junction state. In this approach, transit junctions (non-penultimate hops) forward traffic using IPv6 forwarding with weighted ECMP next hops, penultimate-hop junctions terminate the DAG SID, ingress nodes encapsulate traffic with DAG SID and service SID, and egress nodes perform service handling. The approach ensures there are not two SRv6 SID terminations at a single node. The forwarding semantics in this approach do not require additional SRv6 encapsulation at transit junctions. This approach does not change or redefine existing SRv6 semantics and does not define new SRv6 forwarding instructions. It uses existing SRv6 architecture in an MPTE context. This approach also considers inter-domain use cases. describes an approach for realizing MPTE in Segment Routing networks using SR Policy and Binding SID (BSID) constructs at each junction node, managed by a centralized controller. That approach is general to SR and applies to both SR-MPLS and SRv6 data planes. When a globally consistent BSID value is used across all junction nodes in , this may appear structurally similar to the DAG Locator concept in this document, as both associate a single per-DAG identifier across junction nodes. However, the two constructs differ fundamentally in forwarding behavior: in , each transit junction resolves the BSID to invoke a per-junction SR Policy, whereas in this document, transit junctions perform plain IPv6 forwarding on the DAG Locator prefix and do not execute any Endpoint Behavior at transit nodes. in Section 3.9, SRv6-Tunnel describes the Egress Address Block (EAB) approach which uses an EAB address from a dedicated non-IGP-advertised SRv6 Locator at the egress. Transit nodes forward packets toward the EAB using standard IPv6 forwarding on signaling-programmed routes, without performing any SRv6 Endpoint Behavior. The DAG Locator concept in this document shares a related characteristic: like the EAB, it uses a privately scoped Locator that is absent from the IGP, with transit nodes performing plain IPv6 forwarding on signaling-programmed routes. This document contributes an SRv6-native realization path for MPTE that is intended to align with ongoing WG direction and operational needs. Each MPTED uses a unique DAG Locator and a unique DAG SID as SRv6 forwarding context to program and operate MPTE junction state. This realization leverages native IPv6 forwarding semantics at transit junctions to forward on a DAG Locator prefix with weighted ECMP and SRv6 semantics at penultimate-hop junctions to terminate a DAG SID. This approach natively supports multiple egress nodes within a single MPTED. No Binding SIDs or per-junction SR Policies are required, resulting in simpler per-node state and avoiding additional SRv6 encapsulation at transit junctions.

Requirements Language 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. Lowercase uses of these words are not to be interpreted as BCP 14 normative requirements.

Terminology This document reuses terminology from , , , and .

DAG Locator:: A unique SRv6 Locator allocated for a specific MPTED within a domain. This Locator represents the per-DAG transport context used by transit junctions (non-penultimate hops) for IPv6 forwarding with weighted ECMP next hops according to the DAG's signaled junction state.
DAG SID:: A unique SRv6 SID allocated for a specific MPTED, used for DAG termination semantics at penultimate-hop junctions. In this realization, DAG SID behavior is equivalent to END.X with Next-C-SID, PSP & USD processing semantics where applicable , with weighted ECMP next hops according to the DAG's signaled junction state.
Domain:: A network administrative domain within which DAG Locators and DAG SIDs are unique and privately scoped, consistent with Segment Routing Architecture concepts.
Allocation Function:: A logical function that owns SRv6 block space for MPTED use and allocates unique DAG Locator and DAG SID values on request from the MC.

Scope and Design Principles This document describes one realization approach for applying SRv6 semantics to MPTE and summarizes associated procedures, lifecycle, management, and forwarding behavior. This document does not define:

a new SRv6 Endpoint Behavior,
signaling protocol specific encodings for RSVP-TE, PCEP, BGP, or other signaling families,
MPTE control-plane role behavior, DAG computation procedures, or signaling procedures defined by and companion drafts.

Overview of MPTET-SRv6 Functional Entities

Allocation Function The Allocation Function is a logical entity that allocates and manages the DAG Locator and DAG SID. It is usually co-located with the MC for operational simplicity, or MAY be implementation-specific and located elsewhere. The MC requests dynamic allocation of unique DAG Locator and DAG SID values for each DAG and, optionally, each DAG version. The mechanisms used for communication between MC and Allocation Function are out of scope.

MPTE-DAG Block Each Allocation Function is assigned one or more unique SRv6 block(s), referred to in this document as DAG Blocks. It is RECOMMENDED to assign separate SRv6 blocks to each Allocation Function for operational simplicity, and to use those blocks only for MPTED purposes. Using best-effort or Flex-Algo SRv6 blocks for DAG Locator/SID allocation MAY create loops and MAY raise security concerns if stale or inconsistent state is not cleaned up properly. DAG blocks are private to a domain and MUST NOT be advertised to other domains by any means. The same DAG Block can be reused by another domain. If every ingress behaves as MC and each MC is accompanied by an Allocation Function, two deployment options are common: (1) each MC SHOULD have its own unique DAG Block, or (2) multiple MCs MAY share a common DAG Block with coordinated allocations. The choice depends on operational and scaling requirements.

DAG Locator and DAG SID For each MPTED, the implementation MUST associate one DAG Locator and one DAG SID that are unique within the domain. describes one approach to allocation and describes the corresponding programming workflow. An implementation MAY allocate a new DAG Locator and DAG SID per DAG version, or MAY reuse the same values across versions when safe update behavior is preserved. A unique DAG Locator and DAG SID per DAG provides clear DAG identification inside a domain and improves operational debugging and tracing. DAG Locators and DAG SIDs in this realization are private transport identifiers and MUST NOT be advertised in IGP or other routing protocols. These identifiers MAY be carried only by the signaling protocol used to program junction nodes for the DAG.

Support for MC Roles As described in , the MPTED Computer (MC) is the entity that computes the MPTED. The MC can be either:

an ingress node, or
a Path Computation Element (PCE).

This realization supports both MC models and does not constrain its functional placement. TO, MC, and SS may co-reside on one node or be distributed across multiple nodes, consistent with the base MPTE architecture. The residence and placement model of the MC influences the operational choice of signaling protocol family () used to program DAG junctions.

Support for Signaling Protocols This document aligns with the signaling protocol direction of and supports mapping SRv6 MPTE signaling to the same companion protocol families:

RSVP-TE extensions,
PCEP extensions,
BGP-based signaling,
other MPTE-compatible signaling specifications.

Protocol-specific details for these signaling families are specified in , , and . Independently of the chosen signaling protocol, the signaling exchange is expected to carry SRv6 context (for example DAG Locator/SID context) required by this realization. This document does not define protocol-specific signaling procedures.

Working Principles This section describes the end-to-end operational flow of the SRv6 MPTE realization defined in this document. The working principles are organized around the following functional roles.

the MC computes the MPTED topology and requests a unique DAG Locator and DAG SID from the Allocation Function;
the Signaling Source distributes per-junction programming intent (PHOP/NHOP state, DAG Locator/SID context) to each node in the DAG;
ingress nodes encapsulate traffic using the DAG SID as the outer destination address with service SID context in the SRH;
transit junctions (non-penultimate hops) perform plain IPv6 forwarding on the DAG Locator prefix with weighted ECMP next hops, invoking no SRv6 Endpoint Behavior;
penultimate-hop junctions terminate the DAG SID using END.X with PSP & USD semantics and forward toward egress per DAG NHOP intent; and
egress nodes perform service SID handling without requiring any per-DAG transport-route state.

This realization uses only existing SRv6 behaviors and does not define new SRv6 Endpoint Behaviors.

MPTED Computer The MPTED Computer (MC) computes the MPTED and its per-junction PHOP/NHOP state according to . For each DAG (and optionally each DAG version), the MC requests the Allocation Function to provide a unique DAG Locator and DAG SID. The SRv6 realization programming intent derived from the DAG result is as follows:

DAG Locator context is used for non-penultimate transit junction programming,
DAG SID context is used for penultimate-hop termination programming,
no DAG transport Locator/SID programming is required at egress,
ingress tunnel encapsulation destination is set to DAG SID with service SID stacking in SRH.

The resulting junction programming intent is provided to the Signaling Source for distribution. Detailed MPTE computation workflow and signaling procedures are out of scope in this document. These procedures and workflows are specified in companion MPTE documents.

Allocation Function The Allocation Function allocates and manages DAG Locator and DAG SID values from assigned DAG block space. The Allocation Function MAY be placed on any node or controller entity. For operational simplicity, co-location with the MC is RECOMMENDED. The Allocation Function returns the DAG Locator/DAG SID context needed for signaling and forwarding realization. The mechanisms used for communication between MC and Allocation Function are out of scope.

Signaling Source The Signaling Source distributes the MC-provided per-junction intent using signaling procedures defined by , , , and . For SRv6 realization, the signaling payload carries DAG identity/version and SRv6 context (DAG Locator and DAG SID), together with PHOP/NHOP relationships needed by receiving junction nodes. The base signaling workflow remains as defined in ; this realization only identifies SRv6-specific context used by programmed nodes. Protocol-specific signaling procedures remain out of scope in this document.

Ingress Programming Ingress programming installs tunnel encapsulation context for the selected MPTED:

outer encapsulation destination is set to the DAG SID,
SRH carries service SID context,
forwarding next hops are programmed per MPTE DAG intent.

Ingress does not require DAG-specific transit SID stacking for in-domain transport beyond the DAG Locator/SID realization described in this document.

Transit Junction Programming Transit junctions (non-penultimate hops) are programmed with DAG Locator route state toward MPTE-programmed NHOPs. Transit junctions perform IPv6 forwarding for this transport context with weighted ECMP next hops. They do not perform DAG SID termination in this realization.

Penultimate Junction Programming Penultimate-hop junction programming installs DAG SID termination state with MPTE-programmed NHOPs toward egress. Upon match of the terminating DAG SID context, the node applies signaled SRv6 Endpoint Behavior and forwards toward egress according to DAG NHOP intent.

Egress Programming Egress programming does not require DAG transport-route state in this realization. Egress performs service handling based on service SID context and local service forwarding behavior.

Versioning and Operational Behavior Implementations MAY either:

update PHOP/NHOP state while reusing an existing DAG Locator/SID, or
allocate new DAG Locator/SID values for a new DAG version and perform make-before-break.

In all cases, signaling and forwarding state MUST remain consistent for DAG identity, version, and DAG Locator/SID context.

Optimization and Deployment Simplification Approaches Deployments MAY simplify operations while preserving the working principles described in this section. Two approaches are common:

Shared DAG Block architecture, where multiple logical Allocation Functions share a common DAG Block with coordinated allocations.
Minimal DAG Block with per-allocation function Locator ownership, where a minimal set of DAG Blocks is shared across all logical Allocation Functions, each logical Allocation Function is assigned a unique DAG Locator, and each logical Allocation Function allocates function codes from the shared DAG Block in its local scope.

For the second approach, additional programming semantics will be clarified in a future version of this draft.

Forwarding Semantics defines functional roles and programming intent. This section defines the resulting packet-forwarding behavior at each node type.

Ingress Behavior Ingress encapsulates packets into the SRv6 transport context associated with the selected MPTED. The outer IPv6 header destination is the DAG SID, and SRH carries service SID context. Ingress forwarding uses MPTE-programmed next hops for the DAG.

Transit Junction Behavior Transit junctions (non-penultimate hops) forward packets by IPv6 lookup on DAG Locator route context, performing IPv6 forwarding with weighted ECMP next hops. No DAG SID termination is performed at these transit nodes. Forwarding follows MPTE-programmed NHOP sets.

Penultimate Junction Behavior Penultimate-hop junctions match the DAG SID termination route, apply the signaled Endpoint Behavior, and forward packets toward egress NHOPs programmed by MPTE. This model keeps DAG SID termination at penultimate context and avoids requiring additional in-domain DAG-specific SID stacking. This model also avoids two terminations at any node in a domain.

Egress Behavior Egress receives traffic after DAG transport realization and performs service SID handling. Service SID semantics follow SRv6 Network Programming including DT4, DT6, End.X behaviors and compressed SRv6 Segment List processing. Egress does not require per-DAG transport-route programming for this realization model.

MTU Considerations Implementations SHOULD account for SRv6 encapsulation overhead (outer IPv6 header, SRH, and service SID context) when programming ingress encapsulation and service transport. Path-MTU validation SHOULD ensure that realized MPTED forwarding does not introduce unintended fragmentation behavior. This realization does not require additional SRv6 encapsulation insertion at transit and penultimate nodes beyond ingress encapsulation behavior.

Service Mapping Considerations Service mapping can be implemented in different ways and is outside the strict scope of this document. One possible model is to map services onto an SRv6 TE policy that triggers intent-based MPTED computation and signaling. Other mapping approaches are equally valid.

Inter-AS Considerations For inter-AS or inter-domain end-to-end MPTET realization, the next-domain transport SID can be placed in the SRH to steer traffic across domain boundaries. Each domain maintains private DAG Locator/SID spaces. Inter-domain exchange SHOULD use explicitly intended interconnect SIDs or transport SIDs without leaking private DAG Locator Blocks. Full inter-domain forwarding mechanics and state synchronization requirements are subject to further clarification and will be detailed in a future revision of this document.

Interoperability Considerations Interoperable behavior requires consistent interpretation of DAG identity/version and DAG Locator/SID context by all participating nodes. Interoperability of SRv6 forwarding behavior follows , , and .

IANA Considerations This document has no IANA actions.

Security Considerations Security considerations from apply. SRv6 and SRH security considerations in , , and apply. Because DAG Locator/SID spaces are private and signaling-scoped, implementations SHOULD enforce strict authorization and policy checks on junction-programming messages and SHOULD validate stale-state cleanup for safety.

Contributors TBD

Normative References Informative References

Deployment Example (Provisioning, Signaling, and Forwarding) This appendix illustrates one deployment realization aligned with the approach in this document.

Topology For simplicity, each ingress acts as MC and TO/SS for DAGs sourced from that ingress.

Example DAG Computation For a request sourced at Ingress1 and destined to Egress1, MC1 computes:

JCT Ingress1: PHOPs = none, NHOPs = {T1}
JCT T1: PHOPs = {Ingress1}, NHOPs = {T2}
JCT T2: PHOPs = {T1}, NHOPs = {T3, T4}
JCT T3: PHOPs = {T2}, NHOPs = {PHP1}
JCT T4: PHOPs = {T2}, NHOPs = {PHP2}
JCT PHP1: PHOPs = {T3}, NHOPs = {Egress1}
JCT PHP2: PHOPs = {T4}, NHOPs = {Egress1}
JCT Egress1: PHOPs = {T3, T4}, NHOPs = none

MC1 requests allocation and receives, for example:

DAG Locator: 2001:db8:1::/48
DAG SID: 2001:db8:1:e001::
SID structure metadata: BL 32, LNL 16, LFL 16, AL 64
Endpoint behavior: END.X with Next-C-SID, PSP & USD

Example Junction Signaling Intent For DAG1 version 1:

Ingress1: install encapsulation context with destination address 2001:db8:1:e001:: and service SID context in SRH ( ).
T1/T2/T3/T4: install DAG Locator route 2001:db8:1::/48 with signaled NHOP sets for forwarding at transit junctions (non-penultimate hops) ().
PHP1/PHP2: install terminating route 2001:db8:1:e001::/80 with END.X with Next-C-SID, PSP & USD and NHOP to Egress1 for penultimate behavior (). This /80 route performs DAG SID termination with SRH operation if required. The same route with 2001:db8:1:e001::/64 prefix is also installed to handle termination with END.X with Next-C-SID, PSP & USD and no SRH operation.
Egress1: no per-DAG transport-route programming is required; service SID handling is applied ().

SID Structure Example In this deployment example, compressed SRv6 SID is used with: The same approach works with Traditional SRv6 SIDs. In that case, the route prefixes and prefix-length follow Traditional SID requirements.

Example Route Programming Ingress1 tunnel route example:

destination: Egress1 loopback prefix
tunnel encapsulation DA: 2001:db8:1:e001::
outgoing next hop: toward T1

Transit route example:

2001:db8:1::/48 -> NHOP set per DAG signaling (IPv6 forwarding with weighted ECMP at transit junctions (non-penultimate hops))

Penultimate route examples:

2001:db8:1:e001::/80 -> NHOP Egress1, Endpoint Behavior END.X with Next-C-SID, PSP & USD (DAG SID termination at penultimate nodes, SRH operation, forward on DAG programmed NHOPs)
2001:db8:1:e001::/64 -> NHOP Egress1, Endpoint Behavior END.X with Next-C-SID, PSP & USD (DAG SID termination at penultimate nodes, forward on DAG programmed NHOPs)

Packet Walk Example Ingress1 transmits: T1/T2/T3/T4 perform IPv6 forwarding with weighted ECMP and TTL decrement without DAG SID termination. PHP1/PHP2 match 2001:db8:1:e001::/80, execute termination behavior, update SRH state, and forward: Egress1 applies service SID processing (for example DT4 Behavior) and forwards to service table. No additional in-domain DAG-specific SRv6 SID stacking is required.

Update Behavior Example If T2-T4 fails, implementation may temporarily steer only via T3 while DAG1 version2 is signaled. If a better T2-T4 path appears, DAG1 version3 may include additional T4 adjacency entries; updated junction state is signaled and applied with implementation-specific make-before-break behavior.

Inter-AS Example For end-to-end multi-domain realization, ingress may include a next-domain transport SID in SRH. ] [payload] ]]> Private DAG Locators are not leaked between domains.

Acknowledgments The authors would like to acknowledge Shraddha Hegde, Bharath R and Rajesh Shetty for their valuable inputs.