Signaling RSVP-TE Tunnels on an SR-MPLS Forwarding Plane Using Adjacency Segment Identifiers
draft-beeram-spring-rsvp-sr-mpls-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Vishnu Pavan Beeram , Colby Barth , Andy Smith | ||
| Last updated | 2026-07-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-beeram-spring-rsvp-sr-mpls-00
SPRING V. P. Beeram
Internet-Draft C. Barth
Intended status: Standards Track HPE
Expires: 6 January 2027 A. Smith
Arrcus, Inc.
5 July 2026
Signaling RSVP-TE Tunnels on an SR-MPLS Forwarding Plane Using Adjacency
Segment Identifiers
draft-beeram-spring-rsvp-sr-mpls-00
Abstract
RFC 8577 introduced the concept of signaling RSVP-TE tunnels on a
shared MPLS forwarding plane using preinstalled "TE link labels".
Those labels are functionally equivalent to Segment Routing (SR)
Adjacency Segment Identifiers (Adj-SIDs) but are allocated and
distributed solely via RSVP-TE signaling.
This document extends RFC 8577 to use SR-MPLS Adjacency SIDs that are
advertised by the IGP as the forwarding-plane labels for RSVP-TE
tunnels. It restricts scope to per-link Adj-SIDs and defines the
signaling procedures and protocol extensions required to couple the
RSVP-TE control plane with the native SR-MPLS forwarding plane.
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 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 6 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Beeram, et al. Expires 6 January 2027 [Page 1]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Adjacency SID Requirements . . . . . . . . . . . . . . . . . 4
3.1. Adj-SID Persistence . . . . . . . . . . . . . . . . . . . 5
3.2. Per-Link Adj-SIDs . . . . . . . . . . . . . . . . . . . . 5
3.3. IGP Advertisement . . . . . . . . . . . . . . . . . . . . 6
4. RSVP-TE Tunnel Setup Using Adj-SIDs . . . . . . . . . . . . . 6
4.1. Adj-SID Discovery . . . . . . . . . . . . . . . . . . . . 6
4.2. Path Message Processing . . . . . . . . . . . . . . . . . 6
4.3. Resv Message Processing . . . . . . . . . . . . . . . . . 7
4.4. Label Stack Construction at Ingress . . . . . . . . . . . 8
5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 8
5.1. Binding SIDs as Delegation Labels . . . . . . . . . . . . 8
5.2. ETLD Computation . . . . . . . . . . . . . . . . . . . . 9
6. Protection Mechanisms . . . . . . . . . . . . . . . . . . . . 9
6.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 9
7. Bandwidth Admission Control . . . . . . . . . . . . . . . . . 10
8. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10
8.1. Attribute Flags: SR Forwarding Plane . . . . . . . . . . 11
8.2. RRO Label Sub-object Flag: SR Adj-SID . . . . . . . . . . 11
8.3. Constraining Adj-SID Selection via ERO . . . . . . . . . 12
9. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . 13
10.2. Record Route Label Sub-object Flags . . . . . . . . . . 13
10.3. Error Codes and Error Values . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Beeram, et al. Expires 6 January 2027 [Page 2]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
1. Introduction
RFC 8577 [RFC8577] defines a mechanism to signal Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) tunnels using a shared
Multiprotocol Label Switching (MPLS) forwarding plane. It introduces
"Traffic Engineering (TE) link labels" -- preinstalled, per-TE-link
labels that are allocated locally by each Label Switching Router
(LSR) and communicated to upstream neighbors via RSVP-TE Resv
messages. These labels have "pop and forward" semantics and can be
shared across all RSVP-TE Label Switched Paths (LSPs) traversing the
same TE link.
The Segment Routing (SR) architecture [RFC8402] independently defines
Adjacency Segments (Adj-SIDs) with identical forwarding- plane
semantics: an Adj-SID is a locally significant label that, when
present at the top of the stack, instructs the node to pop the label
and forward the packet over the associated adjacency. Adj-SIDs are
advertised via Interior Gateway Protocol (IGP) extensions [RFC8667]
[RFC8665].
While RFC 8577 TE link labels and SR Adj-SIDs have the same data-
plane behavior, they differ in their control-plane lifecycle:
* TE link labels are typically allocated by a technology- agnostic
TE component and discovered via Resv processing.
* Adj-SIDs are typically allocated by the SR component and
discovered via IGP.
This document extends RFC 8577 to use IGP-advertised SR Adj-SIDs as
the forwarding-plane labels for RSVP-TE tunnels. This unifies the
forwarding plane: a single set of Adj-SID labels serves both SR-
native and RSVP-TE-signaled traffic. The RSVP-TE control plane
continues to provide bandwidth admission control, explicit path
management, and fast-reroute signaling on top of the shared SR-MPLS
forwarding plane.
This document restricts its scope to:
* Per-link Adj-SIDs: One Adj-SID per physical or logical TE link
(not per-neighbor aggregate SIDs).
Benefits of this approach over RFC 8577:
* Single label allocation system: Eliminates dual allocation (TE
link labels + Adj-SIDs) and potential label space fragmentation.
Beeram, et al. Expires 6 January 2027 [Page 3]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
* IGP-native discovery: The ingress or controller can pre-compute
the label stack from the IGP topology database without waiting for
Resv processing to discover labels hop by hop.
* Interoperability: The same Adj-SIDs serve SR-only nodes, RSVP-TE
nodes, and hybrid deployments without forwarding-plane conflicts.
2. Terminology
The following terms are used in this document:
Adj-SID: Adjacency Segment Identifier. A label allocated by a node
for a specific adjacency (TE link) and advertised via IGP. When
present at the top of the label stack, the node pops the label and
forwards the packet over the associated adjacency.
Per-link Adj-SID: An Adj-SID that identifies a specific TE link
(interface) rather than a neighbor (set of parallel links).
Corresponds to an Adj-SID advertisement without the B-flag
(Backup) and without the S-flag (Set).
Binding SID (BSID): A local label that, when matched, triggers the
imposition of a predetermined label stack. Used at delegation
hops to represent a downstream path segment.
SR-MPLS Forwarding Plane: The MPLS data plane where forwarding
decisions at each hop are driven by Adj-SIDs (pop and forward)
rather than per-LSP swap labels.
PLR: Point of Local Repair. The node that detects a failure and
initiates fast-reroute.
SRLB: Segment Routing Local Block. The range of local labels from
which Adj-SIDs are allocated.
2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Adjacency SID Requirements
This section defines the properties of Adj-SIDs used as the
forwarding-plane labels for RSVP-TE tunnels.
Beeram, et al. Expires 6 January 2027 [Page 4]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
3.1. Adj-SID Persistence
An Adj-SID used for RSVP-TE forwarding is RECOMMENDED to be
persistent (i.e., advertised with the P-flag set in the IS-IS Adj-SID
sub-TLV [RFC8667] or the OSPF Adj-SID sub-TLV [RFC8665]). However,
persistence is not required.
Persistent Adj-SIDs have the following properties:
* The label value is preserved when the associated adjacency
transitions from UP to DOWN and back to UP.
* The label value is preserved across process restarts and router
reboots.
* The label is pre-programmed in the forwarding plane upon
configuration, even if the adjacency is not yet operational. In
this state, packets arriving with the Adj-SID are dropped (the
forwarding entry exists but points to a down adjacency).
When persistent Adj-SIDs are used, the label stack at the ingress
remains valid across adjacency flaps; only the data-plane
reachability of the adjacency changes, which is handled by protection
mechanisms (Section 6).
When non-persistent Adj-SIDs are used, a node that restarts may
allocate new Adj-SID label values. RSVP-TE signaling inherently
adapts to such changes: the refreshed or re-signaled Resv message
will carry the new Adj-SID values in the Label object and RRO, and
the ingress LER will update its label stack accordingly. The
transient disruption during the restart is comparable to what occurs
with any RSVP-TE label change.
3.2. Per-Link Adj-SIDs
An Adj-SID used for RSVP-TE forwarding MUST be per-link (per-
interface). That is, a unique Adj-SID is allocated for each TE link,
even if multiple parallel links exist to the same neighbor.
This corresponds to an Adj-SID advertisement without the S-flag (Set)
in the IGP. Per-neighbor (Set) SIDs, which aggregate multiple
parallel links under a single SID with ECMP semantics, MUST NOT be
used for RSVP-TE forwarding under this specification.
Rationale: RSVP-TE requires per-link granularity for:
* Bandwidth admission control on individual links.
Beeram, et al. Expires 6 January 2027 [Page 5]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
* Explicit path routing over specific interfaces.
* Per-link protection (detecting which specific link failed).
3.3. IGP Advertisement
Each node participating in the SR-MPLS forwarding plane for RSVP-TE
MUST advertise its per-link Adj-SIDs via the IGP using the extensions
defined in [RFC8667] (IS-IS) or [RFC8665] (OSPF).
The V-flag (Value) and L-flag (Local) MUST be set, indicating that
the advertised SID value is an absolute MPLS label from the SRLB.
A controller or ingress LER uses these IGP advertisements to pre-
compute the label stack for an RSVP-TE tunnel prior to signaling.
4. RSVP-TE Tunnel Setup Using Adj-SIDs
This section describes the signaling procedures for establishing an
RSVP-TE tunnel that uses IGP-advertised Adj-SIDs for its forwarding
plane.
4.1. Adj-SID Discovery
Prior to signaling, the path computation engine (on the ingress LER
or an external controller) determines the Adj-SID for each TE link
along the explicit path by consulting the Traffic Engineering
Database (TED). Each link in the TED carries the Adj-SID value from
the node that owns the link (the node whose IGP advertisement defined
the SID).
The path computation engine MAY pre-compute the full label stack from
the TED. However, the ingress MUST still use the labels recorded in
the RRO of the Resv message as the authoritative source for label
stack construction. The TED-based pre- computation serves as a
validation mechanism and enables faster setup.
If a link's Adj-SID is not present in the TED at the time of path
computation, the path computation engine SHOULD exclude that link
from consideration when computing the explicit path.
4.2. Path Message Processing
The ingress LER initiates RSVP-TE signaling by sending a Path message
with the following attributes:
Beeram, et al. Expires 6 January 2027 [Page 6]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
* The LSP_REQUIRED_ATTRIBUTES object MUST carry the "SR Forwarding
Plane" flag (Section 8.1) to mandate the use of Adj-SIDs at all
transit hops.
* The ERO MUST contain the explicit path as a sequence of sub-
objects identifying each transit hop (IPv4/IPv6 prefix sub-objects
or Unnumbered Interface ID sub-objects).
* The ERO MAY additionally contain Label sub-objects [RFC3473] to
constrain the Adj-SID selection at specific transit hops (see
Section 8.3). This is OPTIONAL; when present, the transit node
MUST use the indicated label or reject the request.
* If delegation is requested, the LSP_ATTRIBUTES object carries the
LSI-D flag as defined in [RFC8577] Section 9.4.
* The "label recording desired" flag [RFC3209] MUST be set in the
SESSION_ATTRIBUTE object.
When a transit node receives the Path message:
* It MUST verify that it has a per-link Adj-SID configured for the
outgoing TE link toward the next hop.
* If an ERO Label sub-object [RFC3473] is present for this hop, the
node MUST verify that the indicated label matches its locally
configured Adj-SID for the relevant TE link. If there is a
mismatch, the node MUST send a PathErr with error code 'Routing
Problem (24)' and a new error value 'Adj-SID mismatch (TBD1)'.
* If no ERO Label sub-object is present for this hop, the node
selects its locally configured per-link Adj-SID for the outgoing
TE link.
* The node performs bandwidth admission control on the outgoing TE
link per standard RSVP-TE procedures.
4.3. Resv Message Processing
When a node generates or forwards a Resv message:
* It MUST place its per-link Adj-SID for the outgoing TE link (the
link over which it forwards traffic for this LSP) in the Label
object of the Resv message.
* It MUST record the same Adj-SID in the RRO Label sub-object with
the "SR Adj-SID" flag set (Section 8.2).
Beeram, et al. Expires 6 January 2027 [Page 7]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
* No new label allocation occurs. The node simply references its
pre-existing, IGP-advertised Adj-SID.
The key difference from RFC 8577: in RFC 8577, the node allocates a
TE link label from its local label space. Here, the node references
an Adj-SID that is already allocated, pre- programmed in the
forwarding plane, and advertised via IGP. The RSVP-TE signaling is
purely a control-plane exercise -- no forwarding-plane programming
occurs at tunnel setup or teardown.
4.4. Label Stack Construction at Ingress
Upon receiving the Resv message, the ingress LER constructs the label
stack using the same rules defined in [RFC8577] Section 7:
* Process RRO Label sub-objects starting from the first downstream
hop.
* Every label marked with the "SR Adj-SID" flag is a pop-and-
forward label. The next hop's label MUST also be pushed onto the
stack.
* Delegation labels (Binding SIDs) are handled per the stacking
approach (Section 5).
Since all transit hops use Adj-SIDs (pop-and-forward), the resulting
label stack is the ordered sequence of Adj-SIDs from the first hop to
the penultimate hop -- identical to what an SR headend would impose
for the same path.
5. Delegating Label Stack Imposition
The delegation mechanism from [RFC8577] Section 5 is preserved with
one refinement: delegation labels are mapped to SR Binding SIDs
(BSIDs).
5.1. Binding SIDs as Delegation Labels
When a transit node is selected as a delegation hop (either
explicitly or via automatic delegation using ETLD), it MUST allocate
a Binding SID to represent the downstream path segment.
The Binding SID is:
* A local label from the SRLB (or dynamic label range).
Beeram, et al. Expires 6 January 2027 [Page 8]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
* Programmed in the forwarding plane with an action to pop the BSID
and push the label stack representing the path from this node to
the next delegation hop (or egress).
* Recorded in the RRO with the "Delegation Label" flag (0x04) as
defined in [RFC8577] Section 9.5.
Sharing semantics: A Binding SID representing a specific downstream
Adj-SID sequence CAN be shared across multiple RSVP-TE LSPs that
traverse the same downstream path segment. This mirrors the
delegation label sharing in [RFC8577] Section 5.1.1.
When the downstream path changes (e.g., due to MBB or
reoptimization), the old BSID MUST be updated or a new BSID allocated
for the new path segment.
5.2. ETLD Computation
The ETLD (Effective Transport Label-Stack Depth) mechanism from
[RFC8577] Section 5.3 operates unchanged. The computation accounts
for:
* The Maximum SID Depth (MSD) advertised by each node via IGP
[RFC8491] or signaled via other mechanisms.
* Protection overhead: If facility backup link protection is active,
the PLR needs to push the bypass tunnel's label(s). The ETLD
SHOULD be decremented to account for the bypass tunnel label at
protected hops.
6. Protection Mechanisms
This document uses the facility backup link protection procedures
defined in [RFC8577] Section 8.1 and [RFC4090]. Node protection and
non-signaled protection paths are outside the scope of this document.
6.1. Link Protection
Link protection operates as defined in [RFC8577] Section 8.1. To
provide link protection at a PLR, the LSR MUST allocate a separate
Adj-SID for the TE link that will be used for RSVP-TE tunnels
requesting link protection from the ingress. This link-protected
Adj-SID is analogous to the link-protected TE link label defined in
[RFC8577].
A facility backup bypass tunnel is pre-established to protect the TE
link. The bypass tunnel terminates at the next hop (the merge
point). The bypass tunnel is signaled via RSVP-TE.
Beeram, et al. Expires 6 January 2027 [Page 9]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
When the protected TE link is operational, the PLR pops the link-
protected Adj-SID and forwards the packet over the TE link to the
next hop. When the TE link fails, the PLR pops the link-protected
Adj-SID and redirects the packet via the facility backup bypass
tunnel to the next hop.
Since the facility backup terminates at the next hop (merge point),
the incoming label on the packet at the merge point will be the Adj-
SID that the merge point expects -- the same label it would have
received had the protected link been operational.
No additional signaling extensions are required to support link
protection beyond those already defined in [RFC8577] and [RFC4090].
7. Bandwidth Admission Control
Bandwidth admission control operates per standard RSVP-TE procedures.
The fact that the forwarding-plane label (Adj-SID) is shared across
LSPs does not affect admission control, which is maintained in the
control plane per-LSP.
Each transit node:
* Maintains per-link bandwidth accounting (reserved bandwidth as the
sum of all admitted RSVP-TE LSPs on the link).
* Performs admission control on new LSP setup or bandwidth
modification requests.
* Advertises available bandwidth via IGP TE extensions [RFC5305]
[RFC3630].
The shared Adj-SID means that the forwarding plane does not
distinguish between individual LSPs. Bandwidth enforcement is a
control-plane property, not a forwarding-plane property. If
hardware-based bandwidth policing per-LSP is required, this mechanism
is not applicable.
8. Protocol Extensions
This document introduces minimal signaling extensions: one new
Attribute Flag and one new RRO Label sub-object flag. All other
signaling uses existing RSVP-TE objects and sub-objects defined in
[RFC3209], [RFC3473], and [RFC8577].
Beeram, et al. Expires 6 January 2027 [Page 10]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
8.1. Attribute Flags: SR Forwarding Plane
Bit Number (TBD2): SR Forwarding Plane
The presence of this flag in the LSP_REQUIRED_ATTRIBUTES object
[RFC5420] of a Path message mandates the use of IGP-advertised per-
link SR Adj-SIDs at all transit hops.
Relationship to the TE Link Label flag (Bit 16 from [RFC8577]):
* Bit 16 (TE Link Label) requests RSVP-TE-allocated TE link labels.
* Bit TBD2 (SR Forwarding Plane) requests IGP-advertised SR Adj-
SIDs.
* These two flags are mutually exclusive. A node MUST NOT set both
flags for the same LSP.
When a node that recognizes this flag cannot comply (e.g., it does
not have a per-link Adj-SID configured for the outgoing TE link), it
MUST send a PathErr with error code 'Routing Problem (24)' and error
value 'SR Adj-SID unavailable (TBD3)'.
An ingress LER that sets this bit MUST also set the "label recording
desired" flag [RFC3209] in the SESSION_ATTRIBUTE object.
8.2. RRO Label Sub-object Flag: SR Adj-SID
Flag (TBD4): SR Adj-SID
The presence of this flag in an RRO Label sub-object indicates that
the recorded label is an IGP-advertised SR Adjacency SID. This flag
MUST be set by a transit node when recording its per-link Adj-SID in
the RRO.
The TE Link Label flag (0x02) from [RFC8577] SHOULD NOT be used when
the label is a native SR Adj-SID. The SR Adj-SID flag (TBD4)
provides equivalent pop-and-forward semantics with the additional
indication that the label is IGP-originated.
The label value is carried in the standard 20-bit label field of the
existing RRO Label sub-object. No new RRO sub-object type is
defined.
Beeram, et al. Expires 6 January 2027 [Page 11]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
8.3. Constraining Adj-SID Selection via ERO
When the ingress needs to constrain a transit node to use a specific
Adj-SID (e.g., when multiple per-link Adj-SIDs exist for the same TE
link), it MAY include an ERO Label sub-object [RFC3473] following the
hop-identifying sub-object (IPv4/IPv6 prefix or Unnumbered Interface
ID).
The ERO Label sub-object carries the desired 20-bit Adj-SID label
value using the existing encoding defined in [RFC3473] Section 4.1.
No new ERO sub-object type is defined.
When a transit node receives an ERO Label sub-object and the SR
Forwarding Plane flag is set:
* It MUST verify that the label in the ERO Label sub-object matches
one of its locally configured per-link Adj-SIDs for the outgoing
TE link.
* On match: it uses that Adj-SID.
* On mismatch: it MUST send a PathErr with error code 'Routing
Problem (24)' and error value 'Adj-SID mismatch (TBD1)'.
When no ERO Label sub-object is present, the transit node selects its
locally configured per-link Adj-SID for the outgoing TE link
autonomously.
Note: Delegation labels (Binding SIDs) are recorded in the RRO using
the existing Delegation Label flag (0x04) from [RFC8577] Section 9.5.
No new signaling is required for delegation.
9. OAM Considerations
MPLS LSP Ping and Traceroute [RFC8029] are applicable for RSVP-TE
tunnels using SR Adj-SIDs. The procedures in [RFC8287] (Label
Switched Path Ping for Segment Routing) provide additional mechanisms
for validating individual SIDs along the path.
For an RSVP-TE tunnel using Adj-SIDs:
* LSP Ping MAY use the RSVP-TE session-based FEC (as per standard
RSVP-TE OAM) to validate end-to-end connectivity.
* Traceroute SHOULD use the SR Segment List FEC [RFC8287] to
validate each Adj-SID at every transit hop.
Beeram, et al. Expires 6 January 2027 [Page 12]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
* A delegation hop that expands a Binding SID into a label stack
SHOULD report the expanded stack in the Label Stack Sub-TLV of the
MPLS echo reply.
10. IANA Considerations
This document requests the following IANA allocations.
10.1. Attribute Flags
IANA manages the "Attribute Flags" subregistry as part of the
"Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
Parameters" registry. This document introduces one new Attribute
Flag:
Bit Name Attribute Attribute RRO ERO Reference
No Flags Path Flags Resv
TBD2 SR Forwarding Plane Yes No No No [ThisDoc],
Section 8.1
10.2. Record Route Label Sub-object Flags
IANA manages the "Record Route Object Sub-object Flags" registry as
part of the "Resource Reservation Protocol-Traffic Engineering (RSVP-
TE) Parameters" registry. This document introduces one new Label
Sub-object Flag:
Flag Name Reference
TBD4 SR Adj-SID [ThisDoc], Section 8.2
10.3. Error Codes and Error Values
IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a subregistry called "Error Codes and
Globally-Defined Error Value Sub-Codes". Within this subregistry is
a definition of the "Routing Problem" Error Code (24). IANA is
requested to allocate further error values for use with this Error
Code as follows:
Beeram, et al. Expires 6 January 2027 [Page 13]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
24 Routing Problem [RFC3209]
This Error Code has the following globally defined Error
Value sub-codes:
TBD1 = Adj-SID mismatch [ThisDoc],
Section 8.3
TBD3 = SR Adj-SID unavailable [ThisDoc],
Section 8.1
11. Security Considerations
This document does not introduce fundamentally new security issues
beyond those in [RFC8577], [RFC3209], and [RFC8402].
The use of IGP-advertised Adj-SIDs introduces a dependency on IGP
security. If an attacker can inject false IGP advertisements with
spoofed Adj-SIDs, traffic could be misdirected. Deployments SHOULD
use IGP authentication [RFC5304] [RFC5310] to protect against such
attacks.
The Adj-SIDs used for RSVP-TE forwarding are local labels visible in
IGP advertisements. An off-path attacker with knowledge of these
labels could craft packets that traverse specific paths. This is an
inherent property of SR-MPLS and is not worsened by this
specification. Deployments MAY use ACLs at domain boundaries to
filter externally sourced packets with SR label stacks.
12. Acknowledgements
The authors would like to thank Harish Sitaraman, Tejal Parikh, and
Tarek Saad for their contributions to RFC 8577, which forms the
foundation for this work.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/rfc/rfc3209>.
Beeram, et al. Expires 6 January 2027 [Page 14]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, February 2003,
<https://www.rfc-editor.org/rfc/rfc3473>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/rfc/rfc4090>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangar, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <https://www.rfc-editor.org/rfc/rfc5420>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/rfc/rfc8491>.
[RFC8577] Sitaraman, H., Beeram, V., Parikh, T., and T. Saad,
"Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding
Plane", RFC 8577, DOI 10.17487/RFC8577, April 2019,
<https://www.rfc-editor.org/rfc/rfc8577>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/rfc/rfc8665>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/rfc/rfc8667>.
Beeram, et al. Expires 6 January 2027 [Page 15]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
13.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, October 2003,
<https://www.rfc-editor.org/rfc/rfc3630>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/rfc/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/rfc/rfc5305>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/rfc/rfc5310>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/rfc/rfc8029>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/rfc/rfc8287>.
Contributors
Chandra Ramachandran
HPE
Email: chandrasekar.ramachandran@hpe.com
Sudharsana Venkatraman
HPE
Email: sudharsana.venkatraman@hpe.com
Shraddha Hegde
HPE
Email: shraddha.hegde@hpe.com
Beeram, et al. Expires 6 January 2027 [Page 16]
Internet-Draft RSVP-TE with SR-MPLS Adj-SIDs July 2026
Abhishek Chakraborty
HPE
Email: abhishek.chakraborty@hpe.com
Jayant Agarwal
HPE
Email: jayant.agarwal@hpe.com
Authors' Addresses
Vishnu Pavan Beeram
HPE
Email: vishnupavan.ietf@gmail.com
Colby Barth
HPE
Email: jonathan.barth@hpe.com
Andrew Smith
Arrcus, Inc.
Email: andy@arrcus.com
Beeram, et al. Expires 6 January 2027 [Page 17]