One document matched: draft-kandlur-ipatm-mars-directvc-00.txt

Internet Engineering Task Force                                A. Birman
INTERNET DRAFT                                                D. Kandlur
                                                                J. Rubas
                                                                     IBM
                                                        28 November 1995


                     An extension to the MARS model
                draft-kandlur-ipatm-mars-directvc-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).  In the extended
   architecture the determination whether a Multicast Server (MCS) or a
   point-to-multipoint VC will be used for multicasting is made by the
   application in the sender endpoint.  Moreover, there can be senders
   in a multicast group using point-to-multipoint VCs while other
   senders use a MCS.

   It is assumed that the reader is familiar with the MARS document
   [MARS].










Birman, Kandlur, Rubas           Expires 31 May 1996            [Page i]

Internet Draft              MARS Extension              28 November 1995


1. Introduction

   The MARS document [MARS] describes a mechanism for handling IP
   multicast over ATM. Clusters of endpoints 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.

   Yet in many important cases it is better to have the SVC management
   controlled directly by applications, as described in [Rekhter95].
   For applications that have a relatively long lifetime and also
   require QoS guarantees the establishment of dedicated multicast VCs
   can be certainly justified.  Other applications could be served by
   the shared service provided by MCSs and thus the overhead associated
   with the establishment and maintenance of separate multicast VCs can
   be avoided.

   Moreover, there is further evidence that the MARS mechanism should
   be generalized to allow some endpoints in a multicast group to use
   separate point-to-multipoint VCs while other endpoints would rely
   on the MCS. Specifically, consider the scenario in which a source
   endpoint sends an RTP multimedia stream to a multicast group, as
   in an MBONE style conference.  The source would use a separate
   point-to-multipoint VC with QoS guarantees.  At the same time the
   source receives periodic RTP reports from the multicast receivers.
   These reports could use the default VCC through the MCS. In the
   current MARS architecture one would have to use either the MCS for
   all senders in the group, or a mesh of VCs for every sender in the
   group.


2. Summary of proposed changes to MARS

   An endpoint which is a sender to a multicast group may have an
   application-driven requirement that it multicasts to the members
   of the group using a point-to-multipoint VC. We will refer to such
   a sender endpoint as a Direct Sender.  In order to establish this
   point-to-multipoint VC to the members of the multicast group the
   endpoint has the added ability to request, and receive, from the
   MARS the list of ATM addresses corresponding to the members of the
   multicast group (the 'host map').  Furthermore, a Direct Sender
   needs to track membership in the multicast group, very much like an
   MCS. For this reason, if an MCS exists for the group then the Direct
   Sender is added as a leaf to ServerControlVC.




Birman, Kandlur, Rubas           Expires 31 May 1996            [Page 1]

Internet Draft              MARS Extension              28 November 1995


   The proposed extension to MARS is intended to be backward compatible
   with the MARS architecture.  Specifically, hosts implementing the
   MARS extension should interoperate with a MARS or other hosts which
   implement only the MARS architecture [MARS].

   Two issues arise in connection with these changes, and they will be
   addressed in the discussion below.  Since a Direct Sender may be
   a member of both ClusterControlVC and ServerControlVC, and since
   it must track sequence numbers on both ``control VCs'', it must
   have the ability to identify the control VC on which the message
   arrived.  Another issue concerns applications which have a high
   join/leave activity, such as Distributed Interactive Simulations.
   These applications may cause significant non-productive traffic of
   MARS messages on a control VC.


3. The proposed changes to the MARS

3.1. TLVs defined

   (a) get_map:  When used in a MARS_REQUEST message has the following
   meaning:  ON: endpoint is requesting a host map.  OFF: undefined.

   When used in a MARS_MULTI message has the following meaning:  ON: the
   message contains the requested host map.  OFF: undefined.

   (b) direct_sender:  When used in a MARS_LEAVE message has the
   following meaning:  ON: endpoint is no longer a Direct Sender to the
   multicast group.  OFF: undefined.

   When used in a MARS_UNSERV message has the following meaning:  ON:
   endpoint is no longer a Direct Sender to any multicast group.  OFF:
   undefined.

   (c) control_vc_id:  When used in a message sent by the MARS it
   identifies the control VC on which the message was sent.  It is an
   unsigned integer.


3.2. Sender endpoint behavior

   When a Direct Sender requires a host map it sends a MARS_REQUEST
   with the get_map TLV ON (i.e.  value set to ON). If the MARS_MULTI
   received in return has the get_map TLV ON then the endpoint can
   proceed.  If the MARS_MULTI does not have the get_map TLV ON then the
   endpoint should assume that the MARS does not support this feature
   and should discontinue its Direct Sender status.




Birman, Kandlur, Rubas           Expires 31 May 1996            [Page 2]

