IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels
draft-saad-teas-rsvpte-ip-tunnels-03
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 | Tarek Saad , Vishnu Pavan Beeram , 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-saad-teas-rsvpte-ip-tunnels-03
TEAS T. Saad
Internet-Draft Cisco Systems
Intended status: Standards Track V. P. Beeram
Expires: 6 January 2027 HPE
A. Smith
Arrcus, Inc.
5 July 2026
IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels
draft-saad-teas-rsvpte-ip-tunnels-03
Abstract
This document describes the use of RSVP (Resource Reservation
Protocol), including all the necessary extensions, to establish
Point-to-Point (P2P) Traffic Engineered IP (IP-TE) Label Switched
Path (LSP) tunnels for use in native IP forwarding networks.
This document defines specific extensions to the RSVP protocol to
allow the establishment of explicitly routed IP paths using RSVP as
the signaling protocol. The result is the instantiation of an IP
path which can be automatically routed away from network failures,
congestion, and bottlenecks. This document also defines
considerations for using these extensions in networks that support
SRv6.
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.
Saad, et al. Expires 6 January 2027 [Page 1]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of IP-TE LSP Tunnels . . . . . . . . . . . . . . . . 4
3.1. Creation and Management . . . . . . . . . . . . . . . . . 5
3.2. Path Maintenance . . . . . . . . . . . . . . . . . . . . 5
3.3. Signaling Extensions . . . . . . . . . . . . . . . . . . 6
3.3.1. RSVP Path message . . . . . . . . . . . . . . . . . . 6
3.3.2. Transit Node Processing . . . . . . . . . . . . . . . 7
3.4. RSVP Resv Label Object . . . . . . . . . . . . . . . . . 7
3.5. EAB Address Handling . . . . . . . . . . . . . . . . . . 8
3.5.1. Egress Router . . . . . . . . . . . . . . . . . . . . 8
3.5.2. Ingress and Transit Router . . . . . . . . . . . . . 8
3.6. Data Plane Forwarding . . . . . . . . . . . . . . . . . . 9
3.7. Protection . . . . . . . . . . . . . . . . . . . . . . . 10
3.8. Shared Forwarding . . . . . . . . . . . . . . . . . . . . 10
3.9. SRv6 Considerations . . . . . . . . . . . . . . . . . . . 11
3.9.1. SRv6-Tunnel Switching Type . . . . . . . . . . . . . 11
3.9.2. EAB Locator . . . . . . . . . . . . . . . . . . . . . 13
3.9.3. Shared Forwarding with SRv6-Tunnel . . . . . . . . . 13
3.10. MTU Considerations . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. Switching Types . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Saad, et al. Expires 6 January 2027 [Page 2]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
1. Introduction
In native IP networks, each router runs a routing protocol to
determine the best next-hops to a specific destination. The best
next-hops are usually determined by favoring those that run along the
shortest path to the destination. When data flows across the
network, it is routed hop-by-hop and follows the selected path by
each hop towards that destination.
It is sometimes desirable for an ingress router to be able to steer
traffic towards a destination along a pre-determined or pre-computed
path that may follow a path other than the default shortest path.
For example, some flows may need to be forwarded along the least
latency path. Others may need to be routed with bandwidth guarantees
along the selected path, or along a path that honors certain resource
affinities or Shared Risk Link Group (SRLG) memberships.
A solution to such use-cases entails: 1) routers in the network to be
able to maintain and disseminate per-link state information, 2)
ingress routers or an external Path Computation Engine (PCE) to be
able to perform a stateful path computation for feasible paths on top
of the network topology, and 3) for ingress routers to be able to
steer or tunnel the traffic along the established path towards the
destination.
Mechanisms have been defined to achieve this with RSVP extensions for
Traffic Engineered Multiprotocol Label Switching (MPLS-TE) networks
as described in [RFC3209]. This document defines extensions to the
existing mechanisms for achieving this in networks that rely on
native IP for their forwarding.
This document covers the necessary extensions for establishing Point-
to-Point (P2P) Traffic-Engineered IP (IP-TE) Label Switched Path
(LSP) Tunnels. This document also defines considerations for using
these extensions in networks that support SRv6. The equivalent
extensions needed for setting up multicast IP-TE LSPs are currently
out of the scope of this document.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Saad, et al. Expires 6 January 2027 [Page 3]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
2.1. Acronyms
The reader is assumed to be familiar with the terminology used in
[RFC2205] and [RFC3209].
IP-TE LSP (Traffic Engineered IP Label Switched Path): The path
created by programming of an IP route along the explicitly
specified or dynamically computed sequence of router hops,
allowing an IP packet to be forwarded from one hop to another
along the established path.
IP-TE LSP Tunnel: An IP-TE LSP which is used to tunnel traffic over
the pre-established IP path.
Traffic Engineered IP Tunnel (IP-TE Tunnel): A set of one or more
IP-TE LSP Tunnels which carries a traffic trunk.
Egress Address Block (EAB): One or more IP addresses reserved at the
egress router and dedicated for binding to IP-TE LSP tunnels. An
EAB address serves as the destination address of the outer IP
header for traffic encapsulated into the tunnel.
3. Overview of IP-TE LSP Tunnels
IP-TE LSP tunnels are established over a native IP forwarding
network. In many cases, IP-TE LSPs are explicitly routed from an
ingress router. The explicit route used to establish an IP-TE LSP
may be locally computed at the ingress router, or externally computed
by an entity such as a Path Computation Element (PCE) [RFC4655].
To support the setup of IP-TE LSP tunnels, the egress routers reserve
one or more local IP prefixes or Egress Address Blocks (EABs) that
are dedicated for RSVP to establish IP-TE LSP tunnels.
The EAB addresses at the egress router may be managed by the RSVP
protocol and, for IPv4-Tunnel and IPv6-Tunnel switching types, are
not required to be exchanged by any other routing protocol. For the
SRv6-Tunnel switching type, the EAB is allocated from a dedicated
SRv6 locator prefix at the egress node that is not advertised in the
IGP (see Section 3.9).
It is possible in some cases, where the IP-TE LSPs are contained
within a single administrative domain boundary, for EABs to be
allocated from the private IP address space as defined in [RFC1918]
or from the unique-local space as defined in [RFC4193] and [RFC6890].
Saad, et al. Expires 6 January 2027 [Page 4]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
It is also useful in some applications for sets of IP-TE LSP tunnels
to be associated together to facilitate reroute operations or to
spread a traffic trunk over multiple IP-TE LSP tunnel paths. For
traffic engineering applications to IP-TE LSP tunnels, such sets are
called Traffic Engineered IP tunnels (IP-TE tunnels).
3.1. Creation and Management
An IP-TE LSP tunnel is unidirectional in nature. To create an IP-TE
LSP tunnel, the ingress router of the IP-TE LSP tunnel creates an
RSVP Path message with a session type of LSP_TUNNEL_IPv4 or
LSP_TUNNEL_IPv6 and follows the procedures outlined in [RFC3473] to
insert a Generalized Label Request object into the Path message. The
Generalized Label Request object indicates that an IP address binding
is requested to the IP-TE LSP tunnel. The binding of an EAB address
to an IP-TE LSP tunnel happens at the egress router and is signaled
using an RSVP Resv message sent from the egress router.
The ingress router uses a pre-computed explicit path to populate the
EXPLICIT_ROUTE object that is added to the RSVP Path message. The
explicitly routed path can be administratively specified, or
automatically computed by a suitable entity based on QoS and policy
requirements, taking into consideration the prevailing network state.
In addition, RSVP-TE signaling [RFC3209] allows for the specification
of an explicit path as a sequence of strict and loose routes. Such a
combination of abstract nodes, and strict and loose routes
significantly enhances the flexibility of path definitions.
The ingress MAY also add a RECORD_ROUTE object to the RSVP Path
message in order to receive information about the actual route
traversed by the IP-TE LSP tunnel. The RECORD_ROUTE object MAY also
be used by the egress router to determine whether Shared Forwarding
as described in Section 3.8 is possible amongst different IP-TE LSP
tunnels.
3.2. Path Maintenance
If the ingress router discovers a better path, after an IP-TE LSP
tunnel has been successfully established, it can dynamically reroute
the session by changing the EXPLICIT_ROUTE object. If problems are
encountered with the EXPLICIT_ROUTE object, either because it causes
a routing loop or because some intermediate routers do not support
it, the ingress is notified.
Saad, et al. Expires 6 January 2027 [Page 5]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
Make-before-break procedures can also be employed to modify the
characteristics of an IP-TE LSP tunnel. As described in [RFC3209],
the LSP ID in the Sender Template object is updated in the new RSVP
Path message that is signaled. As usual, the combination of the
LSP_TUNNEL SESSION object and the SE reservation style naturally
accommodates smooth transitions in bandwidth and routing.
For example, to trigger a bandwidth increase, a new RSVP Path Message
with a new LSP_ID can be used to attempt a larger bandwidth
reservation while the current LSP_ID continues to be refreshed to
ensure that the reservation is not lost if the larger reservation
fails.
3.3. Signaling Extensions
This section describes RSVP signaling extensions and modifications to
existing RSVP objects that are carried in RSVP Path or Resv messages
and are required to establish IP-TE LSP tunnels.
3.3.1. RSVP Path message
To signal an IP-TE LSP tunnel, the Generalized Label Request object
is carried in the RSVP Path message and used to request an IP address
binding to the IP-TE LSP tunnel.
The Generalized Label Request is defined in [RFC3471] and has the
following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To request an IPv4 or IPv6 binding to an IP-TE LSP tunnel, the
Generalized Label Request object carries the following specifics:
1. The LSP Encoding Type is set to Packet (1) [RFC3471].
2. The LSP Switching Type is set to "IPv4-Tunnel" (TBD1),
"IPv6-Tunnel" (TBD2), or "SRv6-Tunnel" (TBD3). The SRv6-Tunnel
switching type is described in Section 3.9.
3. The Generalized Payload Identifier (G-PID) MAY be set to All (0)
or in some cases to the specific payload type if known, e.g.
Ethernet (33) [RFC3471].
Saad, et al. Expires 6 January 2027 [Page 6]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
3.3.2. Transit Node Processing
When a transit node receives an RSVP Path message with the
Generalized Label Request containing a Switching Type of IPv4-Tunnel
(TBD1), IPv6-Tunnel (TBD2), or SRv6-Tunnel (TBD3), it MUST process
the message as follows:
1. If the transit node does not recognize the switching type, it
MUST reject the Path message per [RFC3471].
2. If the transit node recognizes the switching type, it MUST
perform bandwidth admission control on the outgoing link per
standard RSVP-TE procedures [RFC3209] and forward the Path
message to the next hop as identified by the EXPLICIT_ROUTE
object.
3. When the corresponding Resv message is received from the
downstream hop, the transit node processes the EAB address from
the Generalized Label per the procedures in Section 3.5.2.
3.4. RSVP Resv Label Object
The egress is responsible for binding an EAB address to an IP-TE LSP
tunnel.
Once the egress router receives the RSVP Path message with the
Generalized Label Request object containing the parameters described
in Section 3.3.1, the egress router determines and binds an EAB
address to the newly established IP-TE LSP tunnel. Note that,
subject to local policy and additional path checks, the egress MAY
assign an already in-use EAB address to the newly established IP-TE
LSP tunnel.
The RSVP Resv message that is created by the egress router uses the
Generalized Label defined in [RFC3471] to carry the EAB address that
is bound to the newly established IP-TE LSP tunnel.
The RSVP Generalized Label object has the following format:
LABEL class = 16, C_Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Saad, et al. Expires 6 January 2027 [Page 7]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
Label (Variable Length): Carries label information. The
interpretation of this field depends on the parameters signaled in
the Generalized Label Request. For IPv4-Tunnel (TBD1), the Label
field carries a 32-bit IPv4 address. For IPv6-Tunnel (TBD2) and
SRv6-Tunnel (TBD3), the Label field carries a 128-bit IPv6
address.
3.5. EAB Address Handling
The RSVP Resv message that is created by the egress router is
forwarded upstream along the signaling path towards the ingress
router. The EAB address binding procedures differ at the egress and
at ingress/transit routers, as described below.
3.5.1. Egress Router
The egress router manages the EAB addresses for the use of
establishing IP-TE LSP tunnels.
The egress router MAY assign a unique EAB address to newly
established IP-TE LSP tunnels and MAY free an existing EAB address
upon destroying a previously established IP-TE LSP tunnel. Note that
an egress router MAY hold on to an EAB when the IP-TE LSP is being
destroyed if it determines other IP-TE LSPs are sharing it.
Once an EAB address is allocated and bound to a new IP-TE LSP tunnel,
the egress router programs the address in its forwarding table as a
local address. For IPv4-Tunnel and IPv6-Tunnel switching types, this
results in decapsulation of the outer IP header on any packet
arriving over the IP-TE LSP tunnel and yields the original IP
datagram that was tunneled over the IP-TE LSP tunnel. For
SRv6-Tunnel, the EAB is programmed with SRv6 End behavior as
described in Section 3.9.
3.5.2. Ingress and Transit Router
A transit or an ingress router extracts the EAB address that the
egress router binds to the IP-TE LSP tunnel from the Generalized
Label object contained in the RSVP Resv message that is propagated
upstream as described in Section 3.4. The transit or ingress router
uses the EAB address to program an IP route in the Routing
Information Base (RIB) and uses the previously signaled
EXPLICIT_ROUTE object to derive the next-hop information associated
with the EAB route at that hop.
Saad, et al. Expires 6 January 2027 [Page 8]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
An advantage of using RSVP to establish IP-TE LSP tunnels is that it
enables the allocation of resources along the path. For example,
bandwidth can be allocated to each IP-TE LSP tunnel using standard
RSVP reservations as described in [RFC3209].
3.6. Data Plane Forwarding
For IPv4-Tunnel and IPv6-Tunnel switching types, IP-TE LSP tunnels
use IP-in-IP encapsulation [RFC2003] or GRE encapsulation [RFC2784]
to carry traffic along the explicitly routed path. The EAB address
bound to the tunnel serves as the destination address of the outer IP
header. The choice of encapsulation is a local policy decision at
the ingress router. For SRv6-Tunnel, the encapsulation uses an outer
IPv6 header with a Segment Routing Header (SRH); see Section 3.9 for
details.
At the ingress router, traffic destined for the IP-TE LSP tunnel is
encapsulated in an outer IP header:
* The outer IP Destination Address is set to the EAB address
received from the egress router in the Generalized Label
(Section 3.4).
* The outer IP Source Address is set to an address of the ingress
router.
* For IP-in-IP encapsulation, the IP Protocol field of the outer
header is set to 4 (IP-in-IP) when the inner payload is IPv4, or
41 (IPv6) when the inner payload is IPv6. For GRE encapsulation,
the IP Protocol field is set to 47 (GRE) and the GRE header
carries the appropriate protocol type for the inner payload.
The resulting encapsulated packet is then forwarded hop-by-hop along
the signaled path. At each transit router, the outer packet is
forwarded using the IP route that was programmed in the RIB for the
EAB address (Section 3.5.2). Because this route uses the next-hop
derived from the EXPLICIT_ROUTE object, the packet follows the
traffic-engineered path rather than the shortest path.
At the egress router, the packet arrives with the EAB address as the
IP Destination Address. Since the EAB is programmed as a local
address (Section 3.5.1), the egress router decapsulates the outer IP
header and processes the inner IP datagram according to its normal
forwarding procedures. For SRv6-Tunnel, the egress processing
differs; see Section 3.9.
Saad, et al. Expires 6 January 2027 [Page 9]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
3.7. Protection
Fast Reroute (FRR) procedures that are defined in [RFC4090] describe
the mechanisms for a router along the LSP path to act as a Point of
Local Repair (PLR) and reroute traffic and signaling of a protected
RSVP-TE LSP onto a pre-established bypass tunnel in the event of a
protected TE link or node failure.
Similar mechanisms can be employed for protecting IP-TE LSP tunnels
in IP networks. An ingress or transit router acting as potential PLR
can pre-establish bypass tunnels that protect the primary IP-TE LSP
tunnel against the protected link or downstream node failure.
Upon failure of the protected link, the traffic arriving over the
protected IP-TE LSP on the PLR is automatically tunneled over the
pre-established bypass IP-TE LSP tunnel and packets are forwarded
towards the Merge Point (MP) router.
Since both the protected tunnel and the bypass tunnel use IP-in-IP or
GRE encapsulation (for IPv4-Tunnel and IPv6-Tunnel switching types),
the packet at the PLR undergoes double encapsulation: the bypass
tunnel adds an outer IP header (with the bypass EAB as the
destination) around the already-encapsulated packet of the protected
tunnel (which carries the protected tunnel's EAB as the destination).
Protection mechanisms for SRv6-Tunnel are for further study.
At the MP router, the outer IP header of the bypass tunnel is
decapsulated, exposing the inner encapsulated packet of the protected
IP-TE LSP tunnel. The MP router then forwards this packet downstream
along the protected IP-TE LSP tunnel path using the RIB entry for the
protected tunnel's EAB address.
The bypass tunnel MAY use a separate EAB address allocated by the MP
router, or it MAY use any IP-based tunneling mechanism that delivers
the protected packet to the MP.
3.8. Shared Forwarding
One capability of the IP data plane is its ability to reuse the IP
forwarding entry when setting up IP-TE LSPs from multiple sources
that share a common destination. This capability MAY be preserved
provided certain requirements are met. This capability is referred
to as "Shared Forwarding". Shared Forwarding is a local policy at
the egress router responsible for binding an EAB address to the
signaled IP-TE LSP tunnel.
Saad, et al. Expires 6 January 2027 [Page 10]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
The Shared Forwarding function allows the reduction of forwarding
entries on any transit router RIB. The Shared Forwarding paths are
identical in function to independently routed Multi-point to Point
(MP2P) paths that share part of their paths from the intersecting
router and towards the egress router.
If the egress router policy allows for Shared Forwarding, and upon
signaling a new IP-TE LSP tunnel, the egress inspects the recorded
path (extracted from the RECORD_ROUTE object). If the egress router
determines that the newly signaled IP-TE LSP path intersects and
merges with other IP-TE LSP tunnels from the intersection point to
the egress, and if Shared Forwarding is enabled, it MUST assign the
same EAB address bound to the existing IP-TE LSP tunnel.
Note that forwarding memory savings from Shared Forwarding can be
quite dramatic in some topologies where a high degree of meshing is
required.
If the RECORD_ROUTE object is not present in the Path message, the
egress router does not have the path information needed to determine
whether paths intersect and merge. In this case, the egress MUST
assign a unique EAB address to each IP-TE LSP tunnel and MUST NOT
apply the Shared Forwarding optimization.
3.9. SRv6 Considerations
When the IPv6-Tunnel switching type (TBD2) is used in a network that
supports SRv6 [RFC8402], the EAB address bound to the tunnel at the
egress may be an IPv6 address allocated from a dedicated SRv6 locator
prefix at the egress node. To explicitly signal that the tunnel uses
an address from an SRv6 locator as the EAB, a new switching type
"SRv6-Tunnel" (TBD3) is defined.
3.9.1. SRv6-Tunnel Switching Type
The SRv6-Tunnel switching type indicates that:
* The egress router allocates an IPv6 address from a dedicated SRv6
locator prefix [RFC8402] reserved for EAB use and provides it in
the Generalized Label. This locator MUST NOT be advertised in the
IGP, ensuring that transit nodes have no IGP-derived route for
addresses within it. This address serves as the EAB for the
tunnel. The egress MUST program the EAB with SRv6 End behavior
[RFC8986] so that incoming packets trigger SRH processing rather
than plain IP decapsulation.
Saad, et al. Expires 6 January 2027 [Page 11]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
* Transit nodes forward packets toward the EAB address using
standard IP forwarding based on the per-hop route programmed by
RSVP-TE; no SRv6 endpoint behavior is executed at transit nodes.
Transit nodes program a per-hop IP route for the EAB address in
their RIB, with the next-hop derived from the EXPLICIT_ROUTE
object. Transit nodes do not allocate SIDs; they forward packets
hop-by-hop toward the egress using the programmed route. Per
[RFC8754], a node that does not recognize the IPv6 Destination
Address as a local SID forwards the packet based on the IPv6 DA
and does not process the SRH.
* The ingress encapsulates traffic with the EAB address as the outer
IPv6 Destination Address and includes a Segment Routing Header
(SRH) [RFC8754]. The SRH uses the Reduced encoding defined in
Section 4.1.1 of [RFC8754]: the first segment (the EAB) is placed
only in the IPv6 Destination Address and is not included in the
SRH Segment List. The SRH Segment List contains a single entry --
the service SID (the last segment) -- Segments Left is set to 1,
and Last Entry is set to 0. The service SID identifies the
service function at the egress (e.g., End.DT46 for IPv4/IPv6
decapsulation and table lookup) and is obtained via mechanisms
outside the scope of this document (e.g., BGP signaling,
controller provisioning, or local configuration). The traffic-
engineered path is enforced through per-hop route programming, not
through the SRH segment list.
This approach is architecturally distinct from the SRv6-Segment
switching type defined in [RSVP-SRV6], where each transit node
allocates an SRv6 End.X SID and the ingress builds an SRH containing
the full segment list to steer packets through each hop. In the
SRv6-Tunnel model, the SRH carries only the service SID and does not
encode the path; the path is enforced entirely through per-hop route
programming. This trades per-hop SID allocation and longer SRH
overhead for per-tunnel RIB state at transit nodes.
At the egress, the packet arrives with the EAB address as the outer
IPv6 Destination Address, SL=1, and Last Entry=0. Since the EAB is
programmed with SRv6 End behavior, the egress performs standard End
processing [RFC8986]: it verifies that SL does not exceed Last Entry
+ 1 (per Section 4.1 of [RFC8986]), decrements SL to 0, updates the
IPv6 Destination Address to Segment List[0] (the service SID), and
submits the packet to the FIB. The FIB matches the service SID and
applies the corresponding endpoint behavior (e.g., End.DT46
decapsulates the inner packet and performs a table lookup).
Saad, et al. Expires 6 January 2027 [Page 12]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
3.9.2. EAB Locator
For the SRv6-Tunnel switching type, each egress node MUST reserve a
dedicated SRv6 locator prefix for EAB allocation. This EAB locator
is analogous to the SRv6 Flex-Algo locator concept, where a node
maintains separate locator prefixes for different purposes. The key
properties of the EAB locator are:
* The EAB locator MUST NOT be advertised in the IGP. This ensures
that transit nodes have no IGP-derived covering route for EAB
addresses. Routes for EAB addresses exist only where programmed
by RSVP-TE.
* The EAB locator is programmed locally at the egress node. The
egress programs addresses within the EAB locator with SRv6 End
behavior so that SRH processing is triggered on arrival.
* Because the EAB locator is not in the IGP, a transit node that
loses RSVP-TE state has no fallback route for the EAB address.
Packets are dropped rather than misrouted, providing the same
loop-safety property as private [RFC1918] or unique-local
[RFC4193] EAB addresses used with IPv4-Tunnel and IPv6-Tunnel
switching types.
3.9.3. Shared Forwarding with SRv6-Tunnel
The Shared Forwarding optimization (Section 3.8) is particularly
effective with SRv6-Tunnel switching. Since the EAB address is
allocated from the egress node's dedicated EAB locator, multiple IP-
TE LSP tunnels from different ingress routers to the same egress can
share the same EAB address. Where their paths merge, transit nodes
can share a single RIB entry for the EAB. This sharing works even
when different tunnels carry different service SIDs in their SRH,
because transit nodes forward based solely on the EAB address and do
not inspect the SRH content.
3.10. MTU Considerations
IP-TE LSP tunnels add encapsulation overhead that reduces the
effective MTU available for payload. Ingress routers SHOULD account
for this overhead when determining the maximum payload size:
* For IPv4-Tunnel with IP-in-IP encapsulation: 20 bytes (outer IPv4
header).
* For IPv6-Tunnel with IP-in-IP encapsulation: 40 bytes (outer IPv6
header).
Saad, et al. Expires 6 January 2027 [Page 13]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
* For GRE encapsulation: an additional 4 bytes (GRE header) or 8
bytes (GRE header with key) on top of the outer IP header.
* For SRv6-Tunnel: 40 bytes (outer IPv6 header) + 8 bytes (SRH fixed
header) + 16 bytes (one Segment List entry for the service SID) =
64 bytes. The Reduced SRH encoding [RFC8754] is used, so the EAB
(first segment) is in the IPv6 DA only and does not consume an
additional Segment List entry.
When FRR bypass protection (Section 3.7) is used, the PLR adds a
second layer of encapsulation. Operators SHOULD account for the
combined overhead of the protected tunnel and the bypass tunnel when
sizing path MTU values.
If the encapsulated packet exceeds the path MTU, the ingress router
MUST handle fragmentation according to the rules of the outer IP
version. Operators SHOULD configure path MTU values that account for
the tunnel encapsulation overhead to avoid excessive fragmentation.
4. IANA Considerations
4.1. Switching Types
IANA maintains the "Switching Types" registry under the "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Parameters"
registry. This document requests the allocation of three new
Switching Types:
Value Description Reference
----- ----------- ---------
TBD1 IPv4-Tunnel [This document], Section 3.3.1
TBD2 IPv6-Tunnel [This document], Section 3.3.1
TBD3 SRv6-Tunnel [This document], Section 3.9.1
5. Security Considerations
This document does not introduce fundamentally new security issues
beyond those described in the base RSVP protocol [RFC2205] and RSVP-
TE [RFC3209].
The EAB addresses carried in RSVP signaling messages (Generalized
Label) are IP addresses that, if leaked outside the administrative
domain, could be used to direct unauthorized traffic toward the
egress router. Operators SHOULD ensure that EAB addresses are not
reachable from outside the domain in which the IP-TE LSP tunnels are
established. When EABs are allocated from private address space
[RFC1918] or unique-local address space [RFC4193], this provides an
inherent layer of protection against external misuse. For the
Saad, et al. Expires 6 January 2027 [Page 14]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
SRv6-Tunnel switching type, the use of a dedicated non-IGP-advertised
EAB locator (Section 3.9) provides an equivalent layer of protection:
EAB addresses are not reachable via any routing protocol and exist
only where RSVP-TE state has been explicitly programmed.
Operators SHOULD protect RSVP signaling messages using the
authentication mechanisms defined in [RFC2747] or other applicable
mechanisms to prevent unauthorized establishment or modification of
IP-TE LSP tunnels.
6. Acknowledgement
The authors would like to thank Igor Bryskin for providing valuable
feedback to this document.
7. References
7.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
DOI 10.17487/RFC2003, October 1996,
<https://www.rfc-editor.org/rfc/rfc2003>.
[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>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/rfc/rfc2205>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/rfc/rfc2784>.
[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>.
Saad, et al. Expires 6 January 2027 [Page 15]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, February 2003,
<https://www.rfc-editor.org/rfc/rfc3471>.
[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>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/rfc/rfc4193>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/rfc/rfc6890>.
[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>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
7.2. Informative References
Saad, et al. Expires 6 January 2027 [Page 16]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, DOI 10.17487/RFC2747, January
2000, <https://www.rfc-editor.org/rfc/rfc2747>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/rfc/rfc4655>.
[RSVP-SRV6]
Beeram, V. P., Barth, C., and A. Smith, "Signaling RSVP-TE
Tunnels on an SRv6 Forwarding Plane Using End.X Segment
Identifiers", Work in Progress, Internet-Draft, draft-
beeram-spring-rsvp-srv6-00, July 2026,
<https://www.ietf.org/archive/id/draft-beeram-spring-rsvp-
srv6-00.txt>.
Contributors
Raveendra Torvi
HPE
Email: raveendra.torvi@hpe.com
Colby Barth
HPE
Email: jonathan.barth@hpe.com
Abhishek Chakraborty
HPE
Email: abhishek.chakraborty@hpe.com
Authors' Addresses
Tarek Saad
Cisco Systems
Email: tsaad.net@gmail.com
Vishnu Pavan Beeram
HPE
Email: vishnupavan.ietf@gmail.com
Andrew Smith
Arrcus, Inc.
Saad, et al. Expires 6 January 2027 [Page 17]
Internet-Draft RSVP for P2P IP-TE LSP Tunnels July 2026
Email: andy@arrcus.com
Saad, et al. Expires 6 January 2027 [Page 18]