TEAS V. P. Beeram Internet-Draft C. Ramachandran Intended status: Standards Track HPE Expires: 6 May 2027 2 November 2026 RSVP-TE Resource Notifications draft-beeram-teas-rsvp-resource-notifications-00 Abstract In scaled Resource Reservation Protocol - Traffic Engineering (RSVP- TE) networks, a single network resource event (such as a link failure or bandwidth reduction) can trigger a storm of PathErr messages, one for each affected Label Switched Path (LSP). This document introduces RSVP Resource Notifications, a mechanism that reduces the number of per-LSP error messages by sending summarized per-source resource-level notifications in a new RSVP message, ResourceNotify. This reduces the control-plane message load from O(LSPs) to O(sources), significantly improving convergence in networks with a large number of RSVP-TE LSPs. The mechanism applies to LSPs whose source is reachable by the transit node within the same domain, and uses a Resource Notification Request Object carried in PATH messages. Two types of resource notifications are defined in this document: Resource Unavailable (for link failures) and Resource Degraded (for bandwidth reduction events). 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 May 2027. Beeram & Ramachandran Expires 6 May 2027 [Page 1] Internet-Draft RSVP-TE Resource Notifications November 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Resource Notification Request . . . . . . . . . . . . . . . . 5 3.1. Resource Notification Request Object . . . . . . . . . . 5 3.1.1. Procedures . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Object Format . . . . . . . . . . . . . . . . . . . . 6 4. ResourceNotify Message . . . . . . . . . . . . . . . . . . . 6 4.1. Message Format . . . . . . . . . . . . . . . . . . . . . 7 4.2. RESOURCE_SPEC Object . . . . . . . . . . . . . . . . . . 7 4.3. DEG_RESOURCE_SPEC Object . . . . . . . . . . . . . . . . 8 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Resource Unavailable . . . . . . . . . . . . . . . . . . 10 5.2. Resource Degraded . . . . . . . . . . . . . . . . . . . . 10 5.3. Fallback Procedure . . . . . . . . . . . . . . . . . . . 12 5.4. Message Reliability . . . . . . . . . . . . . . . . . . . 12 5.5. Coexistence with Existing Procedures . . . . . . . . . . 13 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.1. New RSVP Message Type . . . . . . . . . . . . . . . . . . 16 8.2. New RSVP Object Classes . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Example: Resource Unavailable . . . . . . . . . . . 18 A.1. Current Behavior (PathErr) . . . . . . . . . . . . . . . 18 A.2. Proposed Behavior (ResourceNotify) . . . . . . . . . . . 18 Appendix B. Example: Resource Degraded . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Beeram & Ramachandran Expires 6 May 2027 [Page 2] Internet-Draft RSVP-TE Resource Notifications November 2026 1. Introduction Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3209] uses PathErr messages to signal errors to the ingress of a Label Switched Path (LSP). A PathErr message is generated per LSP instance when there is an issue with setting up or maintaining RSVP Path state on a non-ingress node, and is forwarded hop-by-hop to the ingress. Given the per-LSP granularity of PathErr messages, certain network resource events can result in a storm of these messages. For example: * A Traffic Engineering (TE) link traversed by a large number of Fast Reroute (FRR) enabled [RFC4090] LSPs goes down. This results in individual PathErr messages (with "locally repaired" indication) being generated for all LSPs traversing the link. * The bandwidth on a TE link traversed by a large number of soft- preemption enabled LSPs is reduced. This results in individual PathErr messages (with "soft preempted" indication) being generated for a subset of LSPs traversing the link. In scaled networks with 100,000+ LSPs, the processing required to handle a storm of error messages can cause significant disruption to a Label Switching Router (LSR) and may result in overall degraded network performance and convergence. This document introduces RSVP Resource Notifications, a mechanism that summarizes "resource unavailable" and "resource degraded" notifications in a new RSVP message, ResourceNotify, and addresses the PathErr message storm problem. Instead of generating per-LSP PathErr messages in the normal case, a transit node generates a small number of resource-level notifications, one per unique notification recipient, that convey the affected resource and the nature of the event. The recipients of these notifications determine the affected LSPs locally and initiate appropriate remediation. The ResourceNotify mechanism is applicable to point-to-point RSVP-TE LSPs [RFC3209], point-to-multipoint (P2MP) RSVP-TE LSPs [RFC4875], and Generalized Multiprotocol Label Switching (GMPLS) LSPs [RFC3473]. Beeram & Ramachandran Expires 6 May 2027 [Page 3] Internet-Draft RSVP-TE Resource Notifications November 2026 1.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. 1.2. Terminology The following terms are used in this document: Notify-Requester: A node that has requested to receive Resource Notifications for the LSPs that it originates. In this document, the Notify-Requester is the LSP source. Resource Notification: A summarized notification that reports that a network resource (e.g., a TE link) has become unavailable or degraded. ResourceNotify: The RSVP message that carries one or more Resource Notifications from a transit node to a Notify-Requester. 2. Motivation The current RSVP-TE error reporting model generates one PathErr per affected LSP instance. While this provides precise per-LSP error information, it has significant scalability implications: * A single link failure can generate tens of thousands of PathErr messages, each requiring individual processing at every hop between the point of failure and the ingress. * The processing required for each PathErr (session lookup, state update, forwarding) is non-trivial, and a burst of these messages can overwhelm the control plane of transit nodes and ingress nodes. The presence of Interior Gateway Protocol - Traffic Engineering (IGP- TE) triggered notifications (e.g., "TE link down/deleted") does not eliminate the need for RSVP Resource Notifications. There are existing features where receiving an IGP-TE triggered "TE link down/ deleted" notification does not mean that the LSPs traversing that TE link are affected (e.g., when FRR local repair has already protected the LSPs). Beeram & Ramachandran Expires 6 May 2027 [Page 4] Internet-Draft RSVP-TE Resource Notifications November 2026 Resource Notifications reduce the message count from O(LSPs) to O(sources), where "sources" refers to unique Notify-Requesters. For a link carrying 36,000 LSPs from 3 sources, Resource Notifications reduce the PathErr storm from 36,000 messages to 3. 3. Resource Notification Request Resource Notifications are only sent to nodes that have requested them. A node requests Resource Notifications by including a Resource Notification Request Object in the RSVP PATH message, unless another specification defines an implicit procedure for requesting Resource Notifications. 3.1. Resource Notification Request Object The Resource Notification Request Object is carried in the PATH message and identifies the Notify-Requester. 3.1.1. Procedures An LSP source that requests Resource Notifications includes the Resource Notification Request Object in the PATH message, with its own address as the Notify-Requester Address. A transit node that does not support Resource Notifications ignores the Resource Notification Request Object and forwards it unmodified in the PATH message. This ensures backward compatibility. A transit node that supports Resource Notifications processes the Resource Notification Request Object as follows: * It maintains the set of unique Notify-Requesters derived from incoming PATH messages. * It tracks the set of LSPs associated with each unique Notify- Requester. If the Notify-Requester is not "TE reachable" from the transit node (i.e., there is no TE path from the transit node to the Notify- Requester), the transit node ignores the Resource Notification Request and reverts to using per-LSP PathErr notifications for such LSPs. This version of the document applies to Notify-Requesters within the same domain as the transit node. The procedures for other cases are outside the scope of this document. Beeram & Ramachandran Expires 6 May 2027 [Page 5] Internet-Draft RSVP-TE Resource Notifications November 2026 3.1.2. Object Format Class = RESOURCE_NOTIFICATION_REQUEST, C-Type = 1 (IPv4) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notify-Requester Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Resource Notification Request Object (IPv4) * Notify-Requester Address: IPv4 address of the node requesting Resource Notifications. In this version of the document, it MUST be the address of the LSP source. Class = RESOURCE_NOTIFICATION_REQUEST, C-Type = 2 (IPv6) The IPv6 variant uses a 128-bit Notify-Requester Address. The format is otherwise identical. 4. ResourceNotify Message A ResourceNotify message is generated when a network resource becomes unavailable or degraded. It is sent from a transit node to a Notify- Requester to convey the affected resource and the nature of the event. The message is addressed to the Notify-Requester Address, following the addressing of the Notify message in [RFC3473]. Two types of resource events are defined: * Resource Unavailable: A TE link has failed (e.g., link down, link deleted). * Resource Degraded: The capacity of a TE link has been reduced (e.g., a member link in an aggregate link has failed, maximum reservable bandwidth has been reduced). This document defines no notification for the restoration of a resource. A Notify-Requester learns that a resource is usable again from the existing mechanisms, for example IGP-TE advertisements, and decides when to re-optimize. Beeram & Ramachandran Expires 6 May 2027 [Page 6] Internet-Draft RSVP-TE Resource Notifications November 2026 Other specifications can define additional types of Resource Notifications by defining new objects that can be carried in the ResourceNotify message. A node that does not recognize such an object handles it as described in [RFC2205]. New object classes for additional types SHOULD be allocated from the range 10bbbbbb or 11bbbbbb, so that a node that does not support them ignores the objects and still processes the rest of the message. The TE link is the link as advertised by IGP-TE. For a bundled link, the TE link is the bundle as a whole; the failure of a member link is reported as a Resource Degraded event for the bundle. 4.1. Message Format ::= [] [ [ | ] ...] ( | | ( )) ::= (( ) | ) ::= (( ) | ) Figure 2: ResourceNotify Message Format A ResourceNotify message is addressed to a single Notify-Requester and can carry more than one Resource Notification, for example when several TE links of a node are affected at the same time. The message carries one MESSAGE_ID object, and a single acknowledgment covers all of the Resource Notifications in the message. The MESSAGE_ID and MESSAGE_ID_ACK/NACK objects are used per the existing RSVP message reliability procedures [RFC2961]. 4.2. RESOURCE_SPEC Object The RESOURCE_SPEC object identifies an unavailable TE link resource. Class = RESOURCE_SPEC, RESOURCE_SPEC_IPv4 C-Type = 1 Beeram & Ramachandran Expires 6 May 2027 [Page 7] Internet-Draft RSVP-TE Resource Notifications November 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: RESOURCE_SPEC Object (IPv4) * Link Address (32 bits): IPv4 address of the unavailable TE link. For an unnumbered link, the Router ID of the node that advertises the link. * Link Index (32 bits): Index of the unavailable TE link. For an unnumbered link, the interface identifier that the advertising node assigned to the link. Class = RESOURCE_SPEC, RESOURCE_SPEC_IPv6 C-Type = 2 The IPv6 variant uses a 128-bit Link Address field. The format is otherwise identical. 4.3. DEG_RESOURCE_SPEC Object The DEG_RESOURCE_SPEC object identifies a degraded TE link resource and carries the per-priority bandwidth amounts that the notification recipient needs to reduce. Class = DEG_RESOURCE_SPEC, DEG_RESOURCE_SPEC_IPv4 C-Type = 1 Beeram & Ramachandran Expires 6 May 2027 [Page 8] Internet-Draft RSVP-TE Resource Notifications November 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Reservable Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio 0 Degraded Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio 1 Degraded Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio 2 Degraded Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio 3 Degraded Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio 4 Degraded Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio 5 Degraded Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio 6 Degraded Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio 7 Degraded Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: DEG_RESOURCE_SPEC Object (IPv4) * Link Address (32 bits): IPv4 address of the degraded TE link. For an unnumbered link, the Router ID of the node that advertises the link. * Link Index (32 bits): Index of the degraded TE link. For an unnumbered link, the interface identifier that the advertising node assigned to the link. * Max Reservable Bandwidth (32 bits): Maximum reservable bandwidth on the degraded TE link, encoded as a 32-bit IEEE floating point number. * Prio x Degraded Bandwidth (32 bits each): Amount of bandwidth to be reduced for priority x, encoded as a 32-bit IEEE floating point number. Eight fields, one per priority level (0 through 7). Class = DEG_RESOURCE_SPEC, DEG_RESOURCE_SPEC_IPv6 C-Type = 2 The IPv6 variant uses a 128-bit Link Address field. The format is otherwise identical. Beeram & Ramachandran Expires 6 May 2027 [Page 9] Internet-Draft RSVP-TE Resource Notifications November 2026 5. Procedures 5.1. Resource Unavailable When a TE link becomes unavailable (e.g., link down), the transit node adjacent to the failed link performs the following procedure: 1. Identify all Notify-Requesters associated with LSPs traversing the failed link. 2. For each unique Notify-Requester, generate a single ResourceNotify message containing a RESOURCE_SPEC object that identifies the failed link. 3. Send the ResourceNotify message directly to the Notify-Requester (the LSP source). For the LSPs of a Notify-Requester that has requested Resource Notifications, the transit node sends the ResourceNotify message instead of per-LSP PathErr notifications, unless a condition described in Section 5.3 applies. LSPs whose Notify-Requester has not requested Resource Notifications continue to use the existing per-LSP notifications. Upon receiving a ResourceNotify message indicating resource unavailability, the Notify-Requester (the LSP source) determines the set of originating LSPs that traverse the affected resource and initiates the setup of a new LSP instance for each affected LSP along a path that avoids the failed resource. * For FRR-protected LSPs, the ingress initiates a make-before-break (MBB) re-optimization. * For unprotected LSPs, the ingress initiates a break-before-make (BBM) re-route. 5.2. Resource Degraded When the capacity of a TE link is reduced (e.g., a member link in an aggregate fails), the transit node adjacent to the degraded link performs the following procedure: 1. Determine the total amount of per-priority bandwidth that needs to be freed on the degraded link. Beeram & Ramachandran Expires 6 May 2027 [Page 10] Internet-Draft RSVP-TE Resource Notifications November 2026 2. For each unique Notify-Requester, calculate the per-priority bandwidth amount that the Notify-Requester needs to reduce on the affected link. This calculation takes into account the setup/ hold priorities and bandwidth reservations of the LSPs associated with each Notify-Requester. 3. Generate a ResourceNotify message containing a DEG_RESOURCE_SPEC object for each unique Notify-Requester. The DEG_RESOURCE_SPEC object includes the per-priority bandwidth amounts that the recipient needs to reduce. 4. Send each ResourceNotify message directly to the corresponding Notify-Requester. For the LSPs of a Notify-Requester that has requested Resource Notifications, the transit node sends the ResourceNotify message instead of per-LSP PathErr notifications, unless a condition described in Section 5.3 applies. LSPs whose Notify-Requester has not requested Resource Notifications continue to use the existing per-LSP notifications. The amount carried in a DEG_RESOURCE_SPEC object is the total reduction that the Notify-Requester still needs to make. The transit node computes it against the reservations that are in place when the message is sent; it is not an increment to an earlier notification. A ResourceNotify message for a link replaces any earlier pending requirement for that link from the same transit node. The Notify- Requester does not add the amounts of successive notifications, and it ignores a duplicate or older message, using the MESSAGE_ID as described in [RFC2961] to detect them. Because the amounts are computed when the message is sent, a Notify-Requester that has already released bandwidth can receive a notification that does not yet reflect it; it releases no more than the amount indicated. Upon receiving a ResourceNotify message indicating resource degradation, the Notify-Requester (the LSP source) determines suitable originating LSPs that can be preempted to free the indicated bandwidth and initiates the setup of new LSP instances for each preempted LSP (along paths avoiding the degraded resource), followed by the teardown of the old LSP instances. * For soft-preemption enabled LSPs, the ingress initiates MBB. * For hard-preemption enabled LSPs, the ingress initiates BBM. Beeram & Ramachandran Expires 6 May 2027 [Page 11] Internet-Draft RSVP-TE Resource Notifications November 2026 5.3. Fallback Procedure A transit node MUST implement the following fallback behavior, so that a Resource Notification that is not delivered or not acted on does not leave LSPs in an affected state. Delivery failure: The transit node uses per-LSP PathErr notifications, as defined by the existing specifications, for the LSPs of a Notify-Requester if (a) the Notify-Requester is not reachable from the transit node when the resource event occurs, so that the ResourceNotify message cannot be sent, or (b) the ResourceNotify message is not acknowledged after the configured number of retransmissions (see Section 5.4). Resource Unavailable: Once the ResourceNotify message has been acknowledged, the transit node does not send per-LSP PathErr notifications for the LSPs of that Notify-Requester that traverse the unavailable resource. The Notify-Requester has been informed, and the state of those LSPs on the transit node is handled by the existing RSVP-TE procedures. In particular, once the ResourceNotify message has been acknowledged, the transit node retains the state of the LSPs that are locally repaired [RFC4090], and those LSPs continue to use the repair path until the Notify- Requester re-routes them. The transit node does not resend the ResourceNotify message or send per-LSP PathErr notifications because the Notify-Requester has not yet acted. A new ResourceNotify message is sent only for a new resource event. If the ResourceNotify message is not acknowledged, the delivery failure rule applies instead. Resource Degraded: Once the ResourceNotify message has been acknowledged, the Notify-Requester has until the ResourceNotify Timer expires to release the indicated bandwidth. If bandwidth that needs to be freed is still held by the LSPs of that Notify- Requester when the timer expires, the transit node applies the existing per-LSP preemption procedures to those LSPs. The transit node starts the ResourceNotify Timer when it sends a ResourceNotify message that indicates a degraded resource. The ResourceNotify Timer value MUST be configurable. The value needs to allow the Notify-Requester to re-signal its affected LSPs, which can take minutes in networks with a large number of LSPs. 5.4. Message Reliability ResourceNotify messages use the reliable message delivery procedures of [RFC2961], as strengthened by [RFC8370]: Beeram & Ramachandran Expires 6 May 2027 [Page 12] Internet-Draft RSVP-TE Resource Notifications November 2026 * The sender MUST include a MESSAGE_ID object in each ResourceNotify message with the ACK_Desired flag set. * The recipient of a non-out-of-order message that contains a MESSAGE_ID object with the ACK_Desired flag set MUST respond with a MESSAGE_ID_ACK object. It can be packed with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects and sent in an Ack message, or piggybacked in any other RSVP message. * If no acknowledgment is received within the retransmission interval, the sender MUST retransmit the ResourceNotify message using exponential backoff, as described in Section 6 of [RFC2961], up to a configurable number of retransmissions. 5.5. Coexistence with Existing Procedures A Notify-Requester continues to process PathErr messages and IGP-TE advertisements as defined by the existing specifications. A ResourceNotify message is additional information that lets the Notify-Requester act on many LSPs at once; it does not replace those procedures. A Notify-Requester can receive both a ResourceNotify message and per- LSP PathErr messages for the same LSP, for example after the fallback procedure or from transit nodes that do not support this document. The Notify-Requester handles them idempotently: it does not repeat the remedial action for an LSP that is already being re-routed or has already been re-routed because of an earlier notification. 6. Applicability The ResourceNotify mechanism is applicable to LSPs whose source is within the same domain as the transit node that generates the notification (see Section 3.1.1). It is applicable to: * Traditional point-to-point RSVP-TE LSPs [RFC3209], where the LSP source is the ingress node and ResourceNotify messages are sent directly to the ingress. * Point-to-multipoint RSVP-TE LSPs [RFC4875], where the LSP source is the ingress node of the P2MP LSP. For a Resource Degraded notification, the bandwidth reserved by a P2MP LSP on a link is counted once, because the S2L sub-LSPs of a P2MP LSP share resources where they share hops [RFC4875]. * GMPLS LSPs [RFC3473], where the LSP source requests Resource Notifications via the Resource Notification Request Object in the PATH message. Beeram & Ramachandran Expires 6 May 2027 [Page 13] Internet-Draft RSVP-TE Resource Notifications November 2026 Other RSVP-TE specifications can define implicit procedures for requesting Resource Notifications for the LSPs or tunnels that they describe. For example, such a specification can define that the receipt of its signaling message is sufficient to indicate that Resource Notifications are needed, in which case the Resource Notification Request Object is not used. 7. Security Considerations The security considerations of RSVP [RFC2205], RSVP-TE [RFC3209], and the RSVP security framework [RFC5920] apply to this document. The Resource Notification Request Object and ResourceNotify message introduce new RSVP protocol elements that can be used to influence the behavior of LSP sources. An attacker who can inject or modify these messages could cause: * False resource unavailability notifications, triggering unnecessary LSP re-routing and network instability. * False resource degradation notifications with inflated bandwidth reduction values, causing excessive preemption. * Forged acknowledgments, which could make a transit node withhold per-LSP PathErr notifications when the Notify-Requester was never informed (see Section 5.3). * Replay of earlier ResourceNotify messages or acknowledgments. The MESSAGE_ID object does not protect against replay. * Suppression of legitimate Resource Notifications by stripping the Resource Notification Request Object from PATH messages. A ResourceNotify message and its acknowledgment are sent directly between the transit node and the Notify-Requester, which are generally not neighbors. The hop-by-hop integrity and authentication model of the INTEGRITY object [RFC2747] therefore does not apply to them. This situation is the same as for a Notify message sent in a non-hop-by-hop fashion, and the security considerations in Section 12 of [RFC3473] apply to ResourceNotify messages and their acknowledgments in the same way, including the use of IPsec and the option of not using the mechanism. To mitigate these threats: Beeram & Ramachandran Expires 6 May 2027 [Page 14] Internet-Draft RSVP-TE Resource Notifications November 2026 * PATH messages that carry the Resource Notification Request Object are protected in the same way as any other RSVP PATH message, for example with the INTEGRITY object [RFC2747]. This document adds no further requirement. * A transit node MUST ignore a Resource Notification Request Object whose Notify-Requester Address is not the address of the LSP source, and uses per-LSP PathErr notifications for the LSPs of that PATH message. This prevents an attacker that modifies the object from directing ResourceNotify messages to a third party. * A transit node MUST NOT treat an acknowledgment as valid if it does not come from the Notify-Requester Address to which the ResourceNotify message was sent, or, when the protection described in [RFC3473] is in use, if it fails the integrity or authentication check of that protection. Acknowledgments determine whether the fallback procedure is used. * A Notify-Requester acts only on its own LSPs that traverse the identified resource, determined from its own LSP state. When it has path information for those LSPs, for example from the Record Route Object (RRO), it SHOULD accept a ResourceNotify message only from a node on the path of those LSPs. * Implementations SHOULD rate-limit the processing of ResourceNotify messages to prevent denial-of-service attacks. * The fallback procedure (Section 5.3) provides resilience against lost Resource Notifications, provided that acknowledgments are authenticated as described above. A transit node that never sees a Resource Notification Request Object (for example, because it was stripped from PATH messages) uses per-LSP PathErr notifications as before. Without the protection described in [RFC3473], the source address checks above do not stop an attacker that can spoof addresses within the domain. The mechanism is limited to a single domain in this version of the document, and operators SHOULD apply anti-spoofing filtering at the domain border. 8. IANA Considerations This document requests IANA to make the following allocations. Beeram & Ramachandran Expires 6 May 2027 [Page 15] Internet-Draft RSVP-TE Resource Notifications November 2026 8.1. New RSVP Message Type This document requests IANA to allocate a new RSVP message type from the "Message Types" subregistry of the "Resource Reservation Protocol (RSVP) Parameters" registry: Value Description Reference ----- --------------------------- --------- TBD1 ResourceNotify [This document] 8.2. New RSVP Object Classes This document requests IANA to allocate the following new RSVP object classes from the "Class Names, Class Numbers, and Class Types" subregistry: Class Class Name Reference ----- ---------------------------------- --------- TBD2 RESOURCE_NOTIFICATION_REQUEST [This document] C-Type 1: IPv4 C-Type 2: IPv6 TBD3 RESOURCE_SPEC [This document] C-Type 1: RESOURCE_SPEC_IPv4 C-Type 2: RESOURCE_SPEC_IPv6 TBD4 DEG_RESOURCE_SPEC [This document] C-Type 1: DEG_RESOURCE_SPEC_IPv4 C-Type 2: DEG_RESOURCE_SPEC_IPv6 A node that does not support Resource Notifications has to ignore the RESOURCE_NOTIFICATION_REQUEST object and forward it unmodified in the PATH message. The class number TBD2 is therefore requested from the range 11bbbbbb, as described in Section 3.10 of [RFC2205]. 9. Acknowledgments The authors would like to thank Colby Barth for his contributions to the initial design of the resource notification mechanism. 10. References 10.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, . Beeram & Ramachandran Expires 6 May 2027 [Page 16] Internet-Draft RSVP-TE Resource Notifications November 2026 [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, . [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, . [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, . [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, . [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, . [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, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . Beeram & Ramachandran Expires 6 May 2027 [Page 17] Internet-Draft RSVP-TE Resource Notifications November 2026 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Techniques to Improve the Scalability of RSVP-TE Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, . Appendix A. Example: Resource Unavailable Consider a network with three LSP sources (S1, S2, S3) and a TE link L between nodes N5 and N6. The link L carries p LSPs from S1, q LSPs from S2, and r LSPs from S3. A.1. Current Behavior (PathErr) When link L fails, node N5 generates (p+q+r) individual PathErr messages, one for each affected LSP instance. If p=q=r=12,000, then 36,000 PathErr messages are generated and forwarded hop-by-hop to the three ingress nodes. A.2. Proposed Behavior (ResourceNotify) When link L fails, node N5 generates 3 ResourceNotify messages, one for each unique Notify-Requester (S1, S2, S3). Each ResourceNotify contains a RESOURCE_SPEC object identifying link L. Each source determines its affected LSPs locally (those traversing link L) and initiates re-routing. Appendix B. Example: Resource Degraded Using the same topology as Appendix A, when the capacity of link L is reduced (e.g., a member link in an aggregate fails), node N5 determines the per-priority bandwidth that each source needs to reduce: * S1 needs to reduce [P0..P7] bandwidth * S2 needs to reduce [Q0..Q7] bandwidth * S3 needs to reduce [R0..R7] bandwidth Node N5 generates 3 ResourceNotify messages, each containing a DEG_RESOURCE_SPEC object with the per-priority degraded bandwidth amounts customized for the recipient. Each source selects suitable LSPs for preemption based on the indicated bandwidth reduction amounts and initiates re-routing for the preempted LSPs. Beeram & Ramachandran Expires 6 May 2027 [Page 18] Internet-Draft RSVP-TE Resource Notifications November 2026 Authors' Addresses Vishnu Pavan Beeram HPE Email: vishnupavan.ietf@gmail.com Chandra Ramachandran HPE Email: chandrasekar.ramachandran@hpe.com Beeram & Ramachandran Expires 6 May 2027 [Page 19]