draft-ietf-issll-atm-imp-req-01.txt   draft-ietf-issll-atm-imp-req-02.txt 
Internet Draft L. Berger Internet Draft L. Berger
Expires: May 1998 FORE Systems Expires: July 1998 FORE Systems
File: draft-ietf-issll-atm-imp-req-01.txt File: draft-ietf-issll-atm-imp-req-02.txt
RSVP over ATM Implementation Requirements RSVP over ATM Implementation Requirements
November 18, 1997 January 5, 1998
Status of Memo Status of Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Rim). Rim).
Abstract Abstract
This note presents specific implementation requirements for running This note 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 [8]. 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 ........................................................3
1.1 Terms ...........................................................3 1.1 Terms ...........................................................3
1.2 Assumptions .....................................................4 1.2 Assumptions .....................................................4
2. General RSVP Session Support ........................................4 2. General RSVP Session Support ........................................4
2.1 RSVP Message VC Usage ...........................................4 2.1 RSVP Message VC Usage ...........................................5
2.2 VC Initiation ...................................................5 2.2 VC Initiation ...................................................5
2.3 VC Teardown .....................................................6 2.3 VC Teardown .....................................................6
2.4 Dynamic QoS .....................................................7 2.4 Dynamic QoS .....................................................7
2.5 Encapsulation ...................................................7 2.5 Encapsulation ...................................................7
3. Multicast RSVP Session Support ......................................8 3. Multicast RSVP Session Support ......................................8
3.1 Data VC Management for Heterogeneous Sessions ...................8 3.1 Data VC Management for Heterogeneous Sessions ...................8
3.2 Multicast End-Point Identification ..............................9 3.2 Multicast End-Point Identification ..............................9
3.3 Multicast Data Distribution .....................................10 3.3 Multicast Data Distribution .....................................10
3.4 Receiver Transitions ............................................11 3.4 Receiver Transitions ............................................12
4. Security ............................................................12 4. Security ............................................................12
5. Acknowledgments .....................................................12 5. Acknowledgments .....................................................12
6. Author's Address ....................................................12 6. Author's Address ....................................................13
1. Introduction 1. Introduction
This note discusses running IP over ATM in an environment where SVCs This note 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[7] over ATM have been covered in several related to running RSVP[8] over ATM have been covered in several
papers including [8] and other superseded internet drafts. This papers including [9] and other earlier work. This document is
document is intended as a companion to [8,5]. The reader should be intended as a companion to [9,5]. The reader should be familiar with
familiar with both documents. both documents.
This document will define 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.
skipping to change at page 3, line 40 skipping to change at page 3, line 40
often with different meaning. These terms are used in this often with different meaning. These terms are used in this
document with the following meaning: document with 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 simply refresh state do not trigger resource requests. that simply refresh state do not trigger resource requests.
Resource requests may be made based on RSVP sessions and RSVP Resource requests may be made based on RSVP sessions and RSVP
reservation styles. RSVP styles dictate whether the reserved reservation styles. RSVP styles dictate whether the reserved
resources are used by one sender or shared by multiple resources are used by one sender or shared by multiple
senders. See [7] for details of each. Each new request is senders. See [8] for details of each. Each new request is
referred to in this document as an RSVP reservation, or referred to in this 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 flow per sender (per session). one flow per sender (per session).
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 [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 signalling protocol which is We assume RSVP as the internet signaling protocol which is
described in [7]. The reader is assumed to be familiar with described in [8]. The reader is assumed to be familiar with
[7]. [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 RSVP with either IPv4 or IPv6. This document does support RSVP with either IPv4 or IPv6. This document does
not require one version over the other. not require 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 model that best effort service must continue to be a Services model that 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 provides both Permanent Virtual Circuits (PVCs) and ATM provides both Permanent Virtual Circuits (PVCs) and
Switched Virtual Circuits (SVCs). In the Permanent Virtual Switched Virtual Circuits (SVCs). In the Permanent Virtual
Circuit (PVC) environment, PVCs are typically used as point- Circuit (PVC) environment, PVCs are typically used as point-
skipping to change at page 5, line 4 skipping to change at page 5, line 10
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 [8] 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 implementations MUST NOT send RSVP (control) messages on the ATM implementations MUST NOT send RSVP (control) messages on the
same QoS VC as RSVP associated data packets. RSVP over ATM same QoS VC as RSVP associated data packets. RSVP over ATM
implementations MAY send RSVP messages on either the best effort implementations MAY send RSVP messages on either the best effort
data path or on a separate control VC. data path or on a 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 of traffic to fail while the other remains in place. When type of traffic to fail while the other remains in place. When
the VC associated with data packets fails and cannot be the VC associated with data packets fails and cannot be
reestablished, RSVP should treat this as an allocation failure. reestablished, RSVP SHOULD treat this as an allocation failure.
When the VC used to forward RSVP control messages is abnormally When the VC used to forward RSVP control messages is abnormally
released and cannot be reestablished, the RSVP associated QoS VCs released and cannot be reestablished, the RSVP associated QoS VCs
MUST also be released. The release of the associated data VCs is MUST also be released. The release of the associated data VCs is
required to maintain the synchronization between forwarding and required to maintain the synchronization between forwarding and
reservation states for the associated data flows. reservation states for the 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. This initially may seem like a major issue but really oriented. This initially may seem like a major issue but really
is not. While RSVP reservation (RESV) requests are generated at is not. While RSVP reservation (RESV) requests are generated at
the receiver, actual allocation of resources takes place at the the receiver, actual allocation of resources takes place at the
sub-net sender. subnet sender.
For data flows, this means that sub-net senders MUST establish all For data flows, this means that subnet senders MUST establish all
QoS VCs and the RSVP enabled sub-net receiver MUST be able to QoS VCs and the RSVP enabled subnet receiver MUST be able to
accept incoming QoS VCs. These restrictions are consistent with accept incoming QoS VCs. These restrictions are consistent with
RSVP version 1 processing rules and allow senders to use different RSVP version 1 processing rules and allow senders to use different
flow to VC mappings and even different QoS renegotiation flow to VC mappings and even different QoS renegotiation
techniques without interoperability problems. All RSVP over ATM techniques without interoperability problems. All RSVP over ATM
approaches that have VCs initiated and controlled by the sub-net approaches that have VCs initiated and controlled by the subnet
senders will interoperate. Figure 1 shows this model of data flow senders will interoperate. 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 a RSVP initiated QoS point-to-point VC. When sending direction on an RSVP initiated QoS point-to-point VC. When
in the backwards data path, the sender MUST ensure that the data sending in the backwards data path, the sender MUST ensure that
conforms to the backwards direction traffic parameters. Since the the data conforms to the backwards direction traffic parameters.
traffic parameters are set by the VC initiator, it is quite likely Since the traffic parameters are set by the VC initiator, it is
that no resources will be requested for traffic originating at the quite likely that no resources will be requested for traffic
called party. It should be noted that the backwards data path is originating at the called party. It should be noted that the
not available with point-to-multipoint VCs. backwards data path is not 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 and there is therefore no way to know when a VC is connectionless and there is therefore no way to know when a VC is
no longer needed. Since RSVP provides explicit mechanisms no longer needed. Since RSVP provides explicit mechanisms
(messages and timeouts) to determine when an associated data VC is (messages and timeouts) to determine when an associated data VC is
no longer needed, the traditional VC timeout mechanisms is not no longer needed, the traditional VC timeout mechanisms are not
needed. Additionally, under normal operations RSVP implementations needed. Additionally, under normal operations RSVP implementations
expect to be able to allocate resources and have those resource expect to be able to allocate resources and have those resources
remain allocated until released at the direction of RSVP. remain allocated until released at the direction of RSVP.
Therefore, data VCs set up to support RSVP controlled flows should Therefore, data VCs set up to support RSVP controlled flows should
only be released at the direction of RSVP. Such VCs must not be only be released at the direction of RSVP. Such VCs must not be
timed out due to inactivity by either the VC initiator or the VC timed out due to inactivity by either the VC initiator or the VC
receiver. This conflicts with VCs timing out as described in RFC receiver. This conflicts with VCs timing out as described in RFC
1755[10], section 3.4 on VC Teardown. RFC 1755 recommends tearing 1755[11], section 3.4 on VC Teardown. RFC 1755 recommends tearing
down a VC that is inactive for a certain length of time. Twenty down a VC that is inactive for a certain length of time. Twenty
minutes is recommended. This timeout is typically implemented at minutes is recommended. This timeout is typically implemented at
both the VC initiator and the VC receiver. Although, section 3.1 both the VC initiator and the VC receiver. Although, section 3.1
of the update to RFC 1755[11] states that inactivity timers must of the update to RFC 1755[12] states that inactivity 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 mentioned in [10] MUST be set to "infinite" for VCs timer mentioned in [11] MUST be set to "infinite" for VCs
initiated at the request of RSVP. Setting the inactivity timer initiated at the request of RSVP. Setting the inactivity timer
value at the VC initiator should not be problematic since the value at the VC initiator should not be problematic since the
proper value can be relayed internally at the originator. Setting proper value can be relayed internally at the originator. Setting
the inactivity timer at the VC receiver is more difficult, and the inactivity timer at the VC receiver is more difficult, and
would require some mechanism to signal that an incoming VC was would require some mechanism to signal that an incoming VC was
RSVP initiated. To avoid this complexity and to conform to [11], RSVP initiated. To avoid this complexity and to conform to [12],
RSVP over ATM implementations MUST not use an inactivity timer to RSVP over ATM implementations 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 [8], there is a mismatch in the service provided by As stated in [9], there is a mismatch in the service provided by
RSVP and that provided by ATM UNI3.x and 4.0. RSVP allows RSVP and that provided by ATM UNI3.x and 4.0. RSVP allows
modifications to QoS parameters at any time while ATM does not modifications to QoS parameters at any time while ATM does not
support any modifications to QoS parameters post VC setup. See support any modifications to QoS parameters post VC setup. See
[8] for more detail. [9] for more detail.
The method for supporting changes in RSVP reservations is to The method for supporting changes in RSVP reservations is to
attempt to replace an existing VC with a new appropriately sized attempt to replace an existing VC with a new appropriately sized
VC. During setup of the replacement VC, the old VC MUST be left in VC. During setup of the replacement VC, the old VC MUST be left in
place unmodified. The old VC is left unmodified to minimize place unmodified. The old VC is left unmodified to minimize
interruption of QoS data delivery. Once the replacement VC is interruption of QoS data delivery. Once the replacement VC is
established, data transmission is shifted to the new VC, and only established, data transmission is shifted to the new VC, and only
then is the old VC closed. then is the old VC 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 request MUST be treated as if the modification was successful. the request MUST be treated as if the modification was successful.
While leaving the larger allocation in place is suboptimal, it While leaving the larger allocation in place is suboptimal, it
maximizes delivery of service to the user. The behavior is also maximizes delivery of service to the user. The behavior is also
required in order to conform to RSVP error handling as defined in required in order to conform to RSVP error handling as defined in
sections 2.5, 3.1.8 and 3.11.2 of [7]. Implementations SHOULD sections 2.5, 3.1.8 and 3.11.2 of [8]. Implementations SHOULD
retry replacing a too large VC after some appropriate elapsed retry replacing a 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 one time per reservation. If the (RSVP) requested QoS is at one time per reservation. If the (RSVP) requested QoS is
changed while the first replacement VC is still being setup, then changed while the first replacement VC is still being setup, then
the replacement VC SHOULD BE released and the whole VC replacement the 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 [8]. 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 support LLC encapsulation per RFC 1483[9] on such QoS VCs. to 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 [10] B-LLI negotiation procedures defined in ATM Signalling, see [11]
for details. When a QoS VC is only being used to carry IP for details. When a QoS VC is only being used to carry IP
packets, implementations SHOULD negotiate VC based multiplexing to packets, implementations SHOULD negotiate VC based multiplexing to
avoid incurring the overhead of the LLC header. avoid 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
issues, 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 are covered in detail in [8]. In summary, heterogeneity sessions are covered in detail in [9]. In summary, heterogeneity
occurs when receivers request different levels of QoS within a occurs when receivers request different levels of QoS within a
single session, and also when some receivers do not request any single session, and also when some receivers do not request any
QoS. Both types of heterogeneity are shown in figure 2. QoS. Both types of heterogeneity are shown in figure 2.
+----+ +----+
+------> | R1 | +------> | R1 |
| +----+ | +----+
| |
| +----+ | +----+
+-----+ -----+ +--> | R2 | +-----+ -----+ +--> | R2 |
skipping to change at page 9, line 4 skipping to change at page 9, line 4
: +----+ : +----+
/\ : /\ :
|| : +----+ || : +----+
|| +......> | R4 | || +......> | R4 |
|| +----+ || +----+
Single Single
IP Mulicast IP Mulicast
Group Group
Figure 2: Types of Multicast Receivers Figure 2: Types of Multicast Receivers
[8] 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 is used by an implementation, implementations MUST NOT models is used by an implementation, implementations MUST NOT
normally send more than one copy of a particular data packet to a normally send more than one copy of a particular data packet to a
particular next-hop (ATM end-point). Some transient duplicate particular next-hop (ATM end-point). Some transient duplicate
transmission is acceptable, but only during VC setup and transmission is 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
skipping to change at page 9, line 35 skipping to change at page 9, line 35
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 and heterogeneity need to be addressed. A key issue is QoS and heterogeneity need to be addressed. A key issue is
whether to first add the new next-hop or to change to the new QoS. whether to first add the new next-hop or to change to the new QoS.
This is a fairly straight forward special case. Since the older, This is a fairly straight forward special case. Since the older,
smaller reservation does not support the new next-hop, the dynamic smaller reservation does not support the new next-hop, the dynamic
QoS process SHOULD be initiated first. Since the new QoS is only QoS process SHOULD be initiated first. Since the new QoS is only
needed by the new next-hop, it SHOULD be the first end-point of needed by the new next-hop, it SHOULD be the first end-point of
the new VC. This way signalling is minimized when the setup to the new VC. This way signaling is minimized when the setup to the
the new next-hop fails. new next-hop 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 in an IP multicast group. The ATM end-points will participating in an IP multicast group. The ATM end-points will
be IP multicast receivers and/or next-hops. Both QoS and best be IP multicast receivers and/or next-hops. Both QoS and best
effort end-points must be identified. RSVP next-hop information effort end-points must be identified. RSVP next-hop information
will usually provide QoS end-points, but not best effort end- will usually provide QoS end-points, but not best effort end-
points. points.
skipping to change at page 11, line 42 skipping to change at page 11, line 42
not global, break bit(s). Use of the service-specific break bit not global, break bit(s). Use of the service-specific break bit
tells the receiver(s) that RSVP and Integrated Services are tells the receiver(s) that RSVP and Integrated Services are
supported by the router but that the service cannot be delivered supported by the router but that the service cannot be delivered
over the ATM network for the specific request. over the ATM network 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 desire proper RSVP over ATM operation MUST appropriately that desire proper RSVP over ATM operation MUST appropriately
configure their network to support mesh mode distribution for configure their network to support mesh mode distribution for
multicast groups that will be used in RSVP sessions. For LANE1.0 multicast groups that will be used in RSVP sessions. For LANE1.0
networks the only multicast distribution option is over the BUS, networks the only multicast distribution option is over the LANE
which means that the break bit MUST always be set. For LANE2.0 BUS [Note 1] , which means that the break bit MUST always be set.
[3] there are provisions that allow for non-BUS solutions with For LANE2.0 [3] there are provisions that allow for non-BUS
which it may be possible to ensure proper QoS delivery. solutions with which it may be possible to ensure proper QoS
delivery.
_________________________
[Note 1] Broadcast and Unknown Server
3.4 Receiver Transitions 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 some receivers have been added to a QoS VC and some have not. when some receivers have been added to a QoS VC and some have not.
During such transition times it is possible to start sending data 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 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 and the old VC, then data will be delivered with proper QoS to
some receivers and with the old QoS to all receivers. some receivers and with the old QoS to all receivers.
Additionally, the QoS receivers would get duplicate data. If data Additionally, the QoS receivers would get duplicate data. If data
is sent just on the new QoS VC, the receivers that have not yet is sent just on the new QoS VC, the receivers that have not yet
skipping to change at page 12, line 37 skipping to change at page 12, line 42
must be both added to the QoS VC and dropped from a best effort 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 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 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 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 avoid loss of data, the add MUST be completed first and then
followed by the drop. This behavior requires receivers to be followed by the drop. This behavior requires receivers to be
prepared to receive some duplicate packets at times of QoS setup. prepared to receive some duplicate packets at times of QoS setup.
4. Security 4. Security
The same considerations stated in [7] and [10] 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.
skipping to change at page 13, line 4 skipping to change at page 13, line 6
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
6905 Rockledge Drive 1595 Spring Hill Road
Suite 800 5th Floor
Bethesda, MD 20817 Vienna, VA 22182
Phone: +1 301 571 2534 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", Internet
Draft, November 1997. Draft, January 1998.
[6] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and [6] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and
Guaranteed-Service with ATM," Internet Draft, July 1997. Guaranteed-Service with ATM," Internet Draft, November 1997.
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997.
[8] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification," RFC 2205, September 1997. Specification," RFC 2205, September 1997.
[8] 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, "Issues for Integrated Services and RSVP over ATM," Krawczyk, J, "Issues for Integrated Services and RSVP over ATM,"
Internet Draft, July 1997. Internet Draft, Novemver 1997.
[9] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer [10] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
5," RFC 1483. Layer 5," RFC 1483.
[10] 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. Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755.
[11] 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" Internet Draft, May 1997.
 End of changes. 48 change blocks. 
66 lines changed or deleted 78 lines changed or added

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