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

Versions: 00                                                            
Internet Engineering Task Force                                R. Guerin
INTERNET DRAFT                                                D. Kandlur
                                                             D. Williams
                                                                     IBM
                                                       17 September 1996


          Extensions to the MARS model for Integrated Services
                  draft-kandlur-issll-rsvp-mars-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

   This memo describes an extension to the IP multicast architecture
   now being developed by the IP over ATM working group, also known as
   MARS (Multicast Address Resolution Server).  This extension expands
   the responsibilities of the Multicast Server (MCS) to adapt it to
   the Integrated Services Internet Architecture and related signaling
   protocols such as RSVP.















Guerin,Kandlur,Williams          Expires 22 March 1997          [Page i]


Internet Draft         MARS Extension for RSVP         17 September 1996


1. Introduction

   The MARS document [Arm96] describes a mechanism for handling IP
   multicast over ATM. Clusters of endpoints, currently defined by
   IP subnetwork boundaries, share a MARS and use it to track and
   disseminate information on membership in multicast groups.  This
   allows endpoints to establish VCCs and to transmit to their multicast
   group over these VCCs.  Multicasting is supported using either meshes
   of VCs or ATM-level multicast servers (MCSs).  The choice is made on
   a per-group basis and is transparent to the endpoints.


1.1. The Problem

   In a IP/ATM subnetwork using the MARS protocol for IP multicast
   address resolution, an Multicast Server (MCS) may be used to forward
   IP multicast datagrams.  This Multicast Server is transparent to the
   end stations and its operation is further defined in [RT96].  An end
   station (the MARS client) requests the MARS server for resolution
   of IP multicast addresses and receives a list of ATM addresses.  It
   then creates a virtual connection to members of this list, which
   may consist of the MCS or all of the local members of the multicast
   group, to deliver packets addressed to this multicast address.
   Currently, this connection is set up with best-effort service class.
   The purpose of this document is to investigate the operation of the
   MARS/MCS in the presence of IP Integrated Services and RSVP.

   We consider the ``classical'' framework for handling RSVP and
   Integrated Services over ATM described in [Ber96b, Ber96a].  In
   this model, an RSVP ``flow'' is mapped onto an ATM VCC with QoS
   attributes.  The guidelines for this mapping are described in
   [BG96].  Specifically, for multicast flows, when a source receives
   a RESV message for a given multicast session, it is responsible for
   creating a virtual connection with the appropriate quality-of-service
   specification to match the service requested in the RESV message.
   However, when an MCS is used, this virtual connection only extends
   from the source to the MCS (see Fig. 1).  The forwarding path
   from the MCS to the destination end-stations will continue to be
   best-effort since the MCS has no knowledge of the QoS information,
   and the delivery mechanisms currently defined for the MCS only
   specify UBR VCCs.  Moreover, since the MCS does not process RSVP
   messages, the destination stations would not be able to detect this
   breach of service.








Guerin,Kandlur,Williams          Expires 22 March 1997          [Page 1]


Internet Draft         MARS Extension for RSVP         17 September 1996

























                      Figure 1: Data flow with MCS



2. Possible Solutions

   One solution is to place IP multicast group information in the ATM
   setup message when the sender creates an ATM VC (to the MCS). The
   receiver, in this case the MCS, can then use this information to
   create a QoS VC towards the receivers of the multicast group.  It
   would derive the QoS parameters from the QoS and traffic information
   elements received in the ATM SETUP message, and IP multicast group
   information from the information elements reserved for protocol
   information.  Unfortunately, this approach has several deficiencies:

    1. the MCS does not have access to RESV messages so it is not able
       to distinguish between receivers which have made reservations
       from those that have not made any reservation

    2. the MCS would require additional information to handle shared
       reservations

   A second approach would be to apply the SBM mechanism [RY96] to
   ATM. In this approach, the SBM would be co-located with the MCS and




Guerin,Kandlur,Williams          Expires 22 March 1997          [Page 2]


