rfc2149.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   The first MCS thus becomes the active MCS and supports the group as
   described in section 4.  The active MCS also opens a point-to-
   multipoint VC (HelloVC) to the remaining MCSs in the set (the
   inactive MCSs).  It starts sending HELLO messages on this VC at a
   fixed interval (HelloInterval seconds).  The inactive MCSs maintain a
   timer to keep track of the last received HELLO message.  If an
   inactive MCS does not receive a message within HelloInterval*
   DeadFactor seconds (values of HelloInterval and DeadFactor are the
   same at all the MCSs), or if the HelloVC is closed, it assumes
   failure of the active MCS and attempts to elect a new one.  The
   election process is described in section 5.5.

   If an MCS is elected as the new active one, it registers to support
   the group with the MARS. It also initiates the transmission of HELLO
   messages to the remaining inactive MCSs.

5.3 Inter-MCS control messages

   The protocol uses HELLO messages in the heartbeat mechanism, and also
   during the election process.  The format of the HELLO message is
   based on that described in [LA96].  The Hello message type code is 5.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sender Len    |    Recvr Len  | State | Type  |    unused     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |          DeadFactor           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IP Multicast address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sender ATM address (variable length)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Receiver ATM address (variable length)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sender Len
     This field holds the length in octets of the Sender ATM address.

   Recvr Len
     This field holds the length in octets of the Receiver ATM
     address.

   State
     Currently two states: No-Op (0x00) and Elected (0x01).
     It is used by a candidate MCS to indicate if it was successfully
     elected.




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


   Type
     This is the code for the message type.

   HelloInterval
     The hello interval advertises the time between sending of
     consecutive Hello Messages by an active MCS.  If the time between
     Hello messages exceeds the HelloInterval then the Hello is to be
     considered late by the inactive MCS.

   DeadFactor
     This is a multiplier to the HelloInterval. If an inactive MCS
     does not receive a Hello message within the interval
     HelloInterval*DeadFactor from an active MCS that advertised
     the HelloInterval then the inactive MCS MUST consider the active
     one to have failed.

   IP Multicast address
     This field is used to indicate the group to associate the HELLO
     message with. It is useful if MCSs can support more than one
     group.

   Sender ATM address
     This is the protocol address of the server which is sending the
     Hello.

   Receiver ATM address
     This is the protocol address of the server which is to Reply to
     the Hello.  If the sender does not know this address then the
     sender sets it to zero. (This happens in the HELLO messages sent
     from the active MCS to the inactive ones, as they are multicast
     and not sent to one specific receiver).




















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


5.4 The Multiple MCS protocol

   As is indicated in section 5.1, all the MCSs supporting the same IP
   Multicast group MUST be started up together.  The set of MCSs
   ("mcslist") MUST be specified to each MCS in the set at startup.
   After registering to support the group with the MARS, the first MCS
   in the set MUST open a point-to-multipoint VC (HelloVC) with the
   remaining MCSs in the "mcslist" as leaves, and thus assumes the role
   of active MCS. It MUST send HELLO messages HelloInterval seconds
   apart on this VC. The Hello message sent by the active MCS MUST have
   the Receiver Len set to zero, the State field set to "Elected", with
   the other fields appropriately set.  The Receiver ATM address field
   does not exist in this HELLO message.  The initial value of
   HelloInterval and DeadFactor MUST be the same at all MCSs at startup.
   The active MCS can choose to change these values by introducing the
   new value in the HELLO messages that are sent out.  The active MCS
   MUST support the group as described in section 4.

   The other MCSs in "mcslist" determine the identity of the first MCS
   from the "mcslist".  They MUST NOT register to support the group with
   the MARS, and become inactive MCSs.  On startup, an inactive MCS
   expects HELLO messages from the active MCS. The inactive MCS MUST
   terminate the HelloVC.  A timer MUST be maintained, and if the
   inactive MCS does not receive HELLO message from the active one
   within a period HelloInterval*DeadFactor seconds, it assumes that the
   active MCS died, and initiates the election process as described in
   section 5.5.  If a HELLO message is received within this period, the
   inactive MCS does not initiate any further action, other than
   restarting the timer.  The inactive MCSs MUST set their values of
   HelloInterval and DeadFactor to those specified by the active MCS in
   the HELLO messages.

   In case of an MCS supporting multiple groups, it MUST register to
   support those groups for which it is the first MCS, and MUST NOT
   register for other groups.  A MARSMSERV with multiple <min, max>
   pairs may be used for registering multiple disjoint sets of groups.
   Support MUST be provided for the use of a single "mcslist" for more
   than one group.  This is intended to address the case wherein an MCS
   is intended to support multiple groups, with other MCSs acting as
   backups.  This subverts the need for using a different "mcslist" for
   each group being supported by the same set of MCSs.

   On failure of the active MCS, a new MCS assumes its role as described
   in section 5.5.  In this case, the remaining inactive MCSs will
   expect HELLO messages from this new active MCS as described in the
   previous paragraph.





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


