Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy
updates
- rfc-2205 — Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
Extracted elements (28)
Direct Notify is better suited to single-sender applications because with WF and SE styles a single Resv message is shared for all senders, making it impossible to guarantee notification of all affected senders via the Notify Request object in the Resv. Indirect Notify allows the Receiver Proxy to apply the same per-sender logic used for PathErr.
The PathErr-upstream-for-failure-notification approach is borrowed from RFC 3209 (RSVP-TE), where it was introduced to allow MPLS TE LSRs to notify the TE Tunnel head-end of LSP establishment failure. This reuse avoids defining a new mechanism for the same conceptual purpose.
This document explicitly does NOT propose that regular RSVP receivers generate PathErr messages on reservation failure. The rationale is that with an RSVP-capable receiver the current receiver-driven model of RFC 2205 is fully applicable, and modifying existing deployed behavior would require very strong motivation that does not exist.
A sender that does not support sender notification via Notify may include a Notify Request for upstream notifications and will receive unexpected downstream Notify messages from a supporting Receiver Proxy. Such senders are expected to drop downstream notifications as invalid; the RECOMMENDED fallback PathErr path ensures they are still notified of reservation failure.
Policy-Ignorant Nodes (PINs) and policy-capable nodes that do not recognize the Receiver Proxy Control policy element apply the default handling defined in RFC 2750 Section 4.2, ensuring these objects can traverse such nodes in transit between Policy Enforcement Points.
The Path_State_Removed flag should only be enabled on the Receiver Proxy in controlled environments where all routers are known to support it. In environments with 'old RSVP routers' that do not understand the flag, using it results in slower resource release and increased signaling because old routers propagate the flag but do not tear Path state, forcing release via refresh timeout.
A router implementation claiming compliance SHOULD support the dynamic discovery of downstream RSVP functionality method defined in Section 4.1. When generating a proxy Resv message upstream, a supporting Receiver Proxy MUST forward the Path message downstream instead of terminating it.
A router implementation claiming compliance with this document MUST support the sender notification via PathErr message method defined in Section 3.1. The MAY method via Notify message in Section 3.2 is optional.
An RSVP Receiver Proxy that understands the Receiver Proxy Control policy element MUST attempt to insert itself as Receiver Proxy when Control-Value is 1 (Receiver-Proxy-Needed), and MUST NOT attempt to insert itself when Control-Value is 2 (Receiver-Proxy-Not-Needed).
An RSVP sender interested in being notified of reservation failure via Notify MUST include a Notify Request object (containing the sender's IP address) in the Path messages it generates.
By default, the RSVP Receiver Proxy MUST NOT include the Path_State_Removed flag in the ERROR_SPEC of the PathErr message, ensuring predictable operations in environments where some RSVP routers do not understand that flag.
For ERROR_SPEC composition: if the Receiver Proxy receives a ResvErr with error code 1 (Admission Control Failure) or code 2 (Policy Control Failure), it copies the error code and value into the PathErr's ERROR_SPEC; the error node MUST be set to the address of the Receiver Proxy. For all other error codes, a new ERROR_SPEC with error code 36 (Unrecoverable Receiver Proxy Error) MUST be composed.
For FF-style reservations, the Receiver Proxy MUST send a PathErr towards the single sender matching the failed reservation. For SE-style reservations, the Receiver Proxy MUST send PathErr(s) towards the set of senders that triggered reservations that failed. For WF-style reservations, the Receiver Proxy SHOULD send a PathErr towards each sender.
The RSVP Receiver Proxy MUST generate a PathErr message whenever: (1) the reservation establishment has failed or the previously established reservation has been torn down, and (2) the Receiver Proxy determines it cannot re-establish the reservation.
Upon receiving a downstream error notification, the RSVP Receiver Proxy MUST generate a Notify message with upstream notification to the corresponding sender if Indirect Notification is used, and SHOULD do so if Direct Notification is used (since the failure node may not support Notify).
Upon receiving a Path message with a Notify Request object, the RSVP Receiver Proxy MUST include a Notify Request object in the Resv messages it generates, containing either the sender's address (Direct Notify) or an address of the Receiver Proxy itself (Indirect Notify).
When a downstream Resv message reaches the Receiver Proxy, it MUST internally convert its state from a proxied reservation to regular midpoint RSVP behavior, and from then on MUST behave as a regular RSVP router for that reservation.
When the Notify method is used, it is RECOMMENDED that the RSVP Receiver Proxy also issue a sender notification via a PathErr message to maximize the chances the notification reaches the sender even if some routers do not support Notify.
Error Code 36: Unrecoverable Receiver Proxy Error is used in PathErr ERROR_SPEC when the Receiver Proxy receives a ResvErr with any error code other than 1 or 2. The 16-bit Error Value field encodes the original error code in the low 8 bits when the high 8 bits are set to 0x01.
The RSVP Receiver Proxy is an RSVP-capable router that performs RSVP signaling on behalf of a non-RSVP-capable receiver. Upon receiving a Path message it establishes Path state, identifies the downstream interface, sinks the Path, and acts as if a corresponding Resv was received from the receiver.
IANA allocated P-Type 0x07 to the Receiver Proxy Control policy element and created the 'Receiver Proxy Control Policy Element (P-Type 0x07) Control-Value field' registry with values: 0 (Reserved), 1 (Receiver-Proxy-Needed), 2 (Receiver-Proxy-Not-Needed); 3-127 IETF Review, 128-240 First Come First Served, 241-255 Private Use.
IANA updated the 'Error Codes and Globally-Defined Error Value Sub-Codes' registry to allow Error Code 1 (Admission Control Failure) and Error Code 2 (Policy Control Failure) in PathErr messages (previously only ResvErr), and allocated new Error Code 36: Unrecoverable Receiver Proxy Error.
RSVP authentication mechanisms from RFC 2747 and RFC 3097 SHOULD be supported by implementations of this document; these protect RSVP message integrity hop-by-hop, provide node authentication, and replay protection against corruption and spoofing.
The integrity of the Receiver Proxy Control policy element can be protected via two optional mechanisms: (1) the RSVP INTEGRITY object in RSVP messages providing a chain of trust, or (2) the INTEGRITY object within the POLICY_DATA object for guaranteeing integrity between non-adjacent PEPs. The latter MAY be supported.
The Notify message used in Section 3.2 can be sent non-hop-by-hop, precluding standard RSVP hop-by-hop integrity. Where the same level of security as RFC 2747 is desired, IPsec-based integrity and authentication (RFC 4302 or RFC 4303) can be used, or non-hop-by-hop Notify messages can be disabled.
The use of an RSVP Receiver Proxy can actually reduce security risks in environments where receivers are in physically unsecured locations. The operator can place filters at the network edge to discard any RSVP messages received from end-users, completely excluding untrusted receivers from the reservation and admission control operation.
A Receiver Proxy transitions from proxied-reservation state to regular-RSVP-midpoint state upon receiving a Resv message from downstream (indicating an RSVP-capable receiver or downstream Receiver Proxy exists). Trigger: receipt of downstream Resv. From that point it behaves as if it never acted as a Receiver Proxy for the flow.
The Receiver Proxy Control policy element is 8 bytes total: Length (16 bits, always 8), P-Type (16 bits, REC_PROXY_CONTROL = 0x07), Reserved (24 bits, SHALL be zero on transmit and ignored on reception), and Control-Value (8 bits unsigned).