Internet Draft         MARS Extension for RSVP         17 September 1996


   receivers would send RESV messages to the SBM/MCS. However, it has
   some disadvantages in the ATM context:

    1. unlike the Ethernet environment, the SBM/MCS is used only for
       reservations for multicast sessions.  This requires special
       mechanism for differentiating between unicast and multicast
       sessions.

    2. it requires either additional configuration of end-stations (for
       the SBM address) or a cheap multicast mechanism.

   A third, and we believe more effective, solution would be to make
   the MCS participate in RSVP signaling by processing IP/RSVP packets.
   The MCS would intercept PATH messages and change the RSVP_PHOP field
   to the address of the MCS. This change would ensure that the RSVP
   agents on the receivers would direct their RESV responses to the
   MCS. The MCS would process these RESV responses, perform merging as
   applicable, and then forward them to the appropriate previous hops.
   The processing done by the MCS is similar to that performed by an
   RSVP router, or a subnetwork bandwidth manager (SBM). This approach
   differs from the SBM approach in that the MCS also processes RSVP
   PATH messages.  There are several advantages to this approach:

    1. it is transparent to end-stations

    2. it does not require any protocol modifications to RSVP

    3. it places responsibility on the MCS, which is part of the data
       forwarding path and, hence, necessarily involved with the setup
       of QoS connections.

    4. it requires no additional configuration to end-stations or a
       multicast mechanism for discovery of the MCS.


3. Summary

   This draft described several approaches to handling IP Integrated
   Services flows in the presence of an MCS. From the discussion, it is
   apparent that the preferred solution is one in which the MCS is RSVP
   aware and participates in the signaling process in a manner that is
   transparent to end stations.  Further specification of this approach
   will be pursued based on the recommendation of the working group.








Guerin,Kandlur,Williams          Expires 22 March 1997          [Page 3]


Internet Draft         MARS Extension for RSVP         17 September 1996


References

    [Arm96] G. Armitage.  Support for Multicast over UNI 3.1 based ATM
            Networks.  Internet Draft, draft-ietf-ipatm-ipmc-12.txt,
            February 1996.

   [Ber96a] L. Berger.  RSVP over ATM: Framework and UNI 3.0/3.1 Method.
            Internet Draft, draft-berger-rsvp-over-atm-00.ps, June 1996.

   [Ber96b] S. Berson.  IP Integrated Services Support in ATM.  Internet
            Draft, draft-ietf-issll-atm-support-00.ps, June 1996.

     [BG96] M. Borden and M. Garrett.  Interoperation of Controlled-Load
            and Guaranteed-Service with ATM.  Internet Draft,
            draft-borden-intserv-atm-mapping-00.txt, June 1996.

     [RT96] M. Ammar R. Talpade.  Multicast Server Architectures
            for MARS-based ATM multicasting.  Internet Draft,
            draft-ietf-ion-marsmcs-00.txt, June 1996.

     [RY96] D. Hoffman R. Yavatkar, E. Patki.  SBM (Subnet Bandwidth
            Manager):  A Proposal for Admission Control over Ethernet.
            Internet draft, draft-yavatkar-sbm-ethernet-00.txt, June
            1996.


4. Authors' Address


   Roch Guerin
   IBM T.J. Watson research Center
   P.O. Box 704
   Yorktown Heights, NY 10598
   guerin@watson.ibm.com
   VOICE   +1 914 784-7038
   FAX     +1 914 784-6318

   Dilip Kandlur
   IBM T.J. Watson research Center
   P.O. Box 704
   Yorktown Heights, NY 10598
   kandlur@watson.ibm.com
   VOICE   +1 914 784-7722
   FAX     +1 914 784-6205

   Doug Williams
   IBM T.J. Watson research Center
   P.O. Box 704



Guerin,Kandlur,Williams          Expires 22 March 1997          [Page 4]


Internet Draft         MARS Extension for RSVP         17 September 1996


   Yorktown Heights, NY 10598
   dougw@watson.ibm.com
   VOICE   +1 914 784-5047
   FAX     +1 914 784-6318















































Guerin,Kandlur,Williams          Expires 22 March 1997          [Page 5]