5.5 Failure handling

5.5.1 Failure of active MCS

   The failure of the active MCS is detected by the inactive MCSs if no
   HELLO message is received within an interval of
   HelloInterval*DeadFactor seconds, or if the HelloVC is closed.  In
   this case the next MCS in "mcslist" becomes the candidate MCS. It
   MUST open a point-to-multipoint VC to the remaining inactive MCSs
   (HelloVC) and send a HELLO message on it with the State field set to
   No-Op.  The rest of the message is formatted as described earlier.

   On receiving a HELLO message from a candidate MCS, an inactive MCS
   MUST open a point-to-point VC to that candidate.  It MUST send a
   HELLO message back to it, with the Sender and Receiver fields
   appropriately set (not zero), and the State field being No-Op.  If a
   HELLO message is received by an inactive MCS from a non-candidate
   MCS, it is ignored.  If no HELLO message is received from the
   candidate with the State field set to "Elected" in HelloInterval
   seconds, the inactive MCS MUST retransmit the HELLO. If no HELLO
   message with State field set to "Elected" is received by the inactive
   MCSs within an interval of HelloInterval*DeadFactor seconds, the next
   MCS in "mcslist" is considered as the candidate MCS. Note that the
   values used for HelloInterval and DeadFactor in the election phase
   are the default ones.

   The candidate MCS MUST wait for a period of HelloInterval*DeadFactor
   seconds for receiving HELLO messages from inactive MCSs.  It MUST
   transmit HELLO messages with State field set to No-Op at
   HelloInterval seconds interval during this period.  If it receives
   messages from atleast half of the remaining inactive MCSs during this
   period, it considers itself elected and assumes the active MCS role.
   It then registers to support the group with the MARS, and starts
   sending HELLO messages at HelloInterval second intervals with State
   field set to "Elected" on the already existing HelloVC. The active
   MCS can then alter the HelloInterval and DeadFactor values if
   desired, and communicate the same to the inactive MCSs in the HELLO
   message.

5.5.2 Failure of inactive MCS

   If an inactive MCS drops off the HelloVC, the active MCS MUST attempt
   to add that MCS back to the VC for three attempts, spaced
   HelloInterval*DeadFactor seconds apart.  If even the third attempt
   fails, the inactive MCS is considered dead.






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


   An MCS, active or inactive, MUST NOT be started up once it has
   failed.  Failed MCSs can only be started up by manual intervention
   after shutting down all the MCSs, and restarting them together.

5.6 Compatibility with future MARS and MCS versions

   Future versions of MCSs can be expected to use an enhanced MARS for
   load sharing and fault tolerance ([TA96]).  The MCS architecture
   described in this document is compatible with the enhanced MARS and
   the future MCS versions.  This is because the active MCS is the only
   one which communicates with the MARS about the group.  Hence the
   active MCS will only be informed by the enhanced MARS about the
   subset of the group that it is to support.  Thus MCSs conforming to
   this document are compatible with [GA96] based MARS, as well as
   enhanced MARS.

6 Summary

   This document describes the architecture of an MCS. It also provides
   a mechanism for using multiple MCSs per group for providing fault
   tolerance.  This approach can be used with [GA96] based MARS server
   and clients, without needing any change in their functionality.  It
   uses the HELLO packet format as described in [LA96] for the heartbeat
   messages.

7 Acknowledgements

   We would like to acknowledge Grenville Armitage (Bellcore) for
   reviewing the document and suggesting improvements towards
   simplifying the multiple MCS functionalities.  Discussion with Joel
   Halpern (Newbridge) helped clarify the multiple MCS problem.  Anthony
   Gallo (IBM RTP) pointed out security issues that are not adequately
   addressed in the current document.  Arvind Murching (Microsoft)
   flagged a potential show stopper in section 4.1.2.

8 Authors' Address

   Rajesh Talpade
   College of Computing
   Georgia Institute of Technology
   Atlanta, GA 30332-0280

   Phone: [phone]
   Email: [e-mail]







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


   Mostafa H. Ammar
   College of Computing
   Georgia Institute of Technology
   Atlanta, GA 30332-0280

   Phone: [phone]
   Email:  [e-mail]

9 References

[GA96]   Armitage, G.J., "Support for Multicast over UNI 3.0/3.1 based
         ATM networks", RFC 2022, November 1996.

[BK95]   Birman, A., Kandlur, D., Rubas, J., "An extension to the MARS
         model", Work in Progress.

[LM93]   Laubach, M., "Classical IP and ARP over ATM", RFC1577,
         Hewlett-Packard Laboratories, December 1993.

[LA96]   Luciani, J., G. Armitage, and J. Halpern, "Server Cache
         Synchronization Protocol (SCSP) - NBMA", Work in Progress.

[TA96]   Talpade, R., and Ammar, M.H., "Multiple MCS support using an
         enhanced version of the MARS server.", Work in Progress.



























Talpade & Ammar              Informational                     [Page 18]