RFC 2379 (rfc2379) - Page 2 of 8
RSVP over ATM Implementation Guidelines
Alternative Format: Original Text Document
RFC 2379 RSVP over ATM Implementation Guidelines August 1998
This document uses the same terms and assumption stated in [2].
Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [5].
2. Implementation Recommendations
This section provides implementation guidelines for implementation of
RSVP over ATM. Several recommendations are common for all, RSVP
sessions, both unicast and multicast. There are also recommendations
that are unique to unicast and multicast session types.
2.1 RSVP Message VC Usage
The general issues related to which VC should be used for RSVP
messages is covered in [6]. It discussed several implementation
options including: mixed control and data, single control VC per
session, single control VC multiplexed among sessions, and multiple
VCs multiplexed among sessions. QoS for control VCs was also
discussed. The general discussion is not repeated here and [6]
should be reviewed for detailed information.
RSVP over ATM implementations SHOULD send RSVP control (messages)
over the best effort data path, see figure 1. It is permissible to
allow a user to override this behavior. The stated approach
minimizes VC requirements since the best effort data path will need
to exist in order for RSVP sessions to be established and in order
for RSVP reservations to be initiated. The specific best effort
paths that will be used by RSVP are: for unicast, the same VC used to
reach the unicast destination; and for multicast, the same VC that is
used for best effort traffic destined to the IP multicast group.
Note that for multicast there may be another best effort VC that is
used to carry session data traffic, i.e., for data that is both in
the multicast group and matching a sessions protocol and port.
Berger Best Current Practice