Internet Draft              MARS Extension              28 November 1995


   If the MARS was able to satisfy the endpoint's request then it is
   possible that the endpoint may receive MARS messages on multiple
   control VCs.  The Direct Sender must be able to support MARS messages
   arriving on multiple control VCs.  As an aid in distinguishing these
   messages the endpoint should support the control_vc_id TLV when
   attached to MARS messages.  Endpoints which do not support this
   feature should ignore the control_vc_id TLV.

   An endpoint which is a Direct Sender in a multicast group may cease
   to be a sender for that group due to the expiration of an inactivity
   timer or due to an application-initiated request.  The endpoint then
   releases the point-to-multipoint VC to the members of the group and
   sends to the MARS a MARS_LEAVE message with the direct_sender TLV
   ON. The endpoint then determines whether it continues to be a Direct
   Sender for other groups.  If there are no groups left for which the
   endpoint is a Direct Sender then it sends to the MARS a MARS_UNSERV
   message with the direct_sender TLV ON.

   A MARS_MIGRATE message arriving from the MARS is an indicator that
   the endpoint will now receive updates on ServerControlVC instead of
   ClusterControlVC.


3.3. MARS behavior

   A generic data structure, Direct Sender List, contains entries of the
   form {mc_address, atm.1, ..., atm.k} where mc_address is a multicast
   group address and ATM addresses atm.1, ..., atm.k correspond to the
   Direct Senders in that group.

   When the MARS receives a MARS_REQUEST from an endpoint requesting
   a host map, the MARS will attach to the MARS_MULTI message the
   get_map TLV. The MARS will indicate in this TLV that the map in the
   MARS_MULTI is a host map.

   When an endpoint is registered, the MARS (as usual) adds the endpoint
   to ClusterControlVC. If that endpoint then requests a host map,
   the MARS will also add the endpoint to ServerControlVC if there is
   an MCS defined for that group or if an MCS becomes defined for the
   group in the future.  Then, it is on ServerControlVC that group
   membership updates will be reflected.  If MARS added the endpoint to
   ServerControlVC, then the entry in the Direct Sender List will be
   updated by adding the ATM address of the endpoint to the entry.

   If an MCS is not defined for the group then the endpoint is not added
   to ServerControlVC and group membership updates will continue to be
   sent on ClusterControlVC.




Birman, Kandlur, Rubas           Expires 31 May 1996            [Page 3]

Internet Draft              MARS Extension              28 November 1995


   When the MARS receives a MARS_LEAVE message with the direct_sender
   TLV ON it recognizes an endpoint which ceases to be a Direct Sender
   in the specified multicast group.  The MARS then updates the Direct
   Sender List.

   When the MARS receives a MARS_UNSERV message with the direct_sender
   TLV ON it recognizes an endpoint which ceased to be a Direct Sender
   in any multicast group.  The MARS then removes it as a leaf in
   ServerControlVC.


4. Non-productive traffic on ServerControlVC

   There is a concern that some applications which have a high
   join/leave activity, such as Distributed Interactive Simulations, may
   cause significant non-productive traffic.  For example, MARS_JOIN and
   MARS_LEAVE messages reflected by the MARS on ServerControlVC have to
   be processed by all Direct Senders.  Thus, each one of these Direct
   Senders has to process all messages in order to select the possible
   few which affect its own multicast group.

   In order to alleviate this problem one could go to the other extreme
   of creating a dedicated control VC for the Direct Senders of every
   multicast group.  Clearly, there exists a range of additional
   possibilities, where the number of control VCs is somewhere in
   between these two extremes.  Depending on the number of multicast
   groups and their behavior one could attempt to optimize the number of
   control VCs.  This topic is left for future study.


5. Tracking sequence numbers

   A Direct Sender may have to track sequence numbers on multiple
   control VCs, and thus must have the ability to identify the control
   VC on which the message arrived.  Since the MARS sequence numbers
   are associated with different VCs it is sufficient that the endpoint
   be able to identify the VC a message arrived on.  It appears that
   this cannot always be counted on.  Therefore, additional information
   needs to be supplied to the endpoint which allows it to identify
   the control VC on which the message arrived.  This information is
   supplied by the control_vc_id TLV.


6. Acknowledgements

   The authors would like to thank Grenville Armitage (Bellcore) and Tim
   Smith (IBM) for their review and comments.




Birman, Kandlur, Rubas           Expires 31 May 1996            [Page 4]

Internet Draft              MARS Extension              28 November 1995


7. References

   [MARS] G. Armitage, "Support for Multicast over UNI 3.1 based ATM
   Networks", Internet Draft, IP over ATM Working Group, draft-ietf-
   ipatm-ipmc-06.txt, August 1995.

   [Rekhter95] Y. Rekhter and D. Kandlur, "IP Architecture Extensions
   for ATM", Internet Draft, draft-rekhter-ip-atm-architecture-01.txt,
   July 1995.


8. Authors' Address

          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


          Alex Birman
          T. J. Watson Research Center
          IBM Corporation
          30 Saw Mill River Rd.
          Hawthorne, NY  10532

          Phone:   +1-914-784-7275
          E-mail: birman@watson.ibm.com


          Jim Rubas
          T. J. Watson Research Center
          IBM Corporation
          30 Saw Mill River Rd.
          Hawthorne, NY  10532

          Phone:   +1-914-784-7794
          E-mail: rubas@watson.ibm.com










Birman, Kandlur, Rubas           Expires 31 May 1996            [Page 5]