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, . [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [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, . 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, . [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, . [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, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . [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, . 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, . [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [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, . 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]