rfc2149.txt

RFC 的详细文档！


RFC 2149             Multicast Server Architectures             May 1997


   After the active MCS registers to support a layer 3 group, it uses
   MARSREQUEST and MARS-MULTI to obtain information about group
   membership from the MARS. These messages are also used during the
   revalidation phase (section 4.5) and when no outgoing VC exists for a
   received layer 3 packet (section 4.3).

   On registering to support a particular layer 3 group, the MCS MUST
   send a MARSREQUEST to the MARS. The mechanism to retrieve group
   membership and the format of MARSREQUEST and MARS-MULTI is described
   in section 5.1.1 and 5.1.2 of [GA96] respectively.  The MCS MUST use
   this mechanism for sending (and retransmitting) the MARSREQUEST and
   processing the returned MARSMULTI(/s).  The MARS-MULTI MUST be
   received correctly, and the MCS MUST use it to initialize its
   knowledge of group membership.

   On successful reception of a MARSMULTI, the MCS MUST attempt to open
   the outgoing point-to-multipoint VC using the mechanism described in
   section 5.1.3 of [GA96], if any group members exist.  The MCS however
   MUST start transmitting data on this VC after it has opened it
   successfully with at least one of the group members as a leaf, and
   after it has attempted to add all the group members at least once.

4.3 Usage of outgoing point-to-multipoint VC

   Cluster members which are sources for MCS-supported layer 3 groups
   send (encapsulated) layer 3 packets to the designated MCSs.  An MCS,
   on receiving them from cluster members, has to send them out over the
   specific point-to-multipoint VC for that layer 3 group.  This VC is
   setup as described in the previous section.  However, it is possible
   that no group members currently exist, thus causing no VC to be
   setup.  So an MCS may have no outgoing VC to forward received layer 3
   packets on, in which case it MUST initiate the MARSREQUEST and MARS-
   MULTI sequence described in the previous section.  This new MARSMULTI
   could contain new members, whose MARSSJOINs may have been not
   received by the MCS (and the loss not detected due to absence of
   traffic on the ServerControlVC).

   If an MCS learns that there are no group members (MARSNAK received
   from MARS), it MUST delay sending out a new MARSREQUEST for that
   group for a period no less than 5 seconds and no more than 10
   seconds.

   Layer 3 packets received from cluster members, while no outgoing
   point-to-multipoint VC exists for that group, MUST be silently
   dropped after following the guidelines in the previous paragraphs.
   This might result in some layer 3 packets being lost until the VC is
   setup.




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


   Each outgoing point-to-multipoint VC has a revalidate flag associated
   with it.  This flag MUST be checked whenever a layer 3 packet is sent
   out on that VC. No action is taken if it is not set.  If it is set,
   the packet is sent out, the revalidation procedure (section 4.5.3)
   MUST be initiated for this group, and the flag MUST be reset.

   In case of error on a point-to-multipoint VC, the MCS MUST initiate
   revalidation procedures for that VC as described in section 4.5.3.
   Once a point-to-multipoint VC has been setup for a particular layer 3
   group, the MCS MUST hold the VC open and mark it as the outgoing path
   for any subsequent layer 3 packets being sent for that group address.
   A point-to-multipoint VC MUST NOT have an activity timer associated
   with it.  It is to remain up at all times, unless the MCS explicitly
   stops supporting that layer 3 group, or no more leaves exist on the
   VC which causes it to be shut down.  The VC is kept up inspite of
   non-existent traffic to reduce the delay suffered by MCS supported
   groups.  If the VC were to be shut down on absence of traffic, the VC
   reestablishment procedure (needed when new traffic for the layer 3
   group appears) would further increase the initial delay, which can be
   potentially higher than the VC mesh approach anyway as two VCs need
   to be setup in the MCS case (one from source to MCS, second from MCS
   to group) as opposed to only one (from source to group) in the VC
   Mesh approach.  This approach of keeping the VC from the MCS open
   even in the absense of traffic is experimental.  A decision either
   way can only be made after gaining experience (either through
   implementation or simulation) about the implications of keeping the
   VC open.

   If the MCS supports multiple layer 3 groups, it MUST follow the
   procedure outlined in the four previous subsections for each group
   that it is an active MCS. Each incoming data AALSDU MUST be examined
   for determining its recipient group, before being forwarded onto the
   appropriate outgoing point-to-multipoint VC.

