rfc2149.txt

<VC++网络游戏建摸与实现>源代码

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.



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


3 MCS Architecture

   The MCS acts as a proxy server which multicasts data received from a
   source to the group members in the cluster.  All multicast sources
   transmitting to an MCS-based group send the data to the specified
   MCS. The MCS then forwards the data over a point to multipoint VC
   that it maintains to group members in the cluster.  Each multicast
   source thus maintains a single point-to-multipoint VC to the
   designated MCS for the group.  The designated MCS terminates one
   point-to-multipoint VC from each cluster member that is multicasting
   to the layer 3 group.  Each group member is the leaf of the point-
   to-multipoint VC originating from the MCS.

   A brief introduction to possible MCS architectures has been presented
   in [GA96].  The main contribution of that document concerning the MCS
   approach is the specification of the MARS interaction with the MCS.
   The next section lists control messages exchanged by the MARS and
   MCS.

3.1 Control Messages exchanged by the MCS and the MARS

   The following control messages are exchanged by the MARS and the MCS.

   operation code                Control Message

         1                       MARS_REQUEST
         2                       MARS_MULTI
         3                       MARS_MSERV
         6                       MARS_NAK
         7                       MARS_UNSERV
         8                       MARS_SJOIN
         9                       MARS_SLEAVE
        12                       MARS_REDIRECT_MAP

   MARSMSERV and MARS-UNSERV are identical in format to the MARSJOIN
   message.  MARSSJOIN and MARS-SLEAVE are also identical in format to
   MARSJOIN. As such, their formats and those of MARSREQUEST, MARS-
   MULTI, MARSNAK and MARSREDIRECT-MAP are described in [GA96].  Their
   usage is described in section 4.  All control messages are LLC/SNAP
   encapsulated as described in section 4.2 of [GA96].  (The "mar$"
   notation used in this document is borrowed from [GA96], and indicates
   a specific field in the control message.)  Data messages are
   reflected without any modification by the MCS.








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


3.2 Association with a layer 3 group

   The simplest MCS architecture involves taking incoming AALSDUs from
   the multicast sources and sending them out over the point-to-
   multipoint VC to the group members.  The MCS can service just one
   layer 3 group using this design, as it has no way of distinguishing
   between traffic destined for different groups.  So each layer 3 MCS-
   supported group will have its own designated MCS.

   However it is desirable in the interests of saving resources to
   utilize the same MCS to support multiple groups.  This can be done by
   adding minimal layer 3 specific processing into the MCS. The MCS can
   now look inside the received AALSDUs and determine which layer 3
   group they are destined for.  A single instance of such an MCS could
   register its ATM address with the MARS for multiple layer 3 groups,
   and manage multiple point-to-multipoint VCs, one for each group.
   This capability is included in the MCS architecture, as is the
   capability of having multiple MCSs per group (section 5).

4 Working of MCS

   An MCS MUST NOT share its ATM address with any other cluster member
   (MARS or otherwise).  However, it may share the same physical ATM
   interface (even with other MCSs or the MARS), provided that each
   logical entity has a different ATM address.  This section describes
   the working of MCS and its interactions with the MARS and other
   cluster members.

4.1 Usage of MARSMSERV and MARS-UNSERV

4.1.1 Registration (and deregistration) with the MARS

   The ATM address of the MARS MUST be known to the MCS by out-of-band
   means at startup.  One possible approach for doing this is for the
   network administrator to specify the MARS address at command line
   while invoking the MCS. On startup, the MCS MUST open a point-to-
   point control VC (MARSVC) with the MARS. All traffic from the MCS to
   the MARS MUST be carried over the MARSVC. The MCS MUST register with
   the MARS using the MARS-MSERV message on startup.  To register, a
   MARSMSERV MUST be sent by the MCS to the MARS over the MARSVC. On
   receiving this MARS-MSERV, the MARS adds the MCS to the
   ServerControlVC. The ServerControlVC is maintained by the MARS with
   all MCSs as leaves, and is used to disseminate general control
   messages to all the MCSs.  The MCS MUST terminate this VC, and MUST
   expect a copy of the MCS registration MARSMSERV on the MARS-VC from
   the MARS.





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


   An MCS can deregister by sending a MARSUNSERV to the MARS. A copy of
   this MARSUNSERV MUST be expected back from the MARS. The MCS will
   then be dropped from the ServerControlVC.

   No protocol specific group addresses are included in MCS registration
   MARSMSERV and MARS-UNSERV. The mar$flags.register bit MUST be set,
   the mar$cmi field MUST be set to zero, the mar$flags.sequence field
   MUST be set to zero, the source ATM address MUST be included and a
   null source protocol address MAY be specified in these MARSMSERV and
   MARS-UNSERV. All other fields are set as described in section 5.2.1
   of [GA96] (the MCS can be considered to be a cluster member while
   reading that section).  It MUST keep retransmitting (section 4.1.3)
   the MARSMSERV/MARS-UNSERV over the MARSVC until it receives a copy
   back.

   In case of failure to open the MARSVC, or error on it, the
   reconnection procedure outlined in section 4.5.2 is to be followed.

