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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/