4.3.1 Group member dropping off a point-to-multipoint VC

   AN ERRL-DROP may be received during the lifetime of a point-to-
   multipoint VC indicating that a leaf node has terminated its
   participation at the ATM level.  The ATM endpoint associated with the
   ERRL-DROP MUST be removed from the locally held set associated with
   the VC. The revalidate flag on the VC MUST be set after a random
   interval of 1 through 10 seconds.

   If an ERRL-RELEASE is received for a VC, then the entire set is
   cleared and the VC considered to be completely shutdown.  A new VC
   for this layer 3 group will be established only on reception of new
   traffic for the group (as described in section 4.3).




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


4.4 Processing of MARSSJOIN and MARS-SLEAVE

   The MARS transmits equivalent MARSSJOIN/MARS-SLEAVE on the
   ServerControlVC when it receives MARSJOIN/MARS-LEAVE from cluster
   members.  The MCSs keep track of group membership updates through
   these messages.  The format of these messages are identical to
   MARSJOIN and MARS-LEAVE, which are described in section 5.2.1 of
   [GA96].  It is sufficient to note here that these messages carry the
   ATM address of the node joining/leaving the group(/s), the group(/s)
   being joined or left, and a Server Sequence Number from MARS.

   When a MARSSJOIN is seen which refers to (or encompasses) a layer 3
   group (or groups) supported by the MCS, the following action MUST be
   taken.  The new member's ATM address is extracted from the MARSSJOIN.
   An L-MULTIADD is issued for the new member for each of those referred
   groups which have an outgoing point-to-multipoint VC. An LMULTI-RQ is
   issued for the new member for each of those refered groups which have
   no outgoing VCs.

   When a MARSSLEAVE is seen that refers to (or encompasses) a layer 3
   group (or groups) supported by the MCS, the following action MUST be
   taken.  The leaving member's ATM address is extracted.  An LMULTI-
   DROP is issued for the member for each of the refered groups which
   have an outgoing point-to-multipoint VC.

   There is a possibility of the above requests (LMULTI-RQ or LMULTIADD
   or LMULTI-DROP) failing.  The UNI 3.0/3.1 failure cause must be
   returned in the ERRL-RQFAILED signal from the local signaling entity
   to the AAL User.  If the failure cause is not 49 (Quality of Service
   unavailable), 51 (user cell rate not available - UNI 3.0), 37 (user
   cell rate not available - UNI 3.1), or 41 (Temporary failure), the
   endpoint's ATM address is dropped from the locally held view of the
   group by the MCS. Otherwise, the request MUST be re-attempted with
   increasing delay (initial value between 5 to 10 seconds, with delay
   value doubling after each attempt) until it either succeeds or the
   multipoint VC is released or a MARSSLEAVE is received for that group
   member.  If the VC is open, traffic on the VC MUST continue during
   these attempts.

   MARSSJOIN and MARS-SLEAVE are processed differently if multiple MCSs
   share the members of the same layer 3 group (section 5.4).  MARSSJOIN
   and MARSSLEAVE that do not refer to (or encompass) supported groups
   MUST be used to track the Server Sequence Number (section 4.5.1), but
   are otherwise ignored.







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


4.5 Revalidation Procedures

   The MCS has to initiate revalidation procedures in case of certain
   failures or errors.

