home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2443.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  41.5 KB  |  1,012 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         J. Luciani
  8. Request for Comments: 2443                                  Bay Networks
  9. Category: Experimental                                          A. Gallo
  10.                                                                      IBM
  11.                                                            November 1998
  12.  
  13.  
  14.                  A Distributed MARS Service Using SCSP
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Copyright Notice
  25.  
  26.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  27.  
  28. Abstract
  29.  
  30.    This document describes a method for distributing a MARS service
  31.    within a LIS[1].  This method uses the Server Cache Synchronization
  32.    Protocol (SCSP)[2] to synchronize the MARS Server databases within a
  33.    LIS.  When SCSP is used to synchronize the caches of MARS Servers in
  34.    a LIS, the LIS defines the boundary of an SCSP Server Group (SG).
  35.  
  36. 1. Introduction
  37.  
  38.    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
  39.    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
  40.    document, are to be interpreted as described in [5].
  41.  
  42.    The MARS is an extended analog of the ATMARP Server introduced in
  43.    [4]. It provides the necessary connection and addressing services
  44.    required by layer 3 multicast services over ATM. There are three
  45.    basic elements to the MARS model. First, the MARS Server which
  46.    manages and distributes layer 3 group membership information to the
  47.    LIS. Second, MARS Clients which register with and query a single MARS
  48.    Server for layer 3 multicast information. Third, MCS Clients which
  49.    register with a single MARS Server and provide layer 3 multicast
  50.    forwarding services for a LIS.
  51.  
  52.    Both MARS Clients and MCS Clients explicitly register with the MARS
  53.    Server before exchanging layer 3 multicast information. During the
  54.    registration process MARS Clients are place on the Cluster Control VC
  55.  
  56.  
  57.  
  58. Luciani & Gallo               Experimental                      [Page 1]
  59.  
  60. RFC 2443                MARS Service Using SCSP            November 1998
  61.  
  62.  
  63.    (CCVC) and MCS Clients are placed on the Server Control VC (SCVC).
  64.    Both the CCVC and SCVC are then used to propagate layer 3 multicast
  65.    updates to the clients which make up a LIS. During the registration
  66.    process MARS Clients are also assigned a unique Cluster Member ID
  67.    (CMI) which is used to identify reflected packets in the presence of
  68.    MCS Clients.
  69.  
  70.    In the Distributed MARS Model there MAY be multiple MARS Servers in a
  71.    given LIS, and since any MARS Server within the LIS MUST be able to
  72.    provide layer 3 multicast information about any multicast group
  73.    within the LIS, there MUST be a method by which to synchronize
  74.    multicast information across all MARS Servers within the LIS.
  75.  
  76.    The Server Cache Synchronization Protocol (SCSP) solves the
  77.    generalized server synchronization/cache-replication problem for
  78.    distributed databases, and thus SCSP MAY be applied to the MARS
  79.    Server database synchronization problem within a LIS. When SCSP is
  80.    used to synchronize the caches of MARS Servers in a LIS, the LIS
  81.    defines the boundary of and SCSP Server Group (SG).
  82.  
  83.    SCSP is defined in two parts: the protocol independent part and the
  84.    client/server protocol specific part. The protocol independent part
  85.    is specified in [2] whereas this document will specify the
  86.    client/server protocol specific part where the MARS Server is the
  87.    client/server protocol.
  88.  
  89. 2. Overview
  90.  
  91.    All MARS Servers belonging to a LIS are said to belong to a Server
  92.    Group (SG).  A SG is identified by, not surprisingly, its SGID which
  93.    is contained in a field in all SCSP packets. All SCSP packets contain
  94.    a Protocol ID (PID) field as well. This PID field is set to 0x0003 to
  95.    signify that SCSP is synchronizing MARS Server databases as opposed
  96.    to synchronizing some other protocol's databases. (see Section
  97.    B.2.0.1 of [2] for more details).  In general, PIDs for SCSP will be
  98.    assigned by IANA upon request given that a client/server protocol
  99.    specific specification has been written. In the case of MARS Servers,
  100.    the client/server protocol specific specification was written at the
  101.    same time as SCSP, and thus a PID=0x0003 was assigned in [2].
  102.  
  103.    SCSP places no topological requirements upon a MARS Server SG.
  104.    Obviously, however, the resultant graph of MARS Servers must span the
  105.    set of MARS Servers being synchronized. For more information about
  106.    the client/server protocol independent part of SCSP, the reader is
  107.    encouraged to see [2].
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Luciani & Gallo               Experimental                      [Page 2]
  115.  
  116. RFC 2443                MARS Service Using SCSP            November 1998
  117.  
  118.  
  119.    When a SG is using SCSP for synchronization, a MARS Client or MCS
  120.    Client will register with only one MARS Server although it is allowed
  121.    to choose any MARS Server in the SG for this registration. At
  122.    registration time the MARS Client or MCS Client will be added to that
  123.    MARS Servers respective CCVC or SCVC. Also, MARS Clients will be
  124.    issued a unique CMI for the entire LIS. This document assumes at a
  125.    minimum each MARS Server in the SG will be configured with a unique
  126.    range of CMIs to assign to clients registering with that MARS Server.
  127.    Use of some external means for allocating CMIs to MARS Servers in a
  128.    SG is possible but beyond the scope of this document.
  129.  
  130.    When a MARS Client or MCS Client successfully registers with a MARS
  131.    Server in the SG that MARS Server will propagate the registration
  132.    information to its peer MARS Servers. The same propagation will occur
  133.    for any subsequent group membership information learned from the
  134.    clients. The peer MARS Server will then update its group membership
  135.    database and propagate the information out its own CCVC or SCVC if
  136.    needed.
  137.  
  138.    In the case of a MARS Server failure all peer MARS Servers in the SG
  139.    MUST flush the client/group membership information learned from the
  140.    failed MARS Server. The clients belonging to the failed MARS Servers
  141.    CCVC and SCVC will migrate to the next available MARS Server as
  142.    specified in Section 5.3 of [1]. When a client detects a failure of
  143.    its MARS, it steps to the next backup MARS Server and attempts to
  144.    register with the server. If the registration is successful the
  145.    client will re-join all of its previous group membership information.
  146.    If the registration fails, the process repeats until a functional
  147.    MARS Server is found.
  148.  
  149.    Determining the operational state of a MARS Servers in a SG requires
  150.    that each MARS Server send out an "alive" or "heartbeat" message
  151.    similar to the MARS Redirect message sent out on the CCVC or SCVC for
  152.    MARS Clients. However, this message will only be sent to MARS Servers
  153.    in the SG and is from here on defined as the MARS Server Redirect
  154.    Entry.
  155.  
  156.    In order to detect that a MARS Server failure has occurred each
  157.    server MUST update it's MARS Server Redirect Entry state at least
  158.    every 2 minutes, it is RECOMMENDED that it is updated every 1 minute.
  159.    Failure to receive two consecutive MARS Server Redirect Entry updates
  160.    from a given MARS Server in the SG will cause all membership
  161.    information learned from this server to be flushed. The MARS Server
  162.    Redirect Entry state is also used to create the MARS_REDIRECT_MAP
  163.    messages sent out on CCVC for each MARS Server in the SG. The
  164.    ordering of each server learned will be based on the MARS Servers
  165.    SCSP Sender ID. The ordering of the MARS_REDIRECT_MAP will first
  166.  
  167.  
  168.  
  169.  
  170. Luciani & Gallo               Experimental                      [Page 3]
  171.  
  172. RFC 2443                MARS Service Using SCSP            November 1998
  173.  
  174.  
  175.    contain the list of MARS Servers learned via MARS Server Redirect
  176.    Entry updates in ascending order based on the SCSP Sender ID,
  177.    followed by any externally configured or learned backup MARS Servers.
  178.  
  179.    In the case of a MARS Client or MCS Client failure where the client
  180.    is unexpectedly removed from the CCVC or SCVC the MARS Server MUST
  181.    notify its peer SG members via a proxy deregister for that client.
  182.    Upon receiving a proxy deregister request from a peer SG member all
  183.    membership information for the deregistering client MUST be removed.
  184.    Any Clients sending multicast data to the failed client should also
  185.    receive an unexpected removal of this client which will intern cause
  186.    the sending client to revalidate the multicast groups current
  187.    membership as outlined in Section 5.1.5.1 of [1].
  188.  
  189. 3.  Format of the CSA Record MARS Specific Part
  190.  
  191.    CSA Records in SCSP contain a "Client/Server Protocol Specific Part"
  192.    which contains the non-protocol independent information for a given
  193.    server's cache entry.
  194.  
  195.    0                   1                   2                   3
  196.    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
  197.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  198.    |        Hardware Type          |        Protocol Type          |
  199.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  200.    |                              SNAP                             |
  201.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.    |     SNAP      |   Unused      |    Version    |   State       |
  203.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  204.    |            Flags              |       Cluster Member ID       |
  205.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  206.    | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
  207.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  208.    |     Source Protocol Address             (variable length)     |
  209.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  210.    |     Source ATM Address                  (variable length)     |
  211.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  212.    |     Source ATM SubAddress               (variable length)     |
  213.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  214.    |     Minimum Multicast Group Address     (variable length)     |
  215.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  216.    |     Maximum Multicast Group Address     (variable length)     |
  217.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  218.  
  219.    Hardware Type
  220.      Defines the type of "link layer" addresses being carried.  This
  221.      value is the ATM Forum 'address family number' specified in [3] as
  222.      15 decimal (0x000F).  This is the mar$afn field defined in [1].
  223.  
  224.  
  225.  
  226. Luciani & Gallo               Experimental                      [Page 4]
  227.  
  228. RFC 2443                MARS Service Using SCSP            November 1998
  229.  
  230.  
  231.    Protocol Type
  232.      This field is the protocol type number for the protocol using MARS
  233.      from [3].  (IPv4 is 0x0800).  This is the mar$pro.type field from
  234.      [1].
  235.  
  236.    Protocol SNAP
  237.      This field is the optional protocol SNAP extension to protocol
  238.      type. This is the mar$pro.snap field from [1].
  239.  
  240.    Version Number
  241.      0                    MARS Specific part of the CSA record.
  242.      0x01                 Reserved for NHRP.
  243.      0x02 - 0xEF          Reserved for future use by the IETF.
  244.      0xF0 - 0xFE          Allocated for use by the ATM Forum.
  245.      0xFF                 Experimental/Local use.
  246.      Version Number for this document MUST be set to 0x00.
  247.  
  248.    State
  249.      1   MARS Server Redirect Entry.
  250.      2   MCS Serve/Register request.
  251.      3   MARS Client Join/Register request.
  252.      4   MARS Client Leave/Deregister request.
  253.      5   MCS Unserve/Deregister request.
  254.  
  255.      All other State values should cause the CSA to be discarded.
  256.  
  257.    Flags
  258.      The flags field is used to contain several flags and is similar to
  259.      the mar$flags field from [1].
  260.        mar$flags
  261.           Bit 15   - mar$flags.layer3grp
  262.           Bit 13   - mar$flags.register
  263.           Bit 0-7  - mar$flags.sequence
  264.  
  265.        All remaining bits are reserved and MUST be zero. The
  266.        mars$flags.sequence field is of local significance only to the
  267.        Local Server (LS).
  268.  
  269.    Cluster Member CMI
  270.      This field contains the CMI which uniquely identifies each endpoint
  271.      within a LIS. This is the mar$cmi field from [1].
  272.  
  273.    Src Addr Len
  274.      This field contains the length of the Source Protocol Address
  275.      field.  For IPv4, the value is 4 if an address is specified. A null
  276.      (non-existent) address MUST be coded as zero length, and no space
  277.      allocated for it in the message body.  This is the mar$spln field
  278.      from [1].
  279.  
  280.  
  281.  
  282. Luciani & Gallo               Experimental                      [Page 5]
  283.  
  284. RFC 2443                MARS Service Using SCSP            November 1998
  285.  
  286.  
  287.    Group Addr Len
  288.      This field contains the length of the Group Protocol Address field.
  289.      For IPv4, the value is 4 if an address is specified. A null (non-
  290.      existent) address MUST be coded as zero length, and no space
  291.      allocated for it in the message body.  This is the mar$tpln field
  292.      from [1].
  293.  
  294.    ATM Addr T/L
  295.      This field contains the type and length of the Source ATM Address
  296.      field.  The type and length encoding is described in Section 5.1.2
  297.      of [1].
  298.  
  299.    ATM SubAddr T/L
  300.      This field contains the type and length of the Source ATM
  301.      SubAddress field.  The type and length encoding is described in
  302.      Section 5.1.2 of [1].
  303.  
  304.    Source Protocol Address
  305.      This is the internetwork address for the source of an address
  306.      binding in a MARS server cache entry. If null, no storage will be
  307.      allocated.  This is the mar$spa field from [1].
  308.  
  309.    Source ATM Address
  310.      This is the Source's ATM address of an address binding in a MARS
  311.      server cache entry.  The address, if specified, is E.164 or ATM
  312.      Forum NSAPA. This is the mar$sha field from [1].
  313.  
  314.    Source ATM SubAddress
  315.      This is the Source's ATM subaddress of an address binding in a MARS
  316.      server cache entry.  The subaddress, if specified, is an ATM Forum
  317.      NSAPA.  If null, no storage will be allocated. This is the mar$ssa
  318.      field from [1].
  319.  
  320.    Minimum Multicast Group Address
  321.      This is the internetwork address of the lower bound on the range of
  322.      multicast group addresses for the address binding in a MARS server
  323.      cache entry. If null, no storage will be allocated. This is the
  324.      mar$min.N field from [1].
  325.  
  326.    Maximum Multicast Group Address
  327.      This is the internetwork address of the upper bound on the range of
  328.      multicast group addresses for the address binding in a MARS server
  329.      cache entry. If null, no storage will be allocated. This is the
  330.      mar$max.N field from [1].
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Luciani & Gallo               Experimental                      [Page 6]
  339.  
  340. RFC 2443                MARS Service Using SCSP            November 1998
  341.  
  342.  
  343. 4.  Values for SCSP Protocol Independent Part
  344.  
  345.    The following sections give values for fields of the SCSP Protocol
  346.    Independent Part of the various SCSP messages.
  347.  
  348. 4.1 Values for the SCSP "Mandatory Common Part"
  349.  
  350.    Protocol ID = 0x0003
  351.    Sender ID Len = 0x04
  352.    Recvr ID Len = 0x04
  353.  
  354.    See Section B.2.0.1 of [2] for a detailed description of these
  355.    fields.
  356.  
  357. 4.2 Values for the SCSP "CSAS Record"
  358.  
  359.    Cache Key Len = 0x04
  360.    Orig ID Len = 0x04
  361.  
  362.    See Section B.2.0.2 of [2] for a detailed description of these
  363.    fields.
  364.  
  365. 5.  Detailed State Descriptions
  366.  
  367. 5.1  MARS Server Redirect Entry.
  368.  
  369.    The MARS Server Redirect Entry is used to determine the operational
  370.    state of a MARS Server in the SG. Each server MUST update it's MARS
  371.    Server Redirect Entry state at least every 2 minutes, it is
  372.    RECOMMENDED that it is updated every 1 minute.
  373.  
  374.    0                   1                   2                   3
  375.    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
  376.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  377.    |        Hardware Type          |        Protocol Type          |
  378.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  379.    |                              SNAP                             |
  380.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  381.    |     SNAP      |   Unused      |    Version    |   State       |
  382.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  383.    |            Flags              |       Cluster Member ID       |
  384.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  385.    | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
  386.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  387.    |     Source ATM Address                  (variable length)     |
  388.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  389.    |     Source ATM SubAddress               (variable length)     |
  390.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  391.  
  392.  
  393.  
  394. Luciani & Gallo               Experimental                      [Page 7]
  395.  
  396. RFC 2443                MARS Service Using SCSP            November 1998
  397.  
  398.  
  399.    Hardware Type
  400.      This value is the ATM Forum 'address family number' specified in
  401.      [3] as 15 decimal (0x000F).
  402.  
  403.    Protocol Type
  404.      This field is the protocol type number for the protocol using MARS
  405.      from [3].  (IPv4 is 0x0800).
  406.  
  407.    Protocol SNAP
  408.      This field is the optional protocol SNAP extension to protocol
  409.      type.  This is the mar$pro.snap field from [1].
  410.  
  411.    Version Number
  412.      Version Number for this document MUST be set to 0x00.
  413.  
  414.    State
  415.      State value is coded as 1 decimal for a MARS Server Redirect Entry.
  416.  
  417.    The Flags, Cluster Member ID, Src Addr Len, and Group Addr Len fields
  418.    are unused and set to zero.
  419.  
  420.    The ATM Addr T/L, ATM SubAddr T/L, Source ATM Address, and Source ATM
  421.    SubAddress fields define the ATM address for the source of the MARS
  422.    Server Redirect Entry in the SG. The coding for these fields are the
  423.    same as described in Section 3 of this document.
  424.  
  425.    Failure to receive two consecutive MARS Server Redirect Entry updates
  426.    from a given MARS Server in the SG will cause all membership
  427.    information learned from this server to be flushed. When a valid MARS
  428.    Server Redirect Entry update is received the source of this update
  429.    will be placed into the table of backup MARS Servers sent in the
  430.    MARS_REDIRECT_MAP message. The ordering of servers in the
  431.    MARS_REDIRECT_MAP will first contain the list of MARS Servers learned
  432.    via MARS Server Redirect Entry updates in ascending order based on
  433.    the SCSP Sender ID, followed by any externally configured or learned
  434.    backup MARS Servers. The format of the MARS_REDIRECT_MAP can be found
  435.    in Section 5.4.3 of [1].
  436.  
  437. 5.2  MCS Serve/Register request.
  438.  
  439.    The MCS Serve/Register request is used to propagate the registering
  440.    or servicing of specific groups by an MCS Client within the SG
  441.    domain. It is similar to an MARS_MSERV request defined in Section
  442.    6.2.2 and 6.2.3 of [1]. When a MARS Server in the SG successfully
  443.    adds a new MCS Client to it's SCVC or adds MCS support for a specific
  444.    group it MUST send a MCS Serve/Register request to the SG. An MCS
  445.    Client can only register with one MARS Server in the SG.
  446.  
  447.  
  448.  
  449.  
  450. Luciani & Gallo               Experimental                      [Page 8]
  451.  
  452. RFC 2443                MARS Service Using SCSP            November 1998
  453.  
  454.  
  455.    0                   1                   2                   3
  456.    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
  457.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  458.    |        Hardware Type          |        Protocol Type          |
  459.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  460.    |                              SNAP                             |
  461.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  462.    |     SNAP      |   Unused      |    Version    |   State       |
  463.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  464.    |            Flags              |       Cluster Member ID       |
  465.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  466.    | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
  467.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  468.    |     Source Protocol Address             (variable length)     |
  469.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  470.    |     Source ATM Address                  (variable length)     |
  471.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  472.    |     Source ATM SubAddress               (variable length)     |
  473.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  474.    |     Minimum Multicast Group Address     (variable length)     |
  475.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  476.    |     Maximum Multicast Group Address     (variable length)     |
  477.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  478.  
  479.    Hardware Type
  480.      This value is the ATM Forum 'address family number' specified in
  481.      [3] as 15 decimal (0x000F).
  482.  
  483.    Protocol Type
  484.      This field is the protocol type number for the protocol using MARS
  485.      from [3].  (IPv4 is 0x0800).
  486.  
  487.    Protocol SNAP
  488.      This field is the optional protocol SNAP extension to protocol
  489.      type.  This is the mar$pro.snap field from [1].
  490.  
  491.    Version Number
  492.      Version Number for this document MUST be set to 0x00.
  493.  
  494.    State
  495.      State value is coded as 2 decimal for a MCS Serve/Register request.
  496.  
  497.    Flags
  498.      The flags field is used to contain several flags:
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Luciani & Gallo               Experimental                      [Page 9]
  507.  
  508. RFC 2443                MARS Service Using SCSP            November 1998
  509.  
  510.  
  511.        mar$flags
  512.           Bit 15   - mar$flags.layer3grp
  513.           Bit 13   - mar$flags.register
  514.           Bit 0-7  - mar$flags.sequence
  515.  
  516.      The mar$flags.register bit MUST be set the same as in the
  517.      originating MARS_MSERV request. The mar$flags.layer3grp bit MUST be
  518.      zero and the mar$flags.sequence bits are of local significance only
  519.      to the LS.
  520.  
  521.    Cluster Member CMI
  522.      This field contains the CMI assigned by the MARS Server which
  523.      processed the MARS_MSERV request and uniquely identifies the MCS
  524.      Client in the MARS server cache.
  525.  
  526.    Src Addr Len
  527.      This field contains the length of the Source Protocol Address
  528.      field.  For IPv4, the value is 4 if an address is specified. A null
  529.      (non-existent) address MUST be coded as zero length, and no space
  530.      allocated for it in the message body.
  531.  
  532.    Group Addr Len
  533.      This field contains the length of the Group Protocol Address field.
  534.      If the register bit in the flags field is set to 1 in the request
  535.      this field MUST be zero.  If the register bit is zero in the flags
  536.      field the value of this field for IPv4 is 4.
  537.  
  538.    ATM Addr T/L
  539.      This field contains the type and length of the Source ATM Address
  540.      field for the MCS Client that originated the MARS_MSERV request.
  541.      The type and length encoding is described in Section 3.
  542.  
  543.    ATM SubAddr T/L
  544.      This field contains the type and length of the Source ATM
  545.      SubAddress field for the MCS Client that originated the MARS_MSERV
  546.      request.  The type and length encoding is described in Section 3.
  547.  
  548.    Source Protocol Address
  549.      This is the internetwork address for the source of an address
  550.      binding in a MARS server cache entry. If Src Addr Len is set to
  551.      zero no storage will be allocated.
  552.  
  553.    Source ATM Address
  554.      This is the MCS Client's ATM address of an address binding in a
  555.      MARS server cache entry. The address is E.164 or ATM Forum NSAPA.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Luciani & Gallo               Experimental                     [Page 10]
  563.  
  564. RFC 2443                MARS Service Using SCSP            November 1998
  565.  
  566.  
  567.    Source ATM SubAddress
  568.      This is the MCS Client's ATM subaddress of an address binding in a
  569.      MARS server cache entry. The subaddress, if specified, is an ATM
  570.      Forum NSAPA.  If null, no storage will be allocated.
  571.  
  572.    Minimum Multicast Group Address
  573.      This is the internetwork address of the lower bound on the range of
  574.      multicast group addresses for the address binding in a MARS server
  575.      cache entry. If Group Addr Len is set to zero no storage will be
  576.      allocated.
  577.  
  578.    Maximum Multicast Group Address
  579.      This is the internetwork address of the upper bound on the range of
  580.      multicast group addresses for the address binding in a MARS server
  581.      cache entry. If Group Addr Len is set to zero no storage will be
  582.      allocated.
  583.  
  584.    An MCS Client can only register with one MARS Server in the SG and is
  585.    only placed on the SCVC for the MARS Server for which it is
  586.    registered with.
  587.  
  588.    When a MCS Client Serve/Register request specifying a group address
  589.    is received by a MARS Server it MUST create a cache entry associated
  590.    with this client. In addition to adding the cache entry it MUST send
  591.    out a MARS_MIGRATE message on it's CCVC. This is needed so that
  592.    clients using a mesh topology can migrate to a server based topology.
  593.    Details regarding the MARS_MIGRATE message can be found in Section
  594.    5.1.6 of [1].
  595.  
  596. 5.3  MARS Client Join/Register request.
  597.  
  598.    The MARS Client Join/Register request is used to propagate the
  599.    registering or joining of specific group ranges by MARS Clients
  600.    within the SG domain.  It is similar to the MARS_JOIN request defined
  601.    in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the SG
  602.    successfully registers a new MARS Client or a registered client joins
  603.    a specific group address range the MARS Server MUST send a MARS
  604.    Client Join/Register request to the SG. A MARS Client can only
  605.    register with one MARS Server in the SG and is placed only on that
  606.    servers CCVC.
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Luciani & Gallo               Experimental                     [Page 11]
  619.  
  620. RFC 2443                MARS Service Using SCSP            November 1998
  621.  
  622.  
  623.    0                   1                   2                   3
  624.    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
  625.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  626.    |        Hardware Type          |        Protocol Type          |
  627.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  628.    |                              SNAP                             |
  629.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  630.    |     SNAP      |   Unused      |    Version    |   State       |
  631.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  632.    |            Flags              |       Cluster Member ID       |
  633.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  634.    | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
  635.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  636.    |     Source Protocol Address             (variable length)     |
  637.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  638.    |     Source ATM Address                  (variable length)     |
  639.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  640.    |     Source ATM SubAddress               (variable length)     |
  641.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  642.    |     Minimum Multicast Group Address     (variable length)     |
  643.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  644.    |     Maximum Multicast Group Address     (variable length)     |
  645.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  646.  
  647.    Hardware Type
  648.      This value is the ATM Forum 'address family number' specified in
  649.      [3] as 15 decimal (0x000F).
  650.  
  651.    Protocol Type
  652.      This field is the protocol type number for the protocol using MARS
  653.      from [3].  (IPv4 is 0x0800).
  654.  
  655.    Protocol SNAP
  656.      This field is the optional protocol SNAP extension to protocol
  657.      type.  This is the mar$pro.snap field from [1].
  658.  
  659.    Version Number
  660.      Version Number for this document MUST be set to 0x00.
  661.  
  662.    State
  663.      State value is coded as 3 decimal for a MARS Client Join/Register
  664.      request.
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Luciani & Gallo               Experimental                     [Page 12]
  675.  
  676. RFC 2443                MARS Service Using SCSP            November 1998
  677.  
  678.  
  679.    Flags
  680.      The flags field is used to contain several flags:
  681.  
  682.        mar$flags
  683.           Bit 15   - mar$flags.layer3grp
  684.           Bit 13   - mar$flags.register
  685.           Bit 0-7  - mar$flags.sequence
  686.  
  687.      The mars$flags.layer3grp and mar$flags.register bits MUST be set
  688.      the same as in the originating MARS_JOIN request. The
  689.      mar$flags.sequence bits are of local significance only to the LS.
  690.  
  691.    Cluster Member CMI
  692.      This field contains the CMI assigned by the MARS Server which
  693.      processed the MARS_JOIN request and uniquely identifies the MARS
  694.      Client in the MARS server cache.
  695.  
  696.    Src Addr Len
  697.      This field contains the length of the Source Protocol Address
  698.      field.  For IPv4, the value is 4 if an address is specified. A null
  699.      (non-existent) address MUST be coded as zero length, and no space
  700.      allocated for it in the message body.
  701.  
  702.    Group Addr Len
  703.      This field contains the length of the Group Protocol Address field.
  704.      If the register bit in the flags field is set to 1 in the request
  705.      this field MUST be zero.  If the register bit is zero in the flags
  706.      field the value of this field for IPv4 is 4.
  707.  
  708.    ATM Addr T/L
  709.      This field contains the type and length of the Source ATM Address
  710.      field for the MARS Client that originated the MARS_JOIN request.
  711.      The type and length encoding is described in Section 3.
  712.  
  713.    ATM SubAddr T/L
  714.      This field contains the type and length of the Source ATM
  715.      SubAddress field for the MARS Client that originated the MARS_JOIN
  716.      request.  The type and length encoding is described in Section 3.
  717.  
  718.    Source Protocol Address
  719.      This is the internetwork address for the source of an address
  720.      binding in a MARS server cache entry. If Src Addr Len is set to
  721.      zero no storage will be allocated.
  722.  
  723.    Source ATM Address
  724.      This is the MARS Client's ATM address of an address binding in a
  725.      MARS server cache entry. The address is E.164 or ATM Forum NSAPA.
  726.  
  727.  
  728.  
  729.  
  730. Luciani & Gallo               Experimental                     [Page 13]
  731.  
  732. RFC 2443                MARS Service Using SCSP            November 1998
  733.  
  734.  
  735.    Source ATM SubAddress
  736.      This is the MARS Client's ATM subaddress of an address binding in a
  737.      MARS server cache entry. The subaddress, if specified, is an ATM
  738.      Forum NSAPA.  If null, no storage will be allocated.
  739.  
  740.    Minimum Multicast Group Address
  741.      This is the internetwork address of the lower bound on the range of
  742.      multicast group addresses for the address binding in a MARS server
  743.      cache entry. If Group Addr Len is set to zero no storage will be
  744.      allocated.
  745.  
  746.    Maximum Multicast Group Address
  747.      This is the internetwork address of the upper bound on the range of
  748.      multicast group addresses for the address binding in a MARS server
  749.      cache entry. If Group Addr Len is set to zero no storage will be
  750.      allocated.
  751.  
  752.    An MARS Client can only register with one MARS Server in the SG and
  753.    is only placed on the CCVC for the MARS Server for which it is
  754.    registered with. If the mar$flags.layer3grp is set to 1 than the
  755.    Minimum and Maximum Multicast Group Addresses MUST be equal for IPv4.
  756.  
  757.    When a MARS Client Join/Register request is sent with the
  758.    mar$flags.register bit set to 1 all of the servers in the SG will
  759.    create a cache entry for this client using the information in the
  760.    request.
  761.  
  762.    When a registered MARS Client issues a MARS_JOIN for a specific group
  763.    address range a MARS Client Join/Register request MUST be sent to the
  764.    servers in the SG. The actions taken by each server in the SG depend
  765.    on previous group membership actions and MCS supported groups.
  766.  
  767.    Each MARS Server MUST perform the necessary redistribution and hole
  768.    punching algorithms before propagating this request to the CCVC and
  769.    SCVC on each server. The redistribution and hole punching algorithms
  770.    used for propagating join requests to the CCVC are the same as
  771.    defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating
  772.    MARS_JOIN request is a duplicate of a previously joined range or
  773.    contains no group address range than a MARS Client Join/Register MUST
  774.    NOT be sent to the SG.
  775.  
  776.    The redistribution and hole punching algorithms used for propagating
  777.    join requests as MARS_SJOIN request on a SCVC is the same as Section
  778.    6.2.4 except for the following. Only the MARS Servers which contain
  779.    the registered MCS Clients for the target group ranges should
  780.    propagate this information to their SCVCs.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Luciani & Gallo               Experimental                     [Page 14]
  787.  
  788. RFC 2443                MARS Service Using SCSP            November 1998
  789.  
  790.  
  791. 5.4  MARS Client Leave/Deregister request.
  792.  
  793.    The MARS Client Leave/Deregister request is used to propagate the
  794.    deregistering or leaving of specific group ranges by registered MARS
  795.    Clients within the SG domain. It is similar to the MARS_LEAVE request
  796.    defined in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the
  797.    SG successfully deregisters a registered MARS Client or a registered
  798.    client leaves a specific group address range for which it had joined
  799.    the MARS Server MUST send a MARS Client Leave/Deregister request to
  800.    the SG. If a registered MARS Client is unexpectedly removed from the
  801.    CCVC the MARS Server MUST act as a proxy and send a MARS Client
  802.    Leave/Deregister request to the SG.
  803.  
  804.    The format and meanings of the fields in a MARS Client
  805.    Leave/Deregister request are the same as in Section 5.3 except the
  806.    State is coded as 4 decimal for a MARS Client Leave/Deregister
  807.    request.
  808.  
  809.    When a MARS Client Leave/Deregister request is sent with the
  810.    mar$flags.register bit set to 1 all of the servers in the SG
  811.    receiving this update MUST purge all cache entries for this client.
  812.  
  813.    When a registered MARS Client issues a MARS_LEAVE for a specific
  814.    group address range a MARS Client LEAVE/Deregister request MUST be
  815.    sent to the servers in the SG. The actions taken by each server in
  816.    the SG depend on previous group membership actions and MCS supported
  817.    groups.
  818.  
  819.    Each MARS Server MUST perform the necessary redistribution and hole
  820.    punching algorithms before propagating this request to the CCVC and
  821.    SCVC on each server. The redistribution and hole punching algorithms
  822.    used for propagating leave requests to the CCVC are the same as
  823.    defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating
  824.    MARS_LEAVE request does not correspond to a previously joined range
  825.    or contains no group address range than a MARS Client
  826.    Leave/Deregister MUST NOT be sent to the SG.
  827.  
  828.    The redistribution and hole punching algorithms used for propagating
  829.    leave requests as MARS_SLEAVE requests on a SCVC is the same as
  830.    Section 6.2.4 except for the following. Only the MARS Servers which
  831.    contain the registered MCS Clients for the target group ranges should
  832.    propagate this information to their SCVCs.
  833.  
  834. 5.5  MCS Unserve/Deregister request.
  835.  
  836.    The MCS Unserve/Deregister request is used to propagate the
  837.    deregistering or unservicing of specific groups by a registered MCS
  838.    Client within the SG domain. It is similar to an MARS_MUNSERV request
  839.  
  840.  
  841.  
  842. Luciani & Gallo               Experimental                     [Page 15]
  843.  
  844. RFC 2443                MARS Service Using SCSP            November 1998
  845.  
  846.  
  847.    defined in Section 6.2.2 and 6.2.3 of [1]. When a MARS Server in the
  848.    SG successfully deregisters a registered MCS Client or registered MCS
  849.    Client stops serving a specific group address range for which it had
  850.    serviced the MARS Server MUST send a MCS Unserve/Deregister request
  851.    to the SG. If a registered MCS Client is unexpectedly removed from
  852.    the SCVC the MARS Server owning the SCVC MUST act as a proxy and send
  853.    a MCS Unserve/Deregister request to the SG.
  854.  
  855.    The format and meanings of the fields in a MCS Unserve/Deregister
  856.    request are the same as in Section 5.2 except the State is coded as 5
  857.    decimal for a MCS Unserve/Deregister request.
  858.  
  859.    When a MCS Client Unserve/Deregister request is sent with the
  860.    mar$flags.register bit set to 1 all of the servers in the SG
  861.    receiving this update MUST purge all cache entries for this client.
  862.  
  863.    When a registered MCS Client issues a MARS_MUNSERV for a specific
  864.    group address range being served a MCS Client Unserve/Deregister
  865.    request MUST be sent to the servers in the SG. The members of the SG
  866.    that receive this update must then clear the cache entry associated
  867.    with this MCS Client.
  868.  
  869.    In addition to clearing one or more cache entries associated with
  870.    receiving a  MCS Client Unserve/Deregister request each MARS Server
  871.    in the SG MUST send out a MARS_LEAVE message on it's CCVC in order
  872.    for clients to change back to a mesh topology.
  873.  
  874. 6.  Security Considerations
  875.  
  876.    There is no mechanism to encrypt the CSA Record MARS Specific Part of
  877.    the message exchanged between servers. However, there are base SCSP
  878.    security features in the SCSP Protocol Independent part [2] which can
  879.    be used to protect against attacks.
  880.  
  881.    Any SCSP MARS is susceptible to Denial of Service (DOS) attacks. A
  882.    rouge MARS Client can inundate its Server with MARS packets. This is
  883.    a base MARS problem as currently defined by [1]. A rouge host can
  884.    also inundate its neighboring SCSP MARS with SCSP packets. However,
  885.    if the authentication option is used, the SCSP MARS databases will
  886.    not become corrupted, as the bogus packets will be discarded when the
  887.    authentication check fails.
  888.  
  889.    Due to the pair wise authentication model of SCSP MARS, the
  890.    information received from any properly authenticated server is
  891.    trusted and propagated throughout the server group. Consequently, if
  892.    security of any SCSP MARS server is compromised, the entire database
  893.    becomes vulnerable to corruption originating from the compromised
  894.    server.
  895.  
  896.  
  897.  
  898. Luciani & Gallo               Experimental                     [Page 16]
  899.  
  900. RFC 2443                MARS Service Using SCSP            November 1998
  901.  
  902.  
  903. References
  904.  
  905.    [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
  906.        Networks", RFC 2022, November 1996.
  907.  
  908.    [2] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server
  909.        Cache Synchronization Protocol", RFC 2334, April 1998.
  910.  
  911.    [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  912.        October 1994.  See also: http://www.iana.org/numbers.html
  913.  
  914.    [4] Laubach, M., "Classic IP and ARP over ATM", RFC 1577, January
  915.        1994.
  916.  
  917.    [5] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
  918.        Levels," BCP 14, RFC 2119, March 1997.
  919.  
  920. Acknowledgments
  921.  
  922.    The authors would like to thank Grenville Armitage for his previous
  923.    distributed MARS work and also the members of the ION working group
  924.    of the IETF, whose review and discussion of this document has been
  925.    invaluable.
  926.  
  927. Authors' Addresses
  928.  
  929.    James V. Luciani
  930.    Bay Networks, Inc.
  931.    3 Federal Street, BL3-04
  932.    Billerica, MA  01821
  933.  
  934.    Phone: +1-508-916-4734
  935.    EMail: luciani@baynetworks.com
  936.  
  937.  
  938.    Anthony M. Gallo
  939.    IBM, Networking Hardware Division
  940.    Dept. M6LA/B664
  941.    P.O. Box 12195
  942.    Research Triangle Park, NC 27709
  943.  
  944.    Phone: +1-919-254-9889
  945.    EMail: gallo@raleigh.ibm.com
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Luciani & Gallo               Experimental                     [Page 17]
  955.  
  956. RFC 2443                MARS Service Using SCSP            November 1998
  957.  
  958.  
  959. Full Copyright Statement
  960.  
  961.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  962.  
  963.    This document and translations of it may be copied and furnished to
  964.    others, and derivative works that comment on or otherwise explain it
  965.    or assist in its implementation may be prepared, copied, published
  966.    and distributed, in whole or in part, without restriction of any
  967.    kind, provided that the above copyright notice and this paragraph are
  968.    included on all such copies and derivative works.  However, this
  969.    document itself may not be modified in any way, such as by removing
  970.    the copyright notice or references to the Internet Society or other
  971.    Internet organizations, except as needed for the purpose of
  972.    developing Internet standards in which case the procedures for
  973.    copyrights defined in the Internet Standards process must be
  974.    followed, or as required to translate it into languages other than
  975.    English.
  976.  
  977.    The limited permissions granted above are perpetual and will not be
  978.    revoked by the Internet Society or its successors or assigns.
  979.  
  980.    This document and the information contained herein is provided on an
  981.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  982.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  983.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  984.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  985.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  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. Luciani & Gallo               Experimental                     [Page 18]
  1011.  
  1012.