As per Relevance of the word multicast, we have this rfc below:
Network Working Group L.
Request for Comments: 2380 FORE
Category: Standards Track August 1998
RSVP over ATM Implementation
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This memo presents specific implementation requirements for
RSVP over ATM switched virtual circuits (SVCs). It
requirements that ensure interoperability between
implementations and conformance to the RSVP and Integrated
specifications. A separate document [5] provides specific
for running over today's ATM networks. The general problem
discussed in [9]. Integrated Services to ATM service mappings
covered in [6]. The full set of documents present the background
information needed to implement Integrated Services and RSVP
ATM
Table of
1. Introduction ................................................. 2
1.1 Terms .................................................... 2
1.2 Assumptions .............................................. 3
2. General RSVP Session Support ................................. 4
2.1 RSVP Message VC Usage .................................... 4
2.2 VC Initiation ............................................ 4
2.3 VC Teardown .............................................. 5
2.4 Dynamic QoS .............................................. 6
2.5 Encapsulation ............................................ 6
3. Multicast RSVP Session Support ............................... 7
3.1 Data VC Management for Heterogeneous Sessions ............ 7
3.2 Multicast End-Point Identification ....................... 8
3.3 Multicast Data Distribution .............................. 9
3.4 Receiver Transitions ..................................... 11
Berger Standards Track [Page 1]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
4. Security Considerations ...................................... 11
5. Acknowledgments .............................................. 11
6. Author's Address ............................................. 12
REFERENCES ...................................................... 13
FULL COPYRIGHT STATEMENT ........................................ 14
1.
This memo discusses running IP over ATM in an environment where
are used to support QoS flows and RSVP is used as the internet
QoS signaling protocol. It applies when using CLIP/ION, LANE2.0
MPOA [4] methods for supporting IP over ATM. The general
related to running RSVP [8] over ATM have been covered in
papers including [9] and other earlier work. This document
intended as a companion to [9,5]. The reader should be familiar
both documents
This document defines the specific requirements for
using ATM UNI3.x and 4.0. These requirements must be adhered to
all RSVP over ATM implementations to ensure interoperability
Further recommendations to guide implementers of RSVP over ATM
provided in [5].
The rest of this section will define terms and assumptions. Section 2
will cover implementation guidelines common to all RSVP session
Section 3 will cover implementation guidelines specific to
sessions
1.1
The terms "reservation" and "flow" are used in many contexts,
with different meaning. These terms are used in this document
the following meaning
o Reservation is used in this document to refer to an
initiated request for resources. RSVP initiates requests
resources based on RESV message processing. RESV messages
simply refresh state do not trigger resource requests.
requests may be made based on RSVP sessions and RSVP
styles. RSVP styles dictate whether the reserved resources
used by one sender or shared by multiple senders. See [8]
details of each. Each new request is referred to in
document as an RSVP reservation, or simply reservation
Berger Standards Track [Page 2]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
o Flow is used to refer to the data traffic associated with
particular reservation. The specific meaning of flow is
style dependent. For shared style reservations, there is
flow per session. For distinct style reservations, there is
flow per sender (per session).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [7].
1.2
The following assumptions are made
o
We assume RSVP as the internet signaling protocol which
described in [8]. The reader is assumed to be familiar
[8].
o IPv4 and IPv
RSVP support has been defined for both IPv4 and IPv6.
guidelines in this document are intended to be used to
RSVP with either IPv4 or IPv6. This document does not
one version over the other
o Best effort service
The current Internet only supports best effort service.
assume that as additional components of the Integrated
model are defined, best effort service must continue to
supported
o ATM UNI 3.x and 4.0
We assume ATM service as defined by UNI 3.x and 4.0.
provides both point-to-point and point-to-multipoint
Circuits (VCs) with a specified Quality of Service (QoS).
provides both Permanent Virtual Circuits (PVCs) and
Virtual Circuits (SVCs). In the Permanent Virtual Circuit (PVC
environment, PVCs are typically used as point-to-point
replacements. So the support issues are similar to point-to
point links. This memo assumes that SVCs are used to
RSVP over ATM
Berger Standards Track [Page 3]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
2. General RSVP Session
This section provides implementation requirements that are common
all (both unicast and multicast) RSVP sessions. The section
VC usage, QoS VC initiation, VC teardown, handling requested
in QoS, and encapsulation
2.1 RSVP Message VC
There are several RSVP Message VC Usage options available
implementers. Implementers must select which VC to use for
messages and how to aggregate RSVP sessions over QoS VCs.
options have been covered in [9] and some specific
guidelines are stated in [5]. In order to ensure
between implementations that follow different options, RSVP over
implementations MUST NOT send RSVP (control) messages on the same
VC as RSVP associated data packets. RSVP over ATM
MAY send RSVP messages on either the best effort data path or on
separate control VC
Since RSVP (control) messages and RSVP associated data packets
not sent on the same VCs, it is possible for a VC supporting one
of traffic to fail while the other remains in place. When the
associated with data packets fails and cannot be reestablished,
SHOULD treat this as an allocation failure. When the VC used
forward RSVP control messages is abnormally released and cannot
reestablished, the RSVP associated QoS VCs MUST also be released
The release of the associated data VCs is required to maintain
synchronization between forwarding and reservation states for
associated data flows
2.2 VC
There is an apparent mismatch between RSVP and ATM. Specifically
RSVP control is receiver oriented and ATM control is sender oriented
This initially may seem like a major issue but really is not.
RSVP reservation (RESV) requests are generated at the receiver
actual allocation of resources takes place at the subnet sender
For data flows, this means that subnet senders MUST establish all
VCs and the RSVP enabled subnet receiver MUST be able to
incoming QoS VCs. These restrictions are consistent with
version 1 processing rules and allow senders to use different flow
VC mappings and even different QoS renegotiation techniques
interoperability problems. All RSVP over ATM approaches that
VCs initiated and controlled by the subnet senders will interoperate
Figure 1 shows this model of data flow VC initiation
Berger Standards Track [Page 4]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
Data Flow ==========>
+-----+
| | --------------> +----+
| Src | --------------> | R1 |
| *| --------------> +----+
+-----+ QoS
/\
||
VC ||
Figure 1: Data Flow VC
RSVP over ATM implementations MAY send data in the
direction on an RSVP initiated QoS point-to-point VC. When
in the backwards data path, the sender MUST ensure that the
conforms to the backwards direction traffic parameters. Since
traffic parameters are set by the VC initiator, it is quite
that no resources will be requested for traffic originating at
called party. It should be noted that the backwards data path is
available with point-to-multipoint VCs
2.3 VC
VCs supporting IP over ATM data are typically torndown based
inactivity timers. This mechanism is used since IP is
and there is therefore no way to know when a VC is no longer needed
Since RSVP provides explicit mechanisms (messages and timeouts)
determine when an associated data VC is no longer needed,
traditional VC timeout mechanisms are not needed. Additionally,
normal operations RSVP implementations expect to be able to
resources and have those resources remain allocated until released
the direction of RSVP. Therefore, data VCs set up to support
controlled flows should only be released at the direction of RSVP
Such VCs must not be timed out due to inactivity by either the
initiator or the VC receiver. This conflicts with VCs timing out
described in RFC 1755 [11], section 3.4 on VC Teardown. RFC 1755
recommends tearing down a VC that is inactive for a certain length
time. Twenty minutes is recommended. This timeout is
implemented at both the VC initiator and the VC receiver. Although
section 3.1 of the update to RFC 1755 [12] states that
timers must not be used at the VC receiver
In RSVP over ATM implementations, the configurable inactivity
mentioned in [11] MUST be set to "infinite" for VCs initiated at
request of RSVP. Setting the inactivity timer value at the
initiator should not be problematic since the proper value can
Berger Standards Track [Page 5]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
relayed internally at the originator. Setting the inactivity
at the VC receiver is more difficult, and would require
mechanism to signal that an incoming VC was RSVP initiated. To
this complexity and to conform to [12], RSVP over ATM
MUST not use an inactivity timer to clear any received connections
2.4 Dynamic
As stated in [9], there is a mismatch in the service provided by
and that provided by ATM UNI3.x and 4.0. RSVP allows
to QoS parameters at any time while ATM does not support
modifications to QoS parameters post VC setup. See [9] for
detail
The method for supporting changes in RSVP reservations is to
to replace an existing VC with a new appropriately sized VC.
setup of the replacement VC, the old VC MUST be left in
unmodified. The old VC is left unmodified to minimize interruption
QoS data delivery. Once the replacement VC is established,
transmission is shifted to the new VC, and only then is the old
closed
If setup of the replacement VC fails, then the old QoS VC
continue to be used. When the new reservation is greater than
old reservation, the reservation request MUST be answered with
error. When the new reservation is less than the old reservation,
request MUST be treated as if the modification was successful.
leaving the larger allocation in place is suboptimal, it
delivery of service to the user. The behavior is also required
order to conform to RSVP error handling as defined in sections 2.5,
3.1.8 and 3.11.2 of [8]. Implementations SHOULD retry replacing
too large VC after some appropriate elapsed time
One additional issue is that only one QoS change can be processed
one time per reservation. If the (RSVP) requested QoS is
while the first replacement VC is still being setup, then
replacement VC SHOULD BE released and the whole VC
process is restarted. Implementations MAY also limit number
changes processed in a time period per [9].
2.5
There are multiple encapsulation options for data sent over
triggered QoS VCs. All RSVP over ATM implementations MUST be able
support LLC encapsulation per RFC 1483 [10] on such QoS VCs
Implementations MAY negotiate alternative encapsulations using
B-LLI negotiation procedures defined in ATM Signalling, see [11]
Berger Standards Track [Page 6]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
details. When a QoS VC is only being used to carry IP packets
implementations SHOULD negotiate VC based multiplexing to
incurring the overhead of the LLC header
3. Multicast RSVP Session
There are several aspects to running RSVP over ATM that are unique
multicast sessions. This section addresses multicast end-
identification, multicast data distribution, multicast
transitions and next-hops requesting different QoS
(heterogeneity) which includes the handling of multicast best
receivers. Handling of best effort receivers is not strictly an
issue, but needs to be addressed by any RSVP over ATM
in order to maintain expected best effort internet service
3.1 Data VC Management for Heterogeneous
The issues relating to data VC management of heterogeneous
are covered in detail in [9]. In summary, heterogeneity occurs
receivers request different levels of QoS within a single session
and also when some receivers do not request any QoS. Both types
heterogeneity are shown in figure 2.
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
IP
Figure 2: Types of Multicast
[9] provides four models for dealing with heterogeneity:
heterogeneity, limited heterogeneity, homogeneous, and
homogeneous models. No matter which model or combination of
is used by an implementation, implementations MUST NOT normally
Berger Standards Track [Page 7]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
more than one copy of a particular data packet to a particular next
hop (ATM end-point). Some transient duplicate transmission
acceptable, but only during VC setup and transition
Implementations MUST also ensure that data traffic is sent to
effort receivers. Data traffic MAY be sent to best effort
via best effort or QoS VCs as is appropriate for the
model. In all cases, implementations MUST NOT create VCs in such
way that data cannot be sent to best effort receivers. This
the case of not being able to add a best effort receiver to a QoS VC
but does not include the case where best effort VCs cannot be setup
The failure to establish best effort VCs is considered to be
general IP over ATM failure and is therefore beyond the scope of
document
There is an interesting interaction between dynamic QoS
heterogeneous requests when using the limited heterogeneity
homogeneous, or modified homogeneous models. In the case where
RESV message is received from a new next-hop and the
resources are larger than any existing reservation, both dynamic
and heterogeneity need to be addressed. A key issue is whether
first add the new next-hop or to change to the new QoS. This is
fairly straight forward special case. Since the older,
reservation does not support the new next-hop, the dynamic
process SHOULD be initiated first. Since the new QoS is only
by the new next-hop, it SHOULD be the first end-point of the new VC
This way signaling is minimized when the setup to the new next-
fails
3.2 Multicast End-Point
Implementations must be able to identify ATM end-points
in an IP multicast group. The ATM end-points will be IP
receivers and/or next-hops. Both QoS and best effort end-points
be identified. RSVP next-hop information will usually provide
end-points, but not best effort end-points
There is a special case where RSVP next-hop information will
provide the appropriate end-points. This occurs when a next-hop
not RSVP capable and RSVP is being automatically tunneled. In
case a PATH message travels through a non-RSVP egress router on
way to the next-hop RSVP node. When the next-hop RSVP node sends
RESV message it may arrive at the source via a different route
used by the PATH message. The source will get the RESV message,
will not know which ATM end-point should be associated with
reservation. For unicast sessions, there is no problem since the
end-point will be the IP next-hop router. There is a problem
Berger Standards Track [Page 8]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
multicast, since multicast routing may not be able to
identify the IP next-hop router. It is therefore possible for
multicast end-point to not be properly identified
In certain cases it is also possible to identify the list of all
effort end-points. Some multicast over ATM control mechanisms,
as MARS in mesh mode, can be used to identify all end-points of
multicast group. Also, some multicast routing protocols can
all next-hops for a particular multicast group. In both cases,
over ATM implementations can obtain a full list of end-points,
QoS and non-QoS, using the appropriate mechanisms. The full list
then be compared against the RSVP identified end-points to
the list of best effort receivers
While there are cases where QoS and best effort end-points can
identified, there is no straightforward solution to
identifying end-points of multicast traffic handled by non-
next-hops. The preferred solution is to use multicast
mechanisms and routing protocols that support unique end-
identification. In cases where such mechanisms and routing
are unavailable, all IP routers that will be used to support
over ATM should support RSVP. To ensure proper behavior,
RSVP over ATM implementations MUST only establish RSVP-initiated
to RSVP capable end-points. It is permissible to allow a user
override this behavior
3.3 Multicast Data
Two basic models exist for IP multicast data distribution over ATM
In one model, senders establish point-to-multipoint VCs to all
attached destinations, and data is then sent over these VCs.
model is often called "multicast mesh" or "VC mesh"
distribution. In the second model, senders send data over point-to
point VCs to a central point and the central point relays the
onto point-to-multipoint VCs that have been established to
receivers of the IP multicast group. This model is often referred
as "multicast server" mode distribution. Figure 3 shows data flow
both modes of IP multicast data distribution
Berger Standards Track [Page 9]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
_________
/ \
/ Multicast \
\ Server /
\_________/
^ | |
| | +--------+
+-----+ | | |
| | -------+ | | Data Flow
| Src | ...+......|....+ V ---->
| | : | : +----+ ....>
+-----+ : | +...>| R1 |
: | +----+
:
: +----+
+..> | R2 |
+----+
Figure 3: IP Multicast Data Distribution Over
The goal of RSVP over ATM solutions is to ensure that IP
data is distributed with appropriate QoS. Current multicast
[1,2] do not support any mechanisms for communicating
requirements to a multicast server. For this reason, RSVP over
implementations SHOULD support "mesh-mode" distribution for
controlled multicast flows. When using multicast servers that do
support QoS requests, a sender MUST set the service, not global
break bit(s). Use of the service-specific break bit tells
receiver(s) that RSVP and Integrated Services are supported by
router but that the service cannot be delivered over the ATM
for the specific request
In the case of MARS [1], the selection of distribution modes
administratively controlled. Therefore network administrators
desire proper RSVP over ATM operation MUST appropriately
their network to support mesh mode distribution for multicast
that will be used in RSVP sessions. For LANE1.0 networks the
multicast distribution option is over the LANE Broadcast and
Server which means that the break bit MUST always be set.
LANE2.0 [3] there are provisions that allow for non-server
with which it may be possible to ensure proper QoS delivery
Berger Standards Track [Page 10]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
3.4 Receiver
When setting up a point-to-multipoint VCs there will be a time
some receivers have been added to a QoS VC and some have not
During such transition times it is possible to start sending data
the newly established VC. If data is sent both on the new VC and
old VC, then data will be delivered with proper QoS to some
and with the old QoS to all receivers. Additionally, the
receivers would get duplicate data. If data is sent just on the
QoS VC, the receivers that have not yet been added will miss data
So, the issue comes down to whether to send to both the old and
VCs, or to just send to one of the VCs. In one case duplicate
will be received, in the other some data may not be received.
issue needs to be considered for three cases: when establishing
first QoS VC, when establishing a VC to support a QoS change,
when adding a new end-point to an already established QoS VC
The first two cases are essentially the same. In both, it
possible to send data on the partially completed new VC. In both
there is the option of duplicate or lost data. In order to
predictable behavior and to conform to the requirement to
data to all receivers, data MUST NOT be sent on new VCs until
parties have been added. This will ensure that all data is
delivered once to all receivers
The last case differs from the others and occurs when an end-
must be added to an existing QoS VC. In this case the end-point
be both added to the QoS VC and dropped from a best effort VC.
issue is which to do first. If the add is first requested, then
end-point may get duplicate data. If the drop is requested first
then the end-point may miss data. In order to avoid loss of data
the add MUST be completed first and then followed by the drop.
behavior requires receivers to be prepared to receive some
packets at times of QoS setup
4. Security
The same considerations stated in [8] and [11] apply to
document. There are no additional security issues raised in
document
5.
This work is based on earlier drafts and comments from the
working group. The author would like to acknowledge
contribution, most notably Steve Berson who coauthored one of
drafts
Berger Standards Track [Page 11]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
6. Author's
Lou
FORE
1595 Spring Hill
5th
Vienna, VA 22182
Phone: +1 703-245-4527
EMail: lberger@fore.
Berger Standards Track [Page 12]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
[1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
Networks," RFC 2022, November 1996.
[2] The ATM Forum, "LAN Emulation Over ATM Specification",
1.0.
[3] The ATM Forum, "LAN Emulation over ATM Version 2 -
Specification", April 1997.
[4] The ATM Forum, "MPOA Baseline Version 1", May 1997.
[5] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24,
RFC 2379, August 1998.
[6] Borden, M., and M. Garrett, "Interoperation of Controlled-
and Guaranteed-Service with ATM", RFC 2381, August 1998.
[7] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[8] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin
"Resource ReSerVation Protocol (RSVP) -- Version 1
Specification", RFC 2205, September 1997.
[9] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M.,
J. Krawczyk, "A Framework for Integrated Services and RSVP
ATM", RFC 2382, August 1998.
[10] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, July 1993.
[11] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E.,
A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
February 1995.
[12] Maher, M., "ATM Signalling Support for IP over ATM - UNI 4.0
Update", RFC 2331, April 1998.
Berger Standards Track [Page 13]
RFC 2380 RSVP over ATM Implementation Requirements August 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Berger Standards Track [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
