Internet Engineering Task Force D. Williams
INTERNET DRAFT R. Guerin
D. Kandlur
17 September 1996
ATM Virtual Circuit Identification Support for an RSVP-based Service
draft-williams-issll-vcuse-00.txt
Status of This Memo
This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the internet-drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
In this document we present a specification for associating RSVP
flows with Virtual Connections on an ATM network. The text in this
document is meant as an addendum to the text in Subsection 3.2
``Sending RSVP Messages'' of the RSVP specification [Bzb+96]. This
document specifies a usage of the Logical Interface Handle (LIH) in
the RSVP_HOP Class Object when either a host or a router is attached
to an ATM network. This document also specifies ATM UNI [For94]
signaling semantics for associating a switched ATM connection with
RSVP flows. These ATM UNI semantics use the Broadband High Layer
Information (BHLI) Information Element.
Guerin, Kandlur, Williams Expires 22 March 1997 [Page i]
Internet Draft VC Identification 17 September 1996
1. Motivation
The purpose for this document is to propose a standard method for
hosts and routers using the RSVP Protocol [Bzb+96] over an ATM
network to associate RSVP flows with a unique Virtual Connection
(permanent or switched). Specifically this document presents a
specification that is to be used as addendum text to Subsection
3.2 ``Sending RSVP Messages'' of the RSVP Specification. This
document does not present any new RSVP Objects, or in fact, any
particular change to the basic framework of either RSVP or ATM
UNI signaling, rather, this document presents a usage of existing
protocol mechanisms.
The motivation for this work is to allow hosts and routers to
efficiently and consistently use the underlying ATM link layer
technology (i.e. manage VCs). While there are several alternatives
to mapping RSVP sessions to a data-link connection, this document
specifies a "one connection per session" model, in which a new
connection is created for each RSVP session. This model has the
following advantages:
- It exploits the traffic control and scheduling capabilities of the
data link, which are typically supported with hardware mechanisms.
- It reduces the network level processing load by removing the need
for multiplexing of RSVP sessions onto a connection.
The advantages of this model can be extended further when the
receiving end-point of the connection is made aware of the
association between the RSVP session and the data-link connection.
For example, when the receiver is a network device, the data-link
connection can be used as a mechanism for pre-sorting packets to
their network level session. This can assist the network device in
performing appropriate forwarding and scheduling actions at very high
speeds. Similarly, when the receiver is an end-station, the data
link connection can be exploited to perform an early de-multiplexing
of arriving packets to their appropriate application endpoint. This
early de-multiplexing has been shown to reduce latency and processing
overheads within the end-station, thereby improving the performance
of multimedia applications. Moreover, when the consuming application
endpoint is a device within the end-station (such as a graphics
display adapter) the data link connection can be used to direct
packets to the device.
Another reason for keeping track of RSVP-related connections at the
data link layer is related to connection management. The IP over
ATM signaling standard (RFC 1755) specifies that end systems must
support the use of inactivity timers for connections. However, this
Guerin, Kandlur, Williams Expires 22 March 1997 [Page 1]
Internet Draft VC Identification 17 September 1996
provision should not apply to connections that were created for RSVP.
The presence of RSVP signaling messages is sufficient to indicate
that the application desires a reservation, even when there is no
data traffic on the session. Since these data link connections are
established and maintained at the behest of RSVP, it is logical to
leverage RSVP to convey data link connection information between
the endpoints. Moreover, RSVP messages contain all the elements
necessary to identify the data flows that are carried on the
connection.
The advantages of data link connections for supporting QoS have been
recognized in many different forms, and there have been proposals put
forth to define protocols to exploit them. Among these proposals are
SINP and the Ipsilon flow management protocol. Our approach differs
from these efforts in that it is defined as a usage of existing
protocols, namely RSVP and ATM UNI Signaling. We feel this to be of
importance as while the functionality we seek to provide is useful
in many different settings, its support should be through existing
signaling protocols rather than by developing a new protocol for that
purpose.
2. Specification
The following text is meant to be an addendum to the end of
Subsection 3.2 ``Sending RSVP Messages'' in the RSVP Specification.
When operating over and ATM link-layer, it can be desirable to
associate each RSVP session with a separate Virtual Connection
(either Permanent or Switched). ATM attached RSVP capable hosts and
routers can support this capability in the following manner:
1. When a node N forwards a PATH message over an ATM network
connection, this PATH message is sent on a default IP/Control
Virtual Connection. The message includes an RSVP_HOP object
class with one of the following codings for the LIH:
- In a Permanent Virtual Connection environment, the LIH
contains the VPI:VCI of the ATM Virtual Connection as
follows:
+--------------+--------------+--------------+--------------+
| NULL VPI VCI VCI |
+--------------+--------------+--------------+--------------+
- In a Switched Virtual Connection environment, the Logical
Interface Handle contains a Flow ID Handle as follows:
Guerin, Kandlur, Williams Expires 22 March 1997 [Page 2]
Internet Draft VC Identification 17 September 1996
+--------------+--------------+--------------+--------------+
| Flow ID Handle (32-bit integer) |
+--------------+--------------+--------------+--------------+
2. Both N and the next hop node N' store the LIH in their Path State
Tables.
3. When N' sends a RESV message to N, it includes the LIH value from
the Path State Table in an RSVP_HOP object.
4. When a RESV message(s) arrives at N for this session, the LIH
information from the Path State Table is used to identify the
Virtual Connection for this session's data packets. In the case
of PVCs, this association is immediate, in the case of SVCs, the
VPI:VCI is identified after node N performs the ATM UNI signaling
described in Step 5 below.
5. In the case of a Switched Virtual Connection, when N receives the
RESV message it performs ATM UNI signaling [For94] to establish
the connection for this reservation. In the UNI SETUP Message, a
Broadband High Layer Information Information Element is included
with the 32-bit Flow ID Handle for the session that will be using
this Virtual Connection (i.e the same Flow ID that was sent in
the original PATH message for this session). When N' receives
the ATM UNI SETUP message, it extracts the Flow ID Handle from
the BHLI field and uses it to associate the particular RSVP
session with the VPI:VCI being setup. The BHLI Information
Element is coded as follows:
Bits
8 7 6 5 4 3 2 1 Octets
+----------------------------------------------+
| BHLI IE Identifier |
| 0 1 0 1 1 1 0 1 | 1
+----------------------------------------------+
| ext | Coding | Instruction Field |
| 1 | 0 0 | 0 0 0 0 0 | 2
+----------------------------------------------+
| Length |
| 0 0 0 0 0 0 0 0 | 3
+----------------------------------------------+
| Length (cont) |
| 0 0 0 0 0 1 0 0 | 4
+----------------------------------------------+
| ext | High Layer Information Type |
| 1 | 0 0 0 0 0 0 1 | 5
+----------------------------------------------+
| Flow ID Handle (bits 1-8) | 6
Guerin, Kandlur, Williams Expires 22 March 1997 [Page 3]
Internet Draft VC Identification 17 September 1996
+----------------------------------------------+
| Flow ID Handle (bits 9-16) | 7
+----------------------------------------------+
| Flow ID Handle (bits 17-24) | 8
+----------------------------------------------+
| Flow ID Handle (bits 25-32) | 9
+----------------------------------------------+
3. Example
The figure below shows a simple example network. In which two IP
hosts are connected to each other through an ATM switch and a router.
|------| |------| |------| | |------|
| H1 |-----| S1 |-----| R1 |--|--| H2 |
|------| |------| |------| | |------|
H1 is an RSVP sender and H2 is an RSVP receiver; assume two PVCs
between H1 and R1 and R1 and H2 are connected by an Ethernet.
Using the mechanisms outlined in this document, H1 sends an RSVP
PATH message over one of the two PVCs (referred to as the default
VC). This PATH message flows as normal through the network to
the destination, in this case H2 is the destination. The PATH
message contains the VPI:VCI of the second PVC (referred to as the
reserved data PVC) in the LIH field of the RSVP_HOP Object as shown
above. When R1 receives the PATH message, it creates a Path State
Table entry that includes the VPI:VCI that is located in the LIH
field. H2 determines that it would like to setup a Reservation for
this particular session, that is, it sends a RESV message. When
R1 receives this message, along with normal RSVP processing, it
associates the PVC connection that corresponds to the VPI:VCI that
was stored in the Path State Table with this session. R1 then sends
the RESV message to H1 with the LIH again set to its VPI:VCI for the
reserved data PVC. When H1 receives the RESV message it sets up its
resources and sends the session's data on the reserved data PVC.
In the case of an SVC connection, the flow is the same as the PVC
case, with the exception that H1 includes a 32-bit Flow ID handle
in the LIH field instead of a VPI:VCI (note that in the SVC case,
the reserved data SVC is not established until the sender receives
the RESV message), R1 stores the Flow ID handle in the Path State
Table. When the RESV message arrives at H1, it requests a reserved
data VC to R1 using UNI signaling. The UNI signaling includes the
Flow ID handle in the BHLI as shown above. When R1 receives the call
request, it is responsible for associating this particular VC with
the RSVP session that is identified in the Path State Table (i.e.
Guerin, Kandlur, Williams Expires 22 March 1997 [Page 4]
Internet Draft VC Identification 17 September 1996
comparing Flow ID handles). When the ATM SVC is fully established,
the reserved data flows over this SVC.
4. References
[Bzb+96] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", Internet Draft, draft-ietf-rsvp-spec-12.txt, May
1996.
[For94] ATM Forum, "ATM User-Network Interface Specifications,
Version 3.1", September 1994.
[For95] ATM Forum, "ATM User-Network Interface Specifications,
Version 4.0", ATM Forum/94-1018.
5. Authors' Address
Roch Guerin
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Phone: +1-914-784-7038
E-mail: guerin@watson.ibm.com
Dilip Kandlur
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Phone: +1-914-784-7722
E-mail: kandlur@watson.ibm.com
Doug Williams
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Phone: +1-914-784-5047
Guerin, Kandlur, Williams Expires 22 March 1997 [Page 5]
Internet Draft VC Identification 17 September 1996
E-mail: dougw@watson.ibm.com
Guerin, Kandlur, Williams Expires 22 March 1997 [Page 6]