4.1.2 Registration (and deregistration) of layer 3 groups

   The MCS can register with the MARS to support particular group(s).
   To register groups X through Y, a MARSMSERV with a <min, max> pair of
   <X, Y> MUST be sent to the MARS. The MCS MUST expect a copy of the
   MARSMSERV back from the MARS. The retransmission strategy outlined in
   section 4.1.3 is to be followed if no copy is received.

   The MCS MUST similarly use MARSUNSERV if it wants to withdraw support
   for a specific layer 3 group.  A copy of the group MARSUNSERV MUST be
   received, failing which the retransmission strategy in section 4.1.3
   is to be followed.

   The mar$flags.register bit MUST be reset and the mar$flags.sequence
   field MUST be set to zero in the group MARSMSERV and MARS-UNSERV. All
   other fields are set as described in section 5.2.1 of [GA96] (the MCS
   can be considered to be a cluster member when reading that section).

4.1.3 Retransmission of MARSMSERV and MARS-UNSERV

   Transient problems may cause loss of control messages.  The MCS needs
   to retransmit MARSMSERV/MARS-UNSERV at regular intervals when it does
   not receive a copy back from the MARS. This interval should be no
   shorter than 5 seconds, and a default value of 10 seconds is
   recommended.  A maximum of 5 retransmissions are permitted before a
   failure is logged.  This MUST be considered a MARS failure, which
   SHOULD result in the MARS reconnection mechanism described in section
   4.5.2.





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


   A "copy" is defined as a received message with the following fields
   matching the previously transmitted MARSMSERV/MARS-UNSERV:

   -  mar$op
   -  mar$flags.register
   -  mar$pnum
   -  Source ATM address
   -  first <min, max> pair

   In addition, a valid copy MUST have the following field values:

   -  mar$flags.punched = 0
   -  mar$flags.copy = 1

   If either of the above is not true, the message MUST be dropped
   without resetting of the MARSMSERV/MARS-UNSERV timer.  There MUST be
   only one MARSMSERV or MARS-UNSERV outstanding at a time.

4.1.4 Processing of MARSMSERV and MARS-UNSERV

   The MARS transmits copies of group MARSMSERV and MARS-UNSERV on the
   ServerControlVC. So they are also received by MCSs other than the
   originating one.  This section discusses the processing of these
   messages by the other MCSs.

   If a MARSMSERV is seen that refers to a layer 3 group not supported
   by the MCS, it MUST be used to track the Server Sequence Number
   (section 4.5.1) and then silently dropped.

   If a MARSMSERV is seen that refers to a layer 3 group supported by
   the MCS, the MCS learns of the existence of another MCS supporting
   the same group.  This possibility is incorporated (of multiple MCSs
   per group) in this version of the MCS approach and is discussed in
   section 5.

4.2 Usage of MARSREQUEST and MARS-MULTI

   As described in section 5.1, the MCS learns at startup whether it is
   an active or inactive MCS. After successful registration with the
   MARS, an MCS which has been designated as inactive for a particular
   group MUST NOT register to support that group with the MARS. It
   instead proceeds as in section 5.4.  The active MCS for a group also
   has to do some special processing, which we describe in that section.
   The rest of section 4 describes the working of a single active MCS,
   with section 5 describing the active MCSs actions for supporting
   multiple MCSs.





Talpade & Ammar              Informational                      [Page 6]