Multicast Server Architectures for MARS-based ATM multicasting
RFC 2149

Document Type RFC - Informational (May 1997; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2149 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         R. Talpade
Request for Comments: 2149                                      M. Ammar
Category: Informational                  Georgia Institute of Technology
                                                                May 1997

     Multicast Server Architectures for MARS-based ATM multicasting

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   A mechanism to support the multicast needs of layer 3 protocols in
   general, and IP in particular, over UNI 3.0/3.1 based ATM networks
   has been described in RFC 2022.  Two basic approaches exist for the
   intra-subnet (intra-cluster) multicasting of IP packets.  One makes
   use of a mesh of point to multipoint VCs (the 'VC Mesh' approach),
   while the other uses a shared point to multipoint tree rooted on a
   Multicast Server (MCS). This memo provides details on the design and
   implementation of an MCS, building on the core mechanisms defined in
   RFC 2022.  It also provides a mechanism for using multiple MCSs per
   group for providing fault tolerance.  This approach can be used with
   RFC 2022 based MARS server and clients, without needing any change in
   their functionality.

1 Introduction

   A solution to the problem of mapping layer 3 multicast service over
   the connection-oriented ATM service provided by UNI 3.0/3.1, has been
   presented in [GA96].  A Multicast Address Resolution Server (MARS) is
   used to maintain a mapping of layer 3 group addresses to ATM
   addresses in that architecture.  It can be considered to be an
   extended analog of the ATM ARP Server introduced in RFC 1577
   ([ML93]).  Hosts in the ATM network use the MARS to resolve layer 3
   multicast addresses into corresponding lists of ATM addresses of
   group members.  Hosts keep the MARS informed when they need to join
   or leave a particular layer 3 group.

   The MARS manages a "cluster" of ATM-attached endpoints.  A "cluster"
   is defined as

   "The set of ATM interfaces choosing to participate in direct ATM
   connections to achieve multicasting of AALSDUs between themselves."

Talpade & Ammar              Informational                      [Page 1]
RFC 2149             Multicast Server Architectures             May 1997

   In practice, a cluster is the set of endpoints that choose to use the
   same MARS to register their memberships and receive their updates
   from.

   A sender in the cluster has two options for multicasting data to the
   group members.  It can either get the list of ATM addresses
   constituting the group from the MARS, set up a point-to-multipoint
   virtual circuit (VC) with the group members as leaves, and then
   proceed to send data out on it.  Alternatively, the source can make
   use of a proxy Multicast Server (MCS).  The source transmits data to
   such an MCS, which in turn uses a point-to-multipoint VC to get the
   data to the group members.

   The MCS approach has been briefly introduced in [GA96].  This memo
   presents a detailed description of MCS architecture and proposes a
   simple mechanism for supporting multiple MCSs for fault tolerance.
   We assume an understanding of the IP multicasting over UNI 3.0/3.1
   ATM network concepts described in [GA96], and access to it.  This
   document is organized as follows.  Section 2 presents interactions
   with the local UNI 3.0/3.1 signaling entity that are used later in
   the document and have been originally described in [GA96].  Section 3
   presents an MCS architecture, along with a description of its
   interactions with the MARS. Section 4 describes the working of an
   MCS. The possibility of using multiple MCSs for the same layer 3
   group, and the mechanism needed to support such usage, is described
   in section 5.  A comparison of the VC Mesh approach and the MCS
   approach is presented in Appendix A.

2 Interaction with the local UNI 3.0/3.1 signaling entity

   The following generic signaling functions are presumed to be
   available to local AAL Users:

   LCALL-RQ - Establish a unicast VC to a specific endpoint.
   LMULTI-RQ - Establish multicast VC to a specific endpoint.
   LMULTI-ADD - Add new leaf node to previously established VC.
   LMULTI-DROP - Remove specific leaf node from established VC.
   LRELEASE - Release unicast VC, or all Leaves of a multicast VC.

   The following indications are assumed to be available to AAL Users,
   generated by by the local UNI 3.0/3.1 signaling entity:

   LACK - Succesful completion of a local request.
   LREMOTE-CALL - A new VC has been established to the AAL User.
   ERRL-RQFAILED - A remote ATM endpoint rejected an LCALLRQ,
                         LMULTIRQ, or L-MULTIADD.
   ERRL-DROP - A remote ATM endpoint dropped off an existing VC.
   ERRL-RELEASE - An existing VC was terminated.
Show full document text