4.5.1 Server Sequence Number

   The MCS needs to track the Server Sequence Number (SSN) in the
   messages received on the ServerControlVC from the MARS. It is carried
   in the mar$msn of all messages (except MARSNAK) sent by the MARS to
   MCSs.  A jump in SSN implies that the MCS missed the previous
   message(/s) sent by the MARS. The MCS then sets the revalidate flag
   on all outgoing point-to-multipoint VCs after a random delay of
   between 1 and 10 seconds, to avoid all MCSs inundating the MARS
   simultaneously in case of a more general failure.

   The only exception to the rule is if a sequence number is detected
   during the establishment of a new group's VC (i.e.  a MARSMULTI was
   correctly received, but its mar$msn indicated that some previous MARS
   traffic had been missed on ClusterControlVC). In this case every open
   VC, EXCEPT the one just being established, MUST have its revalidate
   flag set at some random interval between 1 and 10 seconds from the
   time the jump in SSN was detected.  (The VC being established is
   considered already validated in this case).

   Each MCS keeps its own 32 bit MCS Sequence Number (MSN) to track the
   SSN.  Whenever a message is received that carries a mar$msn field,
   the following processing is performed:

        Seq.diff = mar$msn - MSN

        mar$msn -> MSN

        (.... process MARS message ....)

        if ((Seq.diff != 1) && (Seq.diff != 0))
              then (.... revalidate group membership information ....)

   The mar$msn value in an individual MARSMULTI is not used to update
   the MSN until all parts of the MARSMULTI (if > 1) have arrived.  (If
   the mar$msn changes during reception of a MARSMULTI series, the
   MARS-MULTI is discarded as described in section 5.1.1 of [GA96]).

   The MCS sets its MSN to zero on startup.  It gets the current value
   of SSN when it receives the copy of the registration MARSMSERV back
   from the MARS.





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


4.5.2 Reconnecting to the MARS

   The MCSs are assumed to have been configured with the ATM address of
   at least one MARS at startup.  MCSs MAY choose to maintain a table of
   ATM addresses, each address representing alternative MARS which will
   be contacted in case of failure of the previous one.  This table is
   assumed to be ordered in descending order of preference.

   An MCS will decide that it has problems communicating with a MARS if:

      * It fails to establish a point-to-point VC with the MARS.

      * MARSREQUEST generates no response (no MARSMULTI or MARS-NAK
      returned).

      * ServerControlVC fails.

      * MARSMSERV or MARSUNSERV do not result in their respective copies
      being
        received.

   (reconnection as in section 5.4 in [GA96], with MCS-specific actions
   used where needed).

4.5.3 Revalidating a point-to-multipoint VC

   The revalidation flag associated with a point-to-multipoint VC is
   checked when a layer 3 packet is to be sent out on the VC.
   Revalidation procedures MUST be initiated for a point-to-multipoint
   VC that has its revalidate flag set when a layer 3 packet is being
   sent out on it.  Thus more active groups get revalidated faster than
   less active ones.  The revalidation process MUST NOT result in
   disruption of normal traffic on the VC being revalidated.

   The revalidation procedure is as follows.  The MCS reissues a
   MARSREQUEST for the VC being revalidated.  The returned set of
   members is compared with the locally held set; LMULTI-ADDs MUST be
   issued for new members, and LMULTI-DROPs MUST be issued for non-
   existent ones.  The revalidate flag MUST be reset for the VC.

5 Multiple MCSs for a layer 3 group

   Having a single MCS for a layer 3 group can cause it to become a
   single point of failure and a bottleneck for groups with large
   numbers of active senders.  It is thus desirable to introduce a level
   of fault tolerance by having multiple MCS per group.  Support for
   load sharing is not introduced in this document as to reduce the
   complexity of the protocol.



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


5.1 Outline

   The protocol described in this document offers fault tolerance by
   using multiple MCSs for the same group.  This is achieved by having a
   standby MCS take over from a failed MCS which had been supporting the
   group.  The MCS currently supporting a group is refered to as the
   active MCS, while the one or more standby MCSs are refered to as
   inactive MCSs.  There is only one active MCS existing at any given
   instant for an MCS-supported group.  The protocol makes use of the
   HELLO messages as described in [LA96].

   To reduce the complexity of the protocol, the following operational
   guidelines need to be followed.  These guidelines need to be enforced
   by out-of-band means which are not specified in this document and can
   be implementation dependent.

      * The set of (one or more) MCSs ("mcslist") that support a
        particular IP Multicast group is predetermined and fixed.  This
        set MUST be known to each MCS in the set at startup, and the
        ordering of MCSs in the set is the same for all MCSs in the set.
        An implementation of this would be to maintain the set of ATM
        addresses of the MCSs in a file, an identical copy of which is
        kept at each MCS in the set.

      * All MCSs in "mcslist" have to be started up together, with the
        first MCS in "mcslist" being the last to be started.

      * A failed MCS cannot be started up again.

5.2 Discussion of Multiple MCSs in operation

   An MCS on startup determines its position in the "mcslist".  If the
   MCS is not the first in "mcslist", it does not register for
   supporting the group with the MARS. If the MCS is first in the set,
   it does register to support the group.
















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