[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]