home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2149 < prev    next >
Text File  |  1997-05-23  |  42KB  |  1,012 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         R. Talpade
  8. Request for Comments: 2149                                      M. Ammar
  9. Category: Informational                  Georgia Institute of Technology
  10.                                                                 May 1997
  11.  
  12.  
  13.      Multicast Server Architectures for MARS-based ATM multicasting
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    A mechanism to support the multicast needs of layer 3 protocols in
  24.    general, and IP in particular, over UNI 3.0/3.1 based ATM networks
  25.    has been described in RFC 2022.  Two basic approaches exist for the
  26.    intra-subnet (intra-cluster) multicasting of IP packets.  One makes
  27.    use of a mesh of point to multipoint VCs (the 'VC Mesh' approach),
  28.    while the other uses a shared point to multipoint tree rooted on a
  29.    Multicast Server (MCS). This memo provides details on the design and
  30.    implementation of an MCS, building on the core mechanisms defined in
  31.    RFC 2022.  It also provides a mechanism for using multiple MCSs per
  32.    group for providing fault tolerance.  This approach can be used with
  33.    RFC 2022 based MARS server and clients, without needing any change in
  34.    their functionality.
  35.  
  36. 1 Introduction
  37.  
  38.    A solution to the problem of mapping layer 3 multicast service over
  39.    the connection-oriented ATM service provided by UNI 3.0/3.1, has been
  40.    presented in [GA96].  A Multicast Address Resolution Server (MARS) is
  41.    used to maintain a mapping of layer 3 group addresses to ATM
  42.    addresses in that architecture.  It can be considered to be an
  43.    extended analog of the ATM ARP Server introduced in RFC 1577
  44.    ([ML93]).  Hosts in the ATM network use the MARS to resolve layer 3
  45.    multicast addresses into corresponding lists of ATM addresses of
  46.    group members.  Hosts keep the MARS informed when they need to join
  47.    or leave a particular layer 3 group.
  48.  
  49.    The MARS manages a "cluster" of ATM-attached endpoints.  A "cluster"
  50.    is defined as
  51.  
  52.    "The set of ATM interfaces choosing to participate in direct ATM
  53.    connections to achieve multicasting of AALSDUs between themselves."
  54.  
  55.  
  56.  
  57.  
  58. Talpade & Ammar              Informational                      [Page 1]
  59.  
  60. RFC 2149             Multicast Server Architectures             May 1997
  61.  
  62.  
  63.    In practice, a cluster is the set of endpoints that choose to use the
  64.    same MARS to register their memberships and receive their updates
  65.    from.
  66.  
  67.    A sender in the cluster has two options for multicasting data to the
  68.    group members.  It can either get the list of ATM addresses
  69.    constituting the group from the MARS, set up a point-to-multipoint
  70.    virtual circuit (VC) with the group members as leaves, and then
  71.    proceed to send data out on it.  Alternatively, the source can make
  72.    use of a proxy Multicast Server (MCS).  The source transmits data to
  73.    such an MCS, which in turn uses a point-to-multipoint VC to get the
  74.    data to the group members.
  75.  
  76.    The MCS approach has been briefly introduced in [GA96].  This memo
  77.    presents a detailed description of MCS architecture and proposes a
  78.    simple mechanism for supporting multiple MCSs for fault tolerance.
  79.    We assume an understanding of the IP multicasting over UNI 3.0/3.1
  80.    ATM network concepts described in [GA96], and access to it.  This
  81.    document is organized as follows.  Section 2 presents interactions
  82.    with the local UNI 3.0/3.1 signaling entity that are used later in
  83.    the document and have been originally described in [GA96].  Section 3
  84.    presents an MCS architecture, along with a description of its
  85.    interactions with the MARS. Section 4 describes the working of an
  86.    MCS. The possibility of using multiple MCSs for the same layer 3
  87.    group, and the mechanism needed to support such usage, is described
  88.    in section 5.  A comparison of the VC Mesh approach and the MCS
  89.    approach is presented in Appendix A.
  90.  
  91. 2 Interaction with the local UNI 3.0/3.1 signaling entity
  92.  
  93.    The following generic signaling functions are presumed to be
  94.    available to local AAL Users:
  95.  
  96.    LCALL-RQ - Establish a unicast VC to a specific endpoint.
  97.    LMULTI-RQ - Establish multicast VC to a specific endpoint.
  98.    LMULTI-ADD - Add new leaf node to previously established VC.
  99.    LMULTI-DROP - Remove specific leaf node from established VC.
  100.    LRELEASE - Release unicast VC, or all Leaves of a multicast VC.
  101.  
  102.    The following indications are assumed to be available to AAL Users,
  103.    generated by by the local UNI 3.0/3.1 signaling entity:
  104.  
  105.    LACK - Succesful completion of a local request.
  106.    LREMOTE-CALL - A new VC has been established to the AAL User.
  107.    ERRL-RQFAILED - A remote ATM endpoint rejected an LCALLRQ,
  108.                          LMULTIRQ, or L-MULTIADD.
  109.    ERRL-DROP - A remote ATM endpoint dropped off an existing VC.
  110.    ERRL-RELEASE - An existing VC was terminated.
  111.  
  112.  
  113.  
  114. Talpade & Ammar              Informational                      [Page 2]
  115.  
  116. RFC 2149             Multicast Server Architectures             May 1997
  117.  
  118.  
  119. 3 MCS Architecture
  120.  
  121.    The MCS acts as a proxy server which multicasts data received from a
  122.    source to the group members in the cluster.  All multicast sources
  123.    transmitting to an MCS-based group send the data to the specified
  124.    MCS. The MCS then forwards the data over a point to multipoint VC
  125.    that it maintains to group members in the cluster.  Each multicast
  126.    source thus maintains a single point-to-multipoint VC to the
  127.    designated MCS for the group.  The designated MCS terminates one
  128.    point-to-multipoint VC from each cluster member that is multicasting
  129.    to the layer 3 group.  Each group member is the leaf of the point-
  130.    to-multipoint VC originating from the MCS.
  131.  
  132.    A brief introduction to possible MCS architectures has been presented
  133.    in [GA96].  The main contribution of that document concerning the MCS
  134.    approach is the specification of the MARS interaction with the MCS.
  135.    The next section lists control messages exchanged by the MARS and
  136.    MCS.
  137.  
  138. 3.1 Control Messages exchanged by the MCS and the MARS
  139.  
  140.    The following control messages are exchanged by the MARS and the MCS.
  141.  
  142.    operation code                Control Message
  143.  
  144.          1                       MARS_REQUEST
  145.          2                       MARS_MULTI
  146.          3                       MARS_MSERV
  147.          6                       MARS_NAK
  148.          7                       MARS_UNSERV
  149.          8                       MARS_SJOIN
  150.          9                       MARS_SLEAVE
  151.         12                       MARS_REDIRECT_MAP
  152.  
  153.    MARSMSERV and MARS-UNSERV are identical in format to the MARSJOIN
  154.    message.  MARSSJOIN and MARS-SLEAVE are also identical in format to
  155.    MARSJOIN. As such, their formats and those of MARSREQUEST, MARS-
  156.    MULTI, MARSNAK and MARSREDIRECT-MAP are described in [GA96].  Their
  157.    usage is described in section 4.  All control messages are LLC/SNAP
  158.    encapsulated as described in section 4.2 of [GA96].  (The "mar$"
  159.    notation used in this document is borrowed from [GA96], and indicates
  160.    a specific field in the control message.)  Data messages are
  161.    reflected without any modification by the MCS.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Talpade & Ammar              Informational                      [Page 3]
  171.  
  172. RFC 2149             Multicast Server Architectures             May 1997
  173.  
  174.  
  175. 3.2 Association with a layer 3 group
  176.  
  177.    The simplest MCS architecture involves taking incoming AALSDUs from
  178.    the multicast sources and sending them out over the point-to-
  179.    multipoint VC to the group members.  The MCS can service just one
  180.    layer 3 group using this design, as it has no way of distinguishing
  181.    between traffic destined for different groups.  So each layer 3 MCS-
  182.    supported group will have its own designated MCS.
  183.  
  184.    However it is desirable in the interests of saving resources to
  185.    utilize the same MCS to support multiple groups.  This can be done by
  186.    adding minimal layer 3 specific processing into the MCS. The MCS can
  187.    now look inside the received AALSDUs and determine which layer 3
  188.    group they are destined for.  A single instance of such an MCS could
  189.    register its ATM address with the MARS for multiple layer 3 groups,
  190.    and manage multiple point-to-multipoint VCs, one for each group.
  191.    This capability is included in the MCS architecture, as is the
  192.    capability of having multiple MCSs per group (section 5).
  193.  
  194. 4 Working of MCS
  195.  
  196.    An MCS MUST NOT share its ATM address with any other cluster member
  197.    (MARS or otherwise).  However, it may share the same physical ATM
  198.    interface (even with other MCSs or the MARS), provided that each
  199.    logical entity has a different ATM address.  This section describes
  200.    the working of MCS and its interactions with the MARS and other
  201.    cluster members.
  202.  
  203. 4.1 Usage of MARSMSERV and MARS-UNSERV
  204.  
  205. 4.1.1 Registration (and deregistration) with the MARS
  206.  
  207.    The ATM address of the MARS MUST be known to the MCS by out-of-band
  208.    means at startup.  One possible approach for doing this is for the
  209.    network administrator to specify the MARS address at command line
  210.    while invoking the MCS. On startup, the MCS MUST open a point-to-
  211.    point control VC (MARSVC) with the MARS. All traffic from the MCS to
  212.    the MARS MUST be carried over the MARSVC. The MCS MUST register with
  213.    the MARS using the MARS-MSERV message on startup.  To register, a
  214.    MARSMSERV MUST be sent by the MCS to the MARS over the MARSVC. On
  215.    receiving this MARS-MSERV, the MARS adds the MCS to the
  216.    ServerControlVC. The ServerControlVC is maintained by the MARS with
  217.    all MCSs as leaves, and is used to disseminate general control
  218.    messages to all the MCSs.  The MCS MUST terminate this VC, and MUST
  219.    expect a copy of the MCS registration MARSMSERV on the MARS-VC from
  220.    the MARS.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Talpade & Ammar              Informational                      [Page 4]
  227.  
  228. RFC 2149             Multicast Server Architectures             May 1997
  229.  
  230.  
  231.    An MCS can deregister by sending a MARSUNSERV to the MARS. A copy of
  232.    this MARSUNSERV MUST be expected back from the MARS. The MCS will
  233.    then be dropped from the ServerControlVC.
  234.  
  235.    No protocol specific group addresses are included in MCS registration
  236.    MARSMSERV and MARS-UNSERV. The mar$flags.register bit MUST be set,
  237.    the mar$cmi field MUST be set to zero, the mar$flags.sequence field
  238.    MUST be set to zero, the source ATM address MUST be included and a
  239.    null source protocol address MAY be specified in these MARSMSERV and
  240.    MARS-UNSERV. All other fields are set as described in section 5.2.1
  241.    of [GA96] (the MCS can be considered to be a cluster member while
  242.    reading that section).  It MUST keep retransmitting (section 4.1.3)
  243.    the MARSMSERV/MARS-UNSERV over the MARSVC until it receives a copy
  244.    back.
  245.  
  246.    In case of failure to open the MARSVC, or error on it, the
  247.    reconnection procedure outlined in section 4.5.2 is to be followed.
  248.  
  249. 4.1.2 Registration (and deregistration) of layer 3 groups
  250.  
  251.    The MCS can register with the MARS to support particular group(s).
  252.    To register groups X through Y, a MARSMSERV with a <min, max> pair of
  253.    <X, Y> MUST be sent to the MARS. The MCS MUST expect a copy of the
  254.    MARSMSERV back from the MARS. The retransmission strategy outlined in
  255.    section 4.1.3 is to be followed if no copy is received.
  256.  
  257.    The MCS MUST similarly use MARSUNSERV if it wants to withdraw support
  258.    for a specific layer 3 group.  A copy of the group MARSUNSERV MUST be
  259.    received, failing which the retransmission strategy in section 4.1.3
  260.    is to be followed.
  261.  
  262.    The mar$flags.register bit MUST be reset and the mar$flags.sequence
  263.    field MUST be set to zero in the group MARSMSERV and MARS-UNSERV. All
  264.    other fields are set as described in section 5.2.1 of [GA96] (the MCS
  265.    can be considered to be a cluster member when reading that section).
  266.  
  267. 4.1.3 Retransmission of MARSMSERV and MARS-UNSERV
  268.  
  269.    Transient problems may cause loss of control messages.  The MCS needs
  270.    to retransmit MARSMSERV/MARS-UNSERV at regular intervals when it does
  271.    not receive a copy back from the MARS. This interval should be no
  272.    shorter than 5 seconds, and a default value of 10 seconds is
  273.    recommended.  A maximum of 5 retransmissions are permitted before a
  274.    failure is logged.  This MUST be considered a MARS failure, which
  275.    SHOULD result in the MARS reconnection mechanism described in section
  276.    4.5.2.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Talpade & Ammar              Informational                      [Page 5]
  283.  
  284. RFC 2149             Multicast Server Architectures             May 1997
  285.  
  286.  
  287.    A "copy" is defined as a received message with the following fields
  288.    matching the previously transmitted MARSMSERV/MARS-UNSERV:
  289.  
  290.    -  mar$op
  291.    -  mar$flags.register
  292.    -  mar$pnum
  293.    -  Source ATM address
  294.    -  first <min, max> pair
  295.  
  296.    In addition, a valid copy MUST have the following field values:
  297.  
  298.    -  mar$flags.punched = 0
  299.    -  mar$flags.copy = 1
  300.  
  301.    If either of the above is not true, the message MUST be dropped
  302.    without resetting of the MARSMSERV/MARS-UNSERV timer.  There MUST be
  303.    only one MARSMSERV or MARS-UNSERV outstanding at a time.
  304.  
  305. 4.1.4 Processing of MARSMSERV and MARS-UNSERV
  306.  
  307.    The MARS transmits copies of group MARSMSERV and MARS-UNSERV on the
  308.    ServerControlVC. So they are also received by MCSs other than the
  309.    originating one.  This section discusses the processing of these
  310.    messages by the other MCSs.
  311.  
  312.    If a MARSMSERV is seen that refers to a layer 3 group not supported
  313.    by the MCS, it MUST be used to track the Server Sequence Number
  314.    (section 4.5.1) and then silently dropped.
  315.  
  316.    If a MARSMSERV is seen that refers to a layer 3 group supported by
  317.    the MCS, the MCS learns of the existence of another MCS supporting
  318.    the same group.  This possibility is incorporated (of multiple MCSs
  319.    per group) in this version of the MCS approach and is discussed in
  320.    section 5.
  321.  
  322. 4.2 Usage of MARSREQUEST and MARS-MULTI
  323.  
  324.    As described in section 5.1, the MCS learns at startup whether it is
  325.    an active or inactive MCS. After successful registration with the
  326.    MARS, an MCS which has been designated as inactive for a particular
  327.    group MUST NOT register to support that group with the MARS. It
  328.    instead proceeds as in section 5.4.  The active MCS for a group also
  329.    has to do some special processing, which we describe in that section.
  330.    The rest of section 4 describes the working of a single active MCS,
  331.    with section 5 describing the active MCSs actions for supporting
  332.    multiple MCSs.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Talpade & Ammar              Informational                      [Page 6]
  339.  
  340. RFC 2149             Multicast Server Architectures             May 1997
  341.  
  342.  
  343.    After the active MCS registers to support a layer 3 group, it uses
  344.    MARSREQUEST and MARS-MULTI to obtain information about group
  345.    membership from the MARS. These messages are also used during the
  346.    revalidation phase (section 4.5) and when no outgoing VC exists for a
  347.    received layer 3 packet (section 4.3).
  348.  
  349.    On registering to support a particular layer 3 group, the MCS MUST
  350.    send a MARSREQUEST to the MARS. The mechanism to retrieve group
  351.    membership and the format of MARSREQUEST and MARS-MULTI is described
  352.    in section 5.1.1 and 5.1.2 of [GA96] respectively.  The MCS MUST use
  353.    this mechanism for sending (and retransmitting) the MARSREQUEST and
  354.    processing the returned MARSMULTI(/s).  The MARS-MULTI MUST be
  355.    received correctly, and the MCS MUST use it to initialize its
  356.    knowledge of group membership.
  357.  
  358.    On successful reception of a MARSMULTI, the MCS MUST attempt to open
  359.    the outgoing point-to-multipoint VC using the mechanism described in
  360.    section 5.1.3 of [GA96], if any group members exist.  The MCS however
  361.    MUST start transmitting data on this VC after it has opened it
  362.    successfully with at least one of the group members as a leaf, and
  363.    after it has attempted to add all the group members at least once.
  364.  
  365. 4.3 Usage of outgoing point-to-multipoint VC
  366.  
  367.    Cluster members which are sources for MCS-supported layer 3 groups
  368.    send (encapsulated) layer 3 packets to the designated MCSs.  An MCS,
  369.    on receiving them from cluster members, has to send them out over the
  370.    specific point-to-multipoint VC for that layer 3 group.  This VC is
  371.    setup as described in the previous section.  However, it is possible
  372.    that no group members currently exist, thus causing no VC to be
  373.    setup.  So an MCS may have no outgoing VC to forward received layer 3
  374.    packets on, in which case it MUST initiate the MARSREQUEST and MARS-
  375.    MULTI sequence described in the previous section.  This new MARSMULTI
  376.    could contain new members, whose MARSSJOINs may have been not
  377.    received by the MCS (and the loss not detected due to absence of
  378.    traffic on the ServerControlVC).
  379.  
  380.    If an MCS learns that there are no group members (MARSNAK received
  381.    from MARS), it MUST delay sending out a new MARSREQUEST for that
  382.    group for a period no less than 5 seconds and no more than 10
  383.    seconds.
  384.  
  385.    Layer 3 packets received from cluster members, while no outgoing
  386.    point-to-multipoint VC exists for that group, MUST be silently
  387.    dropped after following the guidelines in the previous paragraphs.
  388.    This might result in some layer 3 packets being lost until the VC is
  389.    setup.
  390.  
  391.  
  392.  
  393.  
  394. Talpade & Ammar              Informational                      [Page 7]
  395.  
  396. RFC 2149             Multicast Server Architectures             May 1997
  397.  
  398.  
  399.    Each outgoing point-to-multipoint VC has a revalidate flag associated
  400.    with it.  This flag MUST be checked whenever a layer 3 packet is sent
  401.    out on that VC. No action is taken if it is not set.  If it is set,
  402.    the packet is sent out, the revalidation procedure (section 4.5.3)
  403.    MUST be initiated for this group, and the flag MUST be reset.
  404.  
  405.    In case of error on a point-to-multipoint VC, the MCS MUST initiate
  406.    revalidation procedures for that VC as described in section 4.5.3.
  407.    Once a point-to-multipoint VC has been setup for a particular layer 3
  408.    group, the MCS MUST hold the VC open and mark it as the outgoing path
  409.    for any subsequent layer 3 packets being sent for that group address.
  410.    A point-to-multipoint VC MUST NOT have an activity timer associated
  411.    with it.  It is to remain up at all times, unless the MCS explicitly
  412.    stops supporting that layer 3 group, or no more leaves exist on the
  413.    VC which causes it to be shut down.  The VC is kept up inspite of
  414.    non-existent traffic to reduce the delay suffered by MCS supported
  415.    groups.  If the VC were to be shut down on absence of traffic, the VC
  416.    reestablishment procedure (needed when new traffic for the layer 3
  417.    group appears) would further increase the initial delay, which can be
  418.    potentially higher than the VC mesh approach anyway as two VCs need
  419.    to be setup in the MCS case (one from source to MCS, second from MCS
  420.    to group) as opposed to only one (from source to group) in the VC
  421.    Mesh approach.  This approach of keeping the VC from the MCS open
  422.    even in the absense of traffic is experimental.  A decision either
  423.    way can only be made after gaining experience (either through
  424.    implementation or simulation) about the implications of keeping the
  425.    VC open.
  426.  
  427.    If the MCS supports multiple layer 3 groups, it MUST follow the
  428.    procedure outlined in the four previous subsections for each group
  429.    that it is an active MCS. Each incoming data AALSDU MUST be examined
  430.    for determining its recipient group, before being forwarded onto the
  431.    appropriate outgoing point-to-multipoint VC.
  432.  
  433. 4.3.1 Group member dropping off a point-to-multipoint VC
  434.  
  435.    AN ERRL-DROP may be received during the lifetime of a point-to-
  436.    multipoint VC indicating that a leaf node has terminated its
  437.    participation at the ATM level.  The ATM endpoint associated with the
  438.    ERRL-DROP MUST be removed from the locally held set associated with
  439.    the VC. The revalidate flag on the VC MUST be set after a random
  440.    interval of 1 through 10 seconds.
  441.  
  442.    If an ERRL-RELEASE is received for a VC, then the entire set is
  443.    cleared and the VC considered to be completely shutdown.  A new VC
  444.    for this layer 3 group will be established only on reception of new
  445.    traffic for the group (as described in section 4.3).
  446.  
  447.  
  448.  
  449.  
  450. Talpade & Ammar              Informational                      [Page 8]
  451.  
  452. RFC 2149             Multicast Server Architectures             May 1997
  453.  
  454.  
  455. 4.4 Processing of MARSSJOIN and MARS-SLEAVE
  456.  
  457.    The MARS transmits equivalent MARSSJOIN/MARS-SLEAVE on the
  458.    ServerControlVC when it receives MARSJOIN/MARS-LEAVE from cluster
  459.    members.  The MCSs keep track of group membership updates through
  460.    these messages.  The format of these messages are identical to
  461.    MARSJOIN and MARS-LEAVE, which are described in section 5.2.1 of
  462.    [GA96].  It is sufficient to note here that these messages carry the
  463.    ATM address of the node joining/leaving the group(/s), the group(/s)
  464.    being joined or left, and a Server Sequence Number from MARS.
  465.  
  466.    When a MARSSJOIN is seen which refers to (or encompasses) a layer 3
  467.    group (or groups) supported by the MCS, the following action MUST be
  468.    taken.  The new member's ATM address is extracted from the MARSSJOIN.
  469.    An L-MULTIADD is issued for the new member for each of those referred
  470.    groups which have an outgoing point-to-multipoint VC. An LMULTI-RQ is
  471.    issued for the new member for each of those refered groups which have
  472.    no outgoing VCs.
  473.  
  474.    When a MARSSLEAVE is seen that refers to (or encompasses) a layer 3
  475.    group (or groups) supported by the MCS, the following action MUST be
  476.    taken.  The leaving member's ATM address is extracted.  An LMULTI-
  477.    DROP is issued for the member for each of the refered groups which
  478.    have an outgoing point-to-multipoint VC.
  479.  
  480.    There is a possibility of the above requests (LMULTI-RQ or LMULTIADD
  481.    or LMULTI-DROP) failing.  The UNI 3.0/3.1 failure cause must be
  482.    returned in the ERRL-RQFAILED signal from the local signaling entity
  483.    to the AAL User.  If the failure cause is not 49 (Quality of Service
  484.    unavailable), 51 (user cell rate not available - UNI 3.0), 37 (user
  485.    cell rate not available - UNI 3.1), or 41 (Temporary failure), the
  486.    endpoint's ATM address is dropped from the locally held view of the
  487.    group by the MCS. Otherwise, the request MUST be re-attempted with
  488.    increasing delay (initial value between 5 to 10 seconds, with delay
  489.    value doubling after each attempt) until it either succeeds or the
  490.    multipoint VC is released or a MARSSLEAVE is received for that group
  491.    member.  If the VC is open, traffic on the VC MUST continue during
  492.    these attempts.
  493.  
  494.    MARSSJOIN and MARS-SLEAVE are processed differently if multiple MCSs
  495.    share the members of the same layer 3 group (section 5.4).  MARSSJOIN
  496.    and MARSSLEAVE that do not refer to (or encompass) supported groups
  497.    MUST be used to track the Server Sequence Number (section 4.5.1), but
  498.    are otherwise ignored.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Talpade & Ammar              Informational                      [Page 9]
  507.  
  508. RFC 2149             Multicast Server Architectures             May 1997
  509.  
  510.  
  511. 4.5 Revalidation Procedures
  512.  
  513.    The MCS has to initiate revalidation procedures in case of certain
  514.    failures or errors.
  515.  
  516. 4.5.1 Server Sequence Number
  517.  
  518.    The MCS needs to track the Server Sequence Number (SSN) in the
  519.    messages received on the ServerControlVC from the MARS. It is carried
  520.    in the mar$msn of all messages (except MARSNAK) sent by the MARS to
  521.    MCSs.  A jump in SSN implies that the MCS missed the previous
  522.    message(/s) sent by the MARS. The MCS then sets the revalidate flag
  523.    on all outgoing point-to-multipoint VCs after a random delay of
  524.    between 1 and 10 seconds, to avoid all MCSs inundating the MARS
  525.    simultaneously in case of a more general failure.
  526.  
  527.    The only exception to the rule is if a sequence number is detected
  528.    during the establishment of a new group's VC (i.e.  a MARSMULTI was
  529.    correctly received, but its mar$msn indicated that some previous MARS
  530.    traffic had been missed on ClusterControlVC). In this case every open
  531.    VC, EXCEPT the one just being established, MUST have its revalidate
  532.    flag set at some random interval between 1 and 10 seconds from the
  533.    time the jump in SSN was detected.  (The VC being established is
  534.    considered already validated in this case).
  535.  
  536.    Each MCS keeps its own 32 bit MCS Sequence Number (MSN) to track the
  537.    SSN.  Whenever a message is received that carries a mar$msn field,
  538.    the following processing is performed:
  539.  
  540.         Seq.diff = mar$msn - MSN
  541.  
  542.         mar$msn -> MSN
  543.  
  544.         (.... process MARS message ....)
  545.  
  546.         if ((Seq.diff != 1) && (Seq.diff != 0))
  547.               then (.... revalidate group membership information ....)
  548.  
  549.    The mar$msn value in an individual MARSMULTI is not used to update
  550.    the MSN until all parts of the MARSMULTI (if > 1) have arrived.  (If
  551.    the mar$msn changes during reception of a MARSMULTI series, the
  552.    MARS-MULTI is discarded as described in section 5.1.1 of [GA96]).
  553.  
  554.    The MCS sets its MSN to zero on startup.  It gets the current value
  555.    of SSN when it receives the copy of the registration MARSMSERV back
  556.    from the MARS.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Talpade & Ammar              Informational                     [Page 10]
  563.  
  564. RFC 2149             Multicast Server Architectures             May 1997
  565.  
  566.  
  567. 4.5.2 Reconnecting to the MARS
  568.  
  569.    The MCSs are assumed to have been configured with the ATM address of
  570.    at least one MARS at startup.  MCSs MAY choose to maintain a table of
  571.    ATM addresses, each address representing alternative MARS which will
  572.    be contacted in case of failure of the previous one.  This table is
  573.    assumed to be ordered in descending order of preference.
  574.  
  575.    An MCS will decide that it has problems communicating with a MARS if:
  576.  
  577.       * It fails to establish a point-to-point VC with the MARS.
  578.  
  579.       * MARSREQUEST generates no response (no MARSMULTI or MARS-NAK
  580.       returned).
  581.  
  582.       * ServerControlVC fails.
  583.  
  584.       * MARSMSERV or MARSUNSERV do not result in their respective copies
  585.       being
  586.         received.
  587.  
  588.    (reconnection as in section 5.4 in [GA96], with MCS-specific actions
  589.    used where needed).
  590.  
  591. 4.5.3 Revalidating a point-to-multipoint VC
  592.  
  593.    The revalidation flag associated with a point-to-multipoint VC is
  594.    checked when a layer 3 packet is to be sent out on the VC.
  595.    Revalidation procedures MUST be initiated for a point-to-multipoint
  596.    VC that has its revalidate flag set when a layer 3 packet is being
  597.    sent out on it.  Thus more active groups get revalidated faster than
  598.    less active ones.  The revalidation process MUST NOT result in
  599.    disruption of normal traffic on the VC being revalidated.
  600.  
  601.    The revalidation procedure is as follows.  The MCS reissues a
  602.    MARSREQUEST for the VC being revalidated.  The returned set of
  603.    members is compared with the locally held set; LMULTI-ADDs MUST be
  604.    issued for new members, and LMULTI-DROPs MUST be issued for non-
  605.    existent ones.  The revalidate flag MUST be reset for the VC.
  606.  
  607. 5 Multiple MCSs for a layer 3 group
  608.  
  609.    Having a single MCS for a layer 3 group can cause it to become a
  610.    single point of failure and a bottleneck for groups with large
  611.    numbers of active senders.  It is thus desirable to introduce a level
  612.    of fault tolerance by having multiple MCS per group.  Support for
  613.    load sharing is not introduced in this document as to reduce the
  614.    complexity of the protocol.
  615.  
  616.  
  617.  
  618. Talpade & Ammar              Informational                     [Page 11]
  619.  
  620. RFC 2149             Multicast Server Architectures             May 1997
  621.  
  622.  
  623. 5.1 Outline
  624.  
  625.    The protocol described in this document offers fault tolerance by
  626.    using multiple MCSs for the same group.  This is achieved by having a
  627.    standby MCS take over from a failed MCS which had been supporting the
  628.    group.  The MCS currently supporting a group is refered to as the
  629.    active MCS, while the one or more standby MCSs are refered to as
  630.    inactive MCSs.  There is only one active MCS existing at any given
  631.    instant for an MCS-supported group.  The protocol makes use of the
  632.    HELLO messages as described in [LA96].
  633.  
  634.    To reduce the complexity of the protocol, the following operational
  635.    guidelines need to be followed.  These guidelines need to be enforced
  636.    by out-of-band means which are not specified in this document and can
  637.    be implementation dependent.
  638.  
  639.       * The set of (one or more) MCSs ("mcslist") that support a
  640.         particular IP Multicast group is predetermined and fixed.  This
  641.         set MUST be known to each MCS in the set at startup, and the
  642.         ordering of MCSs in the set is the same for all MCSs in the set.
  643.         An implementation of this would be to maintain the set of ATM
  644.         addresses of the MCSs in a file, an identical copy of which is
  645.         kept at each MCS in the set.
  646.  
  647.       * All MCSs in "mcslist" have to be started up together, with the
  648.         first MCS in "mcslist" being the last to be started.
  649.  
  650.       * A failed MCS cannot be started up again.
  651.  
  652. 5.2 Discussion of Multiple MCSs in operation
  653.  
  654.    An MCS on startup determines its position in the "mcslist".  If the
  655.    MCS is not the first in "mcslist", it does not register for
  656.    supporting the group with the MARS. If the MCS is first in the set,
  657.    it does register to support the group.
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Talpade & Ammar              Informational                     [Page 12]
  675.  
  676. RFC 2149             Multicast Server Architectures             May 1997
  677.  
  678.  
  679.    The first MCS thus becomes the active MCS and supports the group as
  680.    described in section 4.  The active MCS also opens a point-to-
  681.    multipoint VC (HelloVC) to the remaining MCSs in the set (the
  682.    inactive MCSs).  It starts sending HELLO messages on this VC at a
  683.    fixed interval (HelloInterval seconds).  The inactive MCSs maintain a
  684.    timer to keep track of the last received HELLO message.  If an
  685.    inactive MCS does not receive a message within HelloInterval*
  686.    DeadFactor seconds (values of HelloInterval and DeadFactor are the
  687.    same at all the MCSs), or if the HelloVC is closed, it assumes
  688.    failure of the active MCS and attempts to elect a new one.  The
  689.    election process is described in section 5.5.
  690.  
  691.    If an MCS is elected as the new active one, it registers to support
  692.    the group with the MARS. It also initiates the transmission of HELLO
  693.    messages to the remaining inactive MCSs.
  694.  
  695. 5.3 Inter-MCS control messages
  696.  
  697.    The protocol uses HELLO messages in the heartbeat mechanism, and also
  698.    during the election process.  The format of the HELLO message is
  699.    based on that described in [LA96].  The Hello message type code is 5.
  700.  
  701.     0                   1                   2                   3
  702.     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
  703.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  704.    | Sender Len    |    Recvr Len  | State | Type  |    unused     |
  705.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  706.    |         HelloInterval         |          DeadFactor           |
  707.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  708.    |                        IP Multicast address                   |
  709.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  710.    |                    Sender ATM address (variable length)       |
  711.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  712.    |                  Receiver ATM address (variable length)       |
  713.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  714.  
  715.    Sender Len
  716.      This field holds the length in octets of the Sender ATM address.
  717.  
  718.    Recvr Len
  719.      This field holds the length in octets of the Receiver ATM
  720.      address.
  721.  
  722.    State
  723.      Currently two states: No-Op (0x00) and Elected (0x01).
  724.      It is used by a candidate MCS to indicate if it was successfully
  725.      elected.
  726.  
  727.  
  728.  
  729.  
  730. Talpade & Ammar              Informational                     [Page 13]
  731.  
  732. RFC 2149             Multicast Server Architectures             May 1997
  733.  
  734.  
  735.    Type
  736.      This is the code for the message type.
  737.  
  738.    HelloInterval
  739.      The hello interval advertises the time between sending of
  740.      consecutive Hello Messages by an active MCS.  If the time between
  741.      Hello messages exceeds the HelloInterval then the Hello is to be
  742.      considered late by the inactive MCS.
  743.  
  744.    DeadFactor
  745.      This is a multiplier to the HelloInterval. If an inactive MCS
  746.      does not receive a Hello message within the interval
  747.      HelloInterval*DeadFactor from an active MCS that advertised
  748.      the HelloInterval then the inactive MCS MUST consider the active
  749.      one to have failed.
  750.  
  751.    IP Multicast address
  752.      This field is used to indicate the group to associate the HELLO
  753.      message with. It is useful if MCSs can support more than one
  754.      group.
  755.  
  756.    Sender ATM address
  757.      This is the protocol address of the server which is sending the
  758.      Hello.
  759.  
  760.    Receiver ATM address
  761.      This is the protocol address of the server which is to Reply to
  762.      the Hello.  If the sender does not know this address then the
  763.      sender sets it to zero. (This happens in the HELLO messages sent
  764.      from the active MCS to the inactive ones, as they are multicast
  765.      and not sent to one specific receiver).
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Talpade & Ammar              Informational                     [Page 14]
  787.  
  788. RFC 2149             Multicast Server Architectures             May 1997
  789.  
  790.  
  791. 5.4 The Multiple MCS protocol
  792.  
  793.    As is indicated in section 5.1, all the MCSs supporting the same IP
  794.    Multicast group MUST be started up together.  The set of MCSs
  795.    ("mcslist") MUST be specified to each MCS in the set at startup.
  796.    After registering to support the group with the MARS, the first MCS
  797.    in the set MUST open a point-to-multipoint VC (HelloVC) with the
  798.    remaining MCSs in the "mcslist" as leaves, and thus assumes the role
  799.    of active MCS. It MUST send HELLO messages HelloInterval seconds
  800.    apart on this VC. The Hello message sent by the active MCS MUST have
  801.    the Receiver Len set to zero, the State field set to "Elected", with
  802.    the other fields appropriately set.  The Receiver ATM address field
  803.    does not exist in this HELLO message.  The initial value of
  804.    HelloInterval and DeadFactor MUST be the same at all MCSs at startup.
  805.    The active MCS can choose to change these values by introducing the
  806.    new value in the HELLO messages that are sent out.  The active MCS
  807.    MUST support the group as described in section 4.
  808.  
  809.    The other MCSs in "mcslist" determine the identity of the first MCS
  810.    from the "mcslist".  They MUST NOT register to support the group with
  811.    the MARS, and become inactive MCSs.  On startup, an inactive MCS
  812.    expects HELLO messages from the active MCS. The inactive MCS MUST
  813.    terminate the HelloVC.  A timer MUST be maintained, and if the
  814.    inactive MCS does not receive HELLO message from the active one
  815.    within a period HelloInterval*DeadFactor seconds, it assumes that the
  816.    active MCS died, and initiates the election process as described in
  817.    section 5.5.  If a HELLO message is received within this period, the
  818.    inactive MCS does not initiate any further action, other than
  819.    restarting the timer.  The inactive MCSs MUST set their values of
  820.    HelloInterval and DeadFactor to those specified by the active MCS in
  821.    the HELLO messages.
  822.  
  823.    In case of an MCS supporting multiple groups, it MUST register to
  824.    support those groups for which it is the first MCS, and MUST NOT
  825.    register for other groups.  A MARSMSERV with multiple <min, max>
  826.    pairs may be used for registering multiple disjoint sets of groups.
  827.    Support MUST be provided for the use of a single "mcslist" for more
  828.    than one group.  This is intended to address the case wherein an MCS
  829.    is intended to support multiple groups, with other MCSs acting as
  830.    backups.  This subverts the need for using a different "mcslist" for
  831.    each group being supported by the same set of MCSs.
  832.  
  833.    On failure of the active MCS, a new MCS assumes its role as described
  834.    in section 5.5.  In this case, the remaining inactive MCSs will
  835.    expect HELLO messages from this new active MCS as described in the
  836.    previous paragraph.
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Talpade & Ammar              Informational                     [Page 15]
  843.  
  844. RFC 2149             Multicast Server Architectures             May 1997
  845.  
  846.  
  847. 5.5 Failure handling
  848.  
  849. 5.5.1 Failure of active MCS
  850.  
  851.    The failure of the active MCS is detected by the inactive MCSs if no
  852.    HELLO message is received within an interval of
  853.    HelloInterval*DeadFactor seconds, or if the HelloVC is closed.  In
  854.    this case the next MCS in "mcslist" becomes the candidate MCS. It
  855.    MUST open a point-to-multipoint VC to the remaining inactive MCSs
  856.    (HelloVC) and send a HELLO message on it with the State field set to
  857.    No-Op.  The rest of the message is formatted as described earlier.
  858.  
  859.    On receiving a HELLO message from a candidate MCS, an inactive MCS
  860.    MUST open a point-to-point VC to that candidate.  It MUST send a
  861.    HELLO message back to it, with the Sender and Receiver fields
  862.    appropriately set (not zero), and the State field being No-Op.  If a
  863.    HELLO message is received by an inactive MCS from a non-candidate
  864.    MCS, it is ignored.  If no HELLO message is received from the
  865.    candidate with the State field set to "Elected" in HelloInterval
  866.    seconds, the inactive MCS MUST retransmit the HELLO. If no HELLO
  867.    message with State field set to "Elected" is received by the inactive
  868.    MCSs within an interval of HelloInterval*DeadFactor seconds, the next
  869.    MCS in "mcslist" is considered as the candidate MCS. Note that the
  870.    values used for HelloInterval and DeadFactor in the election phase
  871.    are the default ones.
  872.  
  873.    The candidate MCS MUST wait for a period of HelloInterval*DeadFactor
  874.    seconds for receiving HELLO messages from inactive MCSs.  It MUST
  875.    transmit HELLO messages with State field set to No-Op at
  876.    HelloInterval seconds interval during this period.  If it receives
  877.    messages from atleast half of the remaining inactive MCSs during this
  878.    period, it considers itself elected and assumes the active MCS role.
  879.    It then registers to support the group with the MARS, and starts
  880.    sending HELLO messages at HelloInterval second intervals with State
  881.    field set to "Elected" on the already existing HelloVC. The active
  882.    MCS can then alter the HelloInterval and DeadFactor values if
  883.    desired, and communicate the same to the inactive MCSs in the HELLO
  884.    message.
  885.  
  886. 5.5.2 Failure of inactive MCS
  887.  
  888.    If an inactive MCS drops off the HelloVC, the active MCS MUST attempt
  889.    to add that MCS back to the VC for three attempts, spaced
  890.    HelloInterval*DeadFactor seconds apart.  If even the third attempt
  891.    fails, the inactive MCS is considered dead.
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Talpade & Ammar              Informational                     [Page 16]
  899.  
  900. RFC 2149             Multicast Server Architectures             May 1997
  901.  
  902.  
  903.    An MCS, active or inactive, MUST NOT be started up once it has
  904.    failed.  Failed MCSs can only be started up by manual intervention
  905.    after shutting down all the MCSs, and restarting them together.
  906.  
  907. 5.6 Compatibility with future MARS and MCS versions
  908.  
  909.    Future versions of MCSs can be expected to use an enhanced MARS for
  910.    load sharing and fault tolerance ([TA96]).  The MCS architecture
  911.    described in this document is compatible with the enhanced MARS and
  912.    the future MCS versions.  This is because the active MCS is the only
  913.    one which communicates with the MARS about the group.  Hence the
  914.    active MCS will only be informed by the enhanced MARS about the
  915.    subset of the group that it is to support.  Thus MCSs conforming to
  916.    this document are compatible with [GA96] based MARS, as well as
  917.    enhanced MARS.
  918.  
  919. 6 Summary
  920.  
  921.    This document describes the architecture of an MCS. It also provides
  922.    a mechanism for using multiple MCSs per group for providing fault
  923.    tolerance.  This approach can be used with [GA96] based MARS server
  924.    and clients, without needing any change in their functionality.  It
  925.    uses the HELLO packet format as described in [LA96] for the heartbeat
  926.    messages.
  927.  
  928. 7 Acknowledgements
  929.  
  930.    We would like to acknowledge Grenville Armitage (Bellcore) for
  931.    reviewing the document and suggesting improvements towards
  932.    simplifying the multiple MCS functionalities.  Discussion with Joel
  933.    Halpern (Newbridge) helped clarify the multiple MCS problem.  Anthony
  934.    Gallo (IBM RTP) pointed out security issues that are not adequately
  935.    addressed in the current document.  Arvind Murching (Microsoft)
  936.    flagged a potential show stopper in section 4.1.2.
  937.  
  938. 8 Authors' Address
  939.  
  940.    Rajesh Talpade
  941.    College of Computing
  942.    Georgia Institute of Technology
  943.    Atlanta, GA 30332-0280
  944.  
  945.    Phone: (404)-894-6737
  946.    Email: taddy@cc.gatech.edu
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Talpade & Ammar              Informational                     [Page 17]
  955.  
  956. RFC 2149             Multicast Server Architectures             May 1997
  957.  
  958.  
  959.    Mostafa H. Ammar
  960.    College of Computing
  961.    Georgia Institute of Technology
  962.    Atlanta, GA 30332-0280
  963.  
  964.    Phone: (404)-894-3292
  965.    Email:  ammar@cc.gatech.edu
  966.  
  967. 9 References
  968.  
  969. [GA96]   Armitage, G.J., "Support for Multicast over UNI 3.0/3.1 based
  970.          ATM networks", RFC 2022, November 1996.
  971.  
  972. [BK95]   Birman, A., Kandlur, D., Rubas, J., "An extension to the MARS
  973.          model", Work in Progress.
  974.  
  975. [LM93]   Laubach, M., "Classical IP and ARP over ATM", RFC1577,
  976.          Hewlett-Packard Laboratories, December 1993.
  977.  
  978. [LA96]   Luciani, J., G. Armitage, and J. Halpern, "Server Cache
  979.          Synchronization Protocol (SCSP) - NBMA", Work in Progress.
  980.  
  981. [TA96]   Talpade, R., and Ammar, M.H., "Multiple MCS support using an
  982.          enhanced version of the MARS server.", Work in Progress.
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Talpade & Ammar              Informational                     [Page 18]
  1011.  
  1012.