existing RSVP mechanisms will support asymmetric short-cuts. The
short-cut model of VC establishment still poses several issues when
running with RSVP. The major issues are dealing with established
best-effort short-cuts, when to establish short-cuts, and QoS only
short-cuts. These issues will need to be addressed by RSVP
implementations.
The key issue to be addressed by any RSVP over ATM solution is when
to establish a short-cut for a QoS data flow. The default behavior is
to simply follow best-effort traffic. When a short-cut has been
established for best-effort traffic to a destination or next-hop,
that same end-point should be used when setting up RSVP triggered VCs
for QoS traffic to the same destination or next-hop. This will happen
naturally when PATH messages are forwarded over the best-effort
short-cut. Note that in this approach when best-effort short-cuts
are never established, RSVP triggered QoS short-cuts will also never
be established. More study is expected in this area.
4.2.9 VC Teardown
RSVP can identify from either explicit messages or timeouts when a
data VC is no longer needed. Therefore, data VCs set up to support
RSVP controlled flows should only be released at the direction of
RSVP. VCs must not be timed out due to inactivity by either the VC
initiator or the VC receiver. This conflicts with VCs timing out as
described in RFC1755 [11], section 3.4 on VC Teardown. RFC1755
recommends tearing down a VC that is inactive for a certain length of
time. Twenty minutes is recommended. This timeout is typically
implemented at both the VC initiator and the VC receiver. Although,
section 3.1 of the update to RFC1755 [11] states that inactivity
timers must not be used at the VC receiver.
When this timeout occurs for an RSVP initiated VC, a valid VC with
QoS will be torn down unexpectedly. While this behavior is
acceptable for best-effort traffic, it is important that RSVP
controlled VCs not be torn down. If there is no choice about the VC
being torn down, the RSVP daemon must be notified, so a reservation
failure message can be sent.
For VCs initiated at the request of RSVP, the configurable inactivity
timer mentioned in [11] must be set to "infinite". Setting the
inactivity timer value at the VC initiator should not be problematic
since the proper value can be relayed internally at the originator.
Setting the inactivity timer at the VC receiver is more difficult,
and would require some mechanism to signal that an incoming VC was
RSVP initiated. To avoid this complexity and to conform to [11]
implementations must not use an inactivity timer to clear received
connections.
4.3 RSVP Control Management
One last important issue is providing a data path for the RSVP
messages themselves. There are two main types of messages in RSVP,
PATH and RESV. PATH messages are sent to unicast or multicast
addresses, while RESV messages are sent only to unicast addresses.
Other RSVP messages are handled similar to either PATH or RESV,
although this might be more complicated for RERR messages. So ATM
VCs used for RSVP signalling messages need to provide both unicast
and multicast functionality. There are several different approaches
for how to assign VCs to use for RSVP signalling messages.
The main approaches are:
- use same VC as data
- single VC per session
- single point-to-multipoint VC multiplexed among sessions
- multiple point-to-point VCs multiplexed among sessions
There are several different issues that affect the choice of how to
assign VCs for RSVP signalling. One issue is the number of additional
VCs needed for RSVP signalling. Related to this issue is the degree
of multiplexing on the RSVP VCs. In general more multiplexing means
fewer VCs. An additional issue is the latency in dynamically setting
up new RSVP signalling VCs. A final issue is complexity of
implementation. The remainder of this section discusses the issues
and tradeoffs among these different approaches and suggests
guidelines for when to use which alternative.
4.3.1 Mixed data and control traffic
In this scheme RSVP signalling messages are sent on the same VCs as
is the data traffic. The main advantage of this scheme is that no
additional VCs are needed beyond what is needed for the data traffic.
An additional advantage is that there is no ATM signalling latency
for PATH messages (which follow the same routing as the data
messages). However there can be a major problem when data traffic on
a VC is nonconforming. With nonconforming traffic, RSVP signalling
messages may be dropped. While RSVP is resilient to a moderate level
of dropped messages, excessive drops would lead to repeated tearing
down and re-establishing of QoS VCs, a very undesirable behavior for
ATM. Due to these problems, this may not be a good choice for
providing RSVP signalling messages, even though the number of VCs
needed for this scheme is minimized. One variation of this scheme is
to use the best effort data path for signalling traffic. In this
scheme, there is no issue with nonconforming traffic, but there is an
issue with congestion in the ATM network. RSVP provides some
resiliency to message loss due to congestion, but RSVP control
messages should be offered a preferred class of service. A related
variation of this scheme that is hopeful but requires further study
is to have a packet scheduling algorithm (before entering the ATM
network) that gives priority to the RSVP signalling traffic. This can
be difficult to do at the IP layer.
4.3.1.1 Single RSVP VC per RSVP Reservation
In this scheme, there is a parallel RSVP signalling VC for each RSVP
reservation. This scheme results in twice the number of VCs, but
means that RSVP signalling messages have the advantage of a separate
VC. This separate VC means that RSVP signalling messages have their
own traffic contract and compliant signalling messages are not
subject to dropping due to other noncompliant traffic (such as can
happen with the scheme in section 4.3.1). The advantage of this
scheme is its simplicity - whenever a data VC is created, a separate
RSVP signalling VC is created. The disadvantage of the extra VC is
that extra ATM signalling needs to be done. Additionally, this scheme
requires twice the minimum number of VCs and also additional latency,
but is quite simple.
4.3.1.2 Multiplexed point-to-multipoint RSVP VCs
In this scheme, there is a single point-to-multipoint RSVP signalling
VC for each unique ingress router and unique set of egress routers.
This scheme allows multiplexing of RSVP signalling traffic that
shares the same ingress router and the same egress routers. This can
save on the number of VCs, by multiplexing, but there are problems
when the destinations of the multiplexed point-to-multipoint VCs are
changing. Several alternatives exist in these cases, that have
applicability in different situations. First, when the egress routers
change, the ingress router can check if it already has a point-to-
multipoint RSVP signalling VC for the new list of egress routers. If
the RSVP signalling VC already exists, then the RSVP signalling
traffic can be switched to this existing VC. If no such VC exists,
one approach would be to create a new VC with the new list of egress
routers. Other approaches include modifying the existing VC to add an
egress router or using a separate new VC for the new egress routers.
When a destination drops out of a group, an alternative would be to
keep sending to the existing VC even though some traffic is wasted.
The number of VCs used in this scheme is a function of traffic
patterns across the ATM network, but is always less than the number
used with the Single RSVP VC per data VC. In addition, existing best
effort data VCs could be used for RSVP signalling. Reusing best
effort VCs saves on the number of VCs at the cost of higher
probability of RSVP signalling packet loss. One possible place where
this scheme will work well is in the core of the network where there
is the most opportunity to take advantage of the savings due to
multiplexing. The exact savings depend on the patterns of traffic
and the topology of the ATM network.
4.3.1.3 Multiplexed point-to-point RSVP VCs
In this scheme, multiple point-to-point RSVP signalling VCs are used
for a single point-to-multipoint data VC. This scheme allows
multiplexing of RSVP signalling traffic but requires the same traffic
to be sent on each of several VCs. This scheme is quite flexible and
allows a large amount of multiplexing.
Since point-to-point VCs can set up a reverse channel at the same
time as setting up the forward channel, this scheme could save
substantially on signalling cost. In addition, signalling traffic
could share existing best effort VCs. Sharing existing best effort
VCs reduces the total number of VCs needed, but might cause
signalling traffic drops if there is congestion in the ATM network.
This point-to-point scheme would work well in the core of the network
where there is much opportunity for multiplexing. Also in the core of
the network, RSVP VCs can stay permanently established either as
Permanent Virtual Circuits (PVCs) or as long lived Switched Virtual
Circuits (SVCs). The number of VCs in this scheme will depend on
traffic patterns, but in the core of a network would be approximately
n(n-1)/2 where n is the number of IP nodes in the network. In the
core of the network, this will typically be small compared to the
total number of VCs.
4.3.2 QoS for RSVP VCs
There is an issue of what QoS, if any, to assign to the RSVP
signalling VCs. For other RSVP VC schemes, a QoS (possibly best
effort) will be needed. What QoS to use partially depends on the
expected level of multiplexing that is being done on the VCs, and the
expected reliability of best effort VCs. Since RSVP signalling is
infrequent (typically every 30 seconds), only a relatively small QoS
should be needed. This is important since using a larger QoS risks
the VC setup being rejected for lack of resources. Falling back to
best effort when a QoS call is rejected is possible, but if the ATM
net is congested, there will likely be problems with RSVP packet loss
on the best effort VC also. Additional experimentation is needed in
this area.
5. Encapsulation
Since RSVP is a signalling protocol used to control flows of IP data
packets, encapsulation for both RSVP packets and associated IP data
packets must be defined. The methods for transmitting IP packets over
ATM (Classical IP over ATM[10], LANE[17], and MPOA[18]) are all based
on the encapsulations defined in RFC1483 [19]. RFC1483 specifies two
encapsulations, LLC Encapsulation and VC-based multiplexing. The
former allows multiple protocols to be encapsulated over the same VC
and the latter requires different VCs for different protocols.
For the purposes of RSVP over ATM, any encapsulation can be used as
long as the VCs are managed in accordance to the methods outlined in
Section 4. Obviously, running multiple protocol data streams over
the same VC with LLC encapsulation can cause the same problems as
running multiple flows over the same VC.
While none of the transmission methods directly address the issue of
QoS, RFC1755 [11] does suggest some common values for VC setup for
best-effort traffic. [14] discusses the relationship of the RFC1755
setup parameters and those needed to support IntServ flows in greater
detail.
6. Security Considerations
The same considerations stated in [1] and [11] apply to this
document. There are no additional security issues raised in this
document.
7. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC2209, September 1997.
[2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
of Realtime Services in an IP-ATM Network Architecture", RFC
1821, August 1995.
[3] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework
Document", RFC1932, April 1996.
[4] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC2332,
April 1998.
[5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", RFC2022, November 1996.
[6] Shenker, S., and C. Partridge, "Specification of Guaranteed
Quality of Service", RFC2212, September 1997.
[7] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC2211, September 1997.
[8] ATM Forum. ATM User-Network Interface Specification Version 3.0.
Prentice Hall, September 1993.
[9] ATM Forum. ATM User Network Interface (UNI) Specification Version
3.1. Prentice Hall, June 1995.
[10] Laubach, M., "Classical IP and ARP over ATM", RFC2225, April
1998.
[11] Perez, M., Mankin, A., Hoffman, E., Grossman, G., and A. Malis,
"ATM Signalling Support for IP over ATM", RFC1755, February
1995.
[12] Herzog, S., "RSVP Extensions for Policy Control", Work in
Progress.
[13] Herzog, S., "Local Policy Modules (LPM): Policy Control for
RSVP", Work in Progress.
[14] Borden, M., and M. Garrett, "Interoperation of Controlled-Load
and Guaranteed Service with ATM", RFC2381, August 1998.
[15] Berger, L., "RSVP over ATM Implementation Requirements", RFC
2380, August 1998.
[16] Berger, L., "RSVP over ATM Implementation Guidelines", RFC2379,
August 1998.
[17] ATM Forum Technical Committee. LAN Emulation over ATM, Version
1.0 Specification, af-lane-0021.000, January 1995.
[18] ATM Forum Technical Committee. Baseline Text for MPOA, af-95-
0824r9, September 1996.
[19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC1483, July 1993.
[20] ATM Forum Technical Committee. LAN Emulation over ATM Version 2
- LUNI Specification, December 1996.
[21] ATM Forum Technical Committee. Traffic Management Specification
v4.0, af-tm-0056.000, April 1996.
[22] Callon, R., et al., "A Framework for Multiprotocol Label
Switching, Work in Progress.
[23] Rajagopalan, B., Nair, R., Sandick, H., and E. Crawley, "A
Framework for QoS-based Routing in the Internet", RFC2386,
August 1998.
[24] ITU-T. Digital Subscriber Signaling System No. 2-Connection
modification: Peak cell rate modification by the connection
owner, ITU-T Recommendation Q.2963.1, July 1996.
[25] ITU-T. Digital Subscriber Signaling System No. 2-Connection
characteristics negotiation during call/connection establishment
phase, ITU-T Recommendation Q.2962, July 1996.
[26] ATM Forum Technical Committee. Private Network-Network Interface
Specification v1.0 (PNNI), March 1996.
8. Authors' Addresses
Eric S. Crawley
Argon Networks
25 Porter Road
Littleton, Ma 01460
Phone: +1 978 486-0665
EMail: esc@argon.com
Lou Berger
FORE Systems
6905 Rockledge Drive
Suite 800
Bethesda, MD 20817
Phone: +1 301 571-2534
EMail: lberger@fore.com
Steven Berson
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: +1 310 822-1511
EMail: berson@isi.edu
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Phone: +1 805 681-0115
EMail: fred@cisco.com
Marty Borden
Bay Networks
125 Nagog Park
Acton, MA 01720
Phone: +1 978 266-1011
EMail: mborden@baynetworks.com
John J. Krawczyk
ArrowPoint Communications
235 Littleton Road
Westford, Massachusetts 01886
Phone: +1 978 692-5875
EMail: jj@arrowpoint.com
9. 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.