RSVP over ATM Implementation Requirements
Extracted elements (28)
Although RSVP control is receiver-oriented and ATM control is sender-oriented, this mismatch is resolved by requiring subnet senders to initiate all QoS VCs. This allows senders to use different flow-to-VC mappings and QoS renegotiation techniques without interoperability problems.
Traditional VC inactivity timeout mechanisms are unnecessary and harmful for RSVP-controlled VCs because RSVP provides explicit mechanisms (messages and timeouts) to determine when a data VC is no longer needed. Premature teardown would break reservation state synchronization.
When a new next-hop with a larger reservation arrives in a heterogeneous multicast session, the dynamic QoS process SHOULD be initiated before adding the new next-hop, and the new next-hop should be the first end-point of the new VC, to minimize signaling when setup to the new next-hop fails.
When a QoS downgrade replacement VC fails, the larger-than-needed old allocation is intentionally left in place because it maximizes service delivery to the user and conforms to RSVP error handling rules in RFC 2205 sections 2.5, 3.1.8, and 3.11.2.
LANE2.0 provides provisions allowing non-server solutions that may enable proper QoS delivery, unlike LANE1.0 which only supports distribution via the Broadcast and Unknown Server and therefore always requires the break bit to be set.
This document defines requirements for implementations using ATM UNI 3.x and 4.0 supporting both CLIP/ION, LANE2.0, and MPOA methods for IP over ATM. All implementations must adhere to these requirements to ensure interoperability.
When using RSVP automatic tunneling through non-RSVP routers, multicast end-point identification becomes problematic: the RESV message may arrive via a different route than the PATH message, making it impossible to identify the correct ATM end-point for the reservation.
All RSVP over ATM implementations MUST be able to support LLC encapsulation per RFC 1483 on RSVP-triggered QoS VCs. When a QoS VC carries only IP packets, implementations SHOULD negotiate VC-based multiplexing to avoid LLC header overhead.
Baseline RSVP over ATM implementations MUST only establish RSVP-initiated VCs to RSVP-capable end-points, to ensure proper behavior when unique end-point identification is unavailable. A user override is permissible.
Data MUST NOT be sent on new point-to-multipoint VCs until all parties have been added, ensuring data is only delivered once to all receivers during initial QoS VC setup and QoS change transitions.
During setup of a replacement QoS VC (for dynamic QoS changes), the old VC MUST be left in place unmodified until the replacement is established, to minimize interruption of QoS data delivery.
For MARS-based networks, administrators MUST configure mesh mode distribution for multicast groups used in RSVP sessions. For LANE1.0 networks, the break bit MUST always be set since the only distribution option is via the Broadcast and Unknown Server.
If setup of a replacement VC fails and the new reservation is greater than the old, the reservation request MUST be answered with an error. If the new reservation is less than the old, the request MUST be treated as if the modification was successful.
Implementations MUST ensure that data traffic is sent to best effort receivers and MUST NOT create VCs in such a way that data cannot be sent to best effort receivers.
Implementations MUST NOT normally send more than one copy of a particular data packet to a particular next-hop (ATM end-point). Some transient duplicate transmission is acceptable only during VC setup and transition.
RSVP over ATM implementations MUST NOT send RSVP control messages on the same QoS VC as RSVP associated data packets. Implementations MAY send RSVP messages on either the best effort data path or on a separate control VC.
RSVP over ATM implementations MUST NOT use an inactivity timer to clear any received connections, conforming to the update in RFC 2331.
RSVP over ATM implementations SHOULD support mesh-mode distribution for RSVP-controlled multicast flows because current multicast servers do not support mechanisms for communicating QoS requirements.
Subnet senders MUST establish all QoS VCs and RSVP-enabled subnet receivers MUST be able to accept incoming QoS VCs. This sender-initiated VC control is consistent with RSVP version 1 processing rules.
The configurable inactivity timer MUST be set to 'infinite' for VCs initiated at the request of RSVP. This overrides RFC 1755's recommendation to tear down VCs inactive for twenty minutes.
When adding a new end-point to an existing QoS VC (transitioning from best effort), the add to the QoS VC MUST be completed first, then followed by the drop from the best effort VC, to avoid data loss. Receivers must be prepared to receive some duplicate packets during QoS setup.
When sending data in the backwards direction on an RSVP-initiated QoS point-to-point VC, the sender MUST ensure the data conforms to the backwards direction traffic parameters.
When the VC used to forward RSVP control messages is abnormally released and cannot be reestablished, the RSVP associated QoS VCs MUST also be released. This maintains synchronization between forwarding and reservation states.
When using multicast servers that do not support QoS requests, a sender MUST set the service-specific (not global) break bit(s) to inform receivers that RSVP and Integrated Services are supported but the service cannot be delivered over ATM for the specific request.
Dynamic QoS changes are implemented by establishing a replacement VC at the new QoS level while keeping the old VC active. Data transmission is shifted to the new VC only after it is fully established, and only then is the old VC closed.
RSVP over ATM uses two separate VC categories: QoS VCs carrying reserved data flows, and a separate path (best effort data path or dedicated control VC) carrying RSVP control messages. These must remain distinct at all times.
The service-specific break bit in RSVP is used to signal to receivers that RSVP and Integrated Services are supported by the router but that the requested service cannot be delivered over the ATM network. This is distinct from the global break bit.
No additional security issues are raised in this document beyond those already stated in the base RSVP specification (RFC 2205) and the ATM Signalling Support for IP over ATM specification (RFC 1755). Implementers should consult those documents for applicable security considerations.