home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ion-scsp-mars-00.txt < prev    next >
Text File  |  1997-07-25  |  16KB  |  421 lines
  1. Internetworking Over NBMA                               James V. Luciani
  2. INTERNET-DRAFT                                            (Bay Networks)
  3. <draft-ietf-ion-scsp-mars-00.txt>                       Anthony M. Gallo
  4.                                                                    (IBM)
  5.                                                    Expires December 1997
  6.  
  7.  
  8.  
  9.  
  10.  
  11.                  A Distributed MARS Service Using SCSP
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This document is an Internet-Draft.  Internet-Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its areas,
  18.    and its working groups.  Note that other groups may also distribute
  19.    working documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six months
  22.    and may be updated, replaced, or obsoleted by other documents at any
  23.    time.  It is inappropriate to use Internet-Drafts as reference
  24.    material or to cite them other than as ``work in progress.''
  25.  
  26.    To learn the current status of any Internet-Draft, please check the
  27.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  28.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  29.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  30.    Rim).
  31.  
  32. Abstract
  33.  
  34.    This document describes a method for distributing a MARS service
  35.    within a LIS[1].  This method uses the Server Cache Synchronization
  36.    Protocol (SCSP)[2] to synchronize the MARS Server databases within a
  37.    LIS.  When SCSP is used to synchronize the caches of MARS Servers in
  38.    a LIS, the LIS defines the boundary of an SCSP Server Group (SG).
  39.  
  40. 1. Introduction
  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.    (CCVC) and MCS Clients are placed on the Server Control VC (SCVC).
  56.    Both the CCVC and SCVC are then used to propagate layer 3 multicast
  57.    updates to the clients which make up a LIS. During the registration
  58.    process MARS Clients are also assigned a unique Cluster Member ID
  59.    (CMI) which is used to identify reflected packets in the presence of
  60.    MCS Clients.
  61.  
  62.    In the Distributed MARS Model there MAY be multiple MARS Servers in a
  63.    given LIS, and since any MARS Server within the LIS MUST be able to
  64.    provide layer 3 multicast information about any multicast group
  65.    within the LIS, there MUST be a method by which to synchronize
  66.    multicast information across all MARS Servers within the LIS. In [5]
  67.    several distributed MARS models are discussed along with various
  68.    trade offs of each. The document provides a description of the
  69.    problems that need to be addressed from the MARS protocol's point of
  70.    view in a distributed system.
  71.  
  72.    The Server Cache Synchronization Protocol (SCSP) solves the
  73.    generalized server synchronization/cache-replication problem for
  74.    distributed databases, and thus SCSP MAY be applied to the MARS
  75.    Server database synchronization problem within a LIS. When SCSP is
  76.    used to synchronize the caches of MARS Servers in a LIS, the LIS
  77.    defines the boundary of and SCSP Server Group (SG).
  78.  
  79.    SCSP is defined in two parts: the protocol independent part and the
  80.    client/server protocol specific part. The protocol independent part
  81.    is specified in [2] whereas this document will specify the
  82.    client/server protocol specific part where the MARS Server is the
  83.    client/server protocol.
  84.  
  85. 2. Overview
  86.  
  87.    All MARS Servers belonging to a LIS are said to belong to a Server
  88.    Group (SG).  A SG is identified by, not surprisingly, its SGID which
  89.    is contained in a field in all SCSP packets. All SCSP packets contain
  90.    a Protocol ID (PID) field as well. This PID field is set to 0x0003 to
  91.    signify that SCSP is synchronizing MARS Server databases as opposed
  92.    to synchronizing some other protocol's databases. (see Section
  93.    B.2.0.1 of [2] for more details).  In general, PIDs for SCSP will be
  94.    assigned by IANA upon request given that a client/server protocol
  95.    specific specification has been written. In the case of MARS Servers,
  96.    the client/server protocol specific specification was written at the
  97.    same time time as SCSP, and thus a PID=0x0003 was assigned in [2].
  98.  
  99.    SCSP places no topological requirements upon a MARS Server SG.
  100.    Obviously, however, the resultant graph of MARS Servers must span the
  101.    set of MARS Servers being synchronized. For more information about
  102.    the client/server protocol independent part of SCSP, the reader is
  103.    encouraged to see [2].
  104.  
  105.    When a SG is using SCSP for synchronization, a MARS Client or MCS
  106.    Client will register with only one MARS Server although it is allowed
  107.    to choose any MARS Server in the SG for this registration). At
  108.    registration time the MARS Client or MCS Client will be added to that
  109.    MARS Servers respective CCVC or SCVC. Also, MARS Clients will be
  110.    issued a unique CMI for the entire LIS. This document assumes at a
  111.    minimum each MARS Server in the SG will be configured with a unique
  112.    range of CMIs to assign to clients registering with that MARS Server.
  113.    Use of some external means for allocating CMIs to MARS Servers in a
  114.    SG is possible but beyond the scope of this document.
  115.  
  116.    When a MARS Client or MCS Client successfully registers with a MARS
  117.    Server in the SG that MARS Server will propagate the registration
  118.    information to its peer MARS Servers. The same propagation will occur
  119.    for any subsequent group membership information learned from the
  120.    clients. The peer MARS Server will then update its group membership
  121.    database and propagate the information out its own CCVC or SCVC if
  122.    needed.
  123.  
  124.    In the case of a MARS Server failure all peer MARS Servers in the SG
  125.    MUST flush the client/group membership information learned from the
  126.    failed MARS Server. The clients belonging to the failed MARS Servers
  127.    CCVC and SCVC will migrate to the next available MARS Server as
  128.    specified in Section 5.3 of [1]. When a client detects a failure of
  129.    its MARS, it steps to the next backup MARS Server and attempts to
  130.    register with the server. If the registration is successful the
  131.    client will re-join all of its previous group membership information.
  132.    If the registration fails, the process repeats until a functional
  133.    MARS Server is found.
  134.  
  135.    Determining the operational state of a MARS Servers in a SG requires
  136.    that each MARS Server send out an "alive" or "heartbeat" message
  137.    similar to the MARS Redirect message sent out on the CCVC or SCVC for
  138.    MARS Clients. However, this message will only be sent to MARS Servers
  139.    in the SG and is from here on defined as the MARS Server Redirect
  140.    Entry.
  141.  
  142.    In order to detect that a MARS Server failure has occurred each
  143.    server MUST update it's MARS Server Redirect Entry state at least
  144.    every 2 minutes, it is RECOMMENDED that it is updated every 1 minute.
  145.    Failure to receive two consecutive MARS Server Redirect Entry updates
  146.    from a given MARS Server in the SG will cause all membership
  147.    information learned from this server to be flushed. The MARS Server
  148.    Redirect Entry state is also used to create the MARS_REDIRECT_MAP
  149.    messages sent out on CCVC for each MARS Server in the SG. The
  150.    ordering of each server learned will be based on the MARS Servers
  151.    SCSP Sender ID. The ordering of the MARS_REDIRECT_MAP will first
  152.    contain the list of MARS Servers learned via MARS Server Redirect
  153.    Entry updates in ascending order based on the SCSP Sender ID,
  154.    followed by any externally configured or learned backup MARS Servers.
  155.  
  156.    In the case of a MARS Client or MCS Client failure where the client
  157.    is unexpectedly removed from the CCVC or SCVC the MARS Server MUST
  158.    notify its peer SG members via a proxy deregister for that client.
  159.    Upon receiving a proxy deregister request from a peer SG member all
  160.    membership information for the deregistering client MUST be removed.
  161.    Any Clients sending multicast data to the failed client should also
  162.    receive an unexpected removal of this client which will intern cause
  163.    the sending client to revalidate the multicast groups current
  164.    membership as outlined in Section 5.1.5.1 of [1].
  165.  
  166. 3.  Format of the CSA Record MARS Specific Part
  167.  
  168.    CSA Records in SCSP contain a "Client/Server Protocol Specific Part"
  169.    which contains the non-protocol independent information for a given
  170.    server's cache entry.
  171.  
  172.    0                   1                   2                   3
  173.    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
  174.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  175.    |        Hardware Type          |        Protocol Type          |
  176.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  177.    |                              SNAP                             |
  178.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  179.    |     SNAP      |   Unused      |    Version    |   State       |
  180.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  181.    |            Flags              |       Cluster Member ID       |
  182.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  183.    | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
  184.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  185.    |     Source Protocol Address             (variable length)     |
  186.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  187.    |     Source ATM Address                  (variable length)     |
  188.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  189.    |     Source ATM SubAddress               (variable length)     |
  190.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  191.    |     Minimum Multicast Group Address     (variable length)     |
  192.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  193.    |     Maximum Multicast Group Address     (variable length)     |
  194.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  195.  
  196.    Hardware Type
  197.      Defines the type of "link layer" addresses being carried.  This
  198.      value is the ATM Forum 'address family number' specified in [3] as
  199.      15 decimal (0x000F).  This is the mar$afn field defined in [1].
  200.  
  201.    Protocol Type
  202.      This field is the protocol type number for the protocol using MARS
  203.      from [3].  (IPv4 is 0x0800).  This is the mar$pro.type field from
  204.      [1].
  205.  
  206.    Protocol SNAP
  207.      This field is the optional protocol SNAP extension to protocol
  208.      type. This is the mar$pro.snap field from [1].
  209.  
  210.    Version Number
  211.      0                    MARS Specific part of the CSA record.
  212.      0x01                 Reserved for NHRP.
  213.      0x02 - 0xEF          Reserved for future use by the IETF.
  214.      0xF0 - 0xFE          Allocated for use by the ATM Forum.
  215.      0xFF                 Experimental/Local use.
  216.      Version Number for this document MUST be set to 0x00.
  217.  
  218.    State
  219.      1   MARS Server Redirect Entry.
  220.      2   MCS Register request.
  221.      3   MARS Client Join/Register request.
  222.      4   MARS Client Leave/Deregister request.
  223.      5   MCS Deregister request.
  224.      6   MCS Join request.
  225.      7   MCS Leave request.
  226.  
  227.      All other State values should cause the CSA to be discarded.
  228.  
  229.    Src Addr Len
  230.      This field contains the length of the Source Protocol Address
  231.      field. For IPv4, the value is 4 if an address is specified. A null
  232.      (non-existant) address MUST be coded as zero length, and no space
  233.      allocated for it in the message body.  This is the mar$spln field
  234.      from [1].
  235.  
  236.    Group Addr Len
  237.      This field contains the length of the Group Protocol Address field.
  238.      For IPv4, the value is 4 if an address is specified. A null (non-
  239.      existant) address MUST be coded as zero length, and no space
  240.      allocated for it in the message body.  This is the mar$tpln field
  241.      from [1].
  242.  
  243.    ATM Addr T/L
  244.      This field contains the type and length of the Source ATM Address
  245.      field.  The type and length encodings are described in Section
  246.      5.1.2 of [1].
  247.  
  248.    ATM SubAddr T/L
  249.      This field contains the type and length of the Source ATM
  250.      SubAddress field.  The type and length encodings are described in
  251.      Section 5.1.2 of [1].
  252.  
  253.    Flags
  254.      Th flags field is used to contain several flags and is similar to
  255.      the mar$flags field from [1].
  256.        mar$flags
  257.           Bit 15   - mar$flags.layer3grp
  258.           Bit 13   - mar$flags.register
  259.           Bit 0-7  - mar$flags.sequence
  260.  
  261.        All remaining bits are reserved and MUST be zero. The
  262.        mars$flags.sequence field is of local significance only to the
  263.        Local Server (LS).
  264.  
  265.    Cluster Member CMI
  266.      This field contains the CMI which uniquely identifies each endpoint
  267.      within a LIS. This is the mar$cmi field from [1].
  268.  
  269.    Source ATM Address
  270.      This is the Source's ATM address of an address binding in a MARS
  271.      server cache entry.  The address, if specified, is E.164 or ATM
  272.      Forum NSAPA. This is the mar$sha field from [1].
  273.  
  274.    Source ATM Subaddress
  275.      This is the Source's ATM subaddress of an address binding in a MARS
  276.      server cache entry.  The subaddress, if specified, is an ATM Forum
  277.      NSAPA.  If null, no storage will be allocated. This is the mar$ssa
  278.      field from [1].
  279.  
  280.    Minimum Multicast Group Address
  281.      This is the internetwork address of the lower bound on the range of
  282.      multicast group addresses for the address binding in a MARS server
  283.      cache entry. This is the mar$min.N field from [1].
  284.  
  285.    Maximum Multicast Group Address
  286.      This is the internetwork address of the upper bound on the range of
  287.      multicast group addresses for the address binding in a MARS server
  288.      cache entry. This is the mar$max.N field from [1].
  289.  
  290. 4.  Values for SCSP Protocol Independent Part
  291.  
  292.    The following sections give values for fields of the SCSP Protocol
  293.    Independent Part of the various SCSP messages.
  294.  
  295. 4.1 Values for the SCSP "Mandatory Common Part"
  296.  
  297.    Protocol ID = 0x0003
  298.    Sender ID Len = 0x04
  299.    Recvr ID Len = 0x04
  300.  
  301.    See Section B.2.0.1 of [2] for a detailed description of these
  302.    fields.
  303.  
  304. 4.2 Values for the SCSP "CSAS Record"
  305.  
  306.    Cache Key Len = 0x04
  307.    Orig ID Len = 0x04
  308.  
  309.    See Section B.2.0.2 of [2] for a detailed description of these
  310.    fields.
  311.  
  312.  
  313. 5.  Detailed State Descriptions (Under Construction)
  314.  
  315.  
  316. 5.1  MARS Server Redirect Entry.
  317.  
  318.    TBD....
  319.  
  320. 5.2  MCS Register request.
  321.  
  322.    TBD....
  323.  
  324. 5.3  MARS Client Join/Register request.
  325.  
  326.    TBD....
  327.  
  328. 5.4  MARS Client Leave/Deregister request.
  329.  
  330.    TBD....
  331.  
  332. 5.5  MCS Deregister request.
  333.  
  334.    TBD....
  335.  
  336. 5.6  MCS Join request.
  337.  
  338.    TBD....
  339.  
  340. 5.7  MCS Leave request.
  341.  
  342.    TBD....
  343.  
  344.  
  345. 6.  Security Consideration
  346.  
  347.    Security is not addressed in this document but is addressed in the
  348.    SCSP Protocol Independent part [2].
  349.  
  350.  
  351. References
  352.  
  353. [1] "Support for Multicast over UNI 3.0/3.1 based ATM Networks", Armitage,
  354.     RFC2022.
  355.  
  356. [2] "Server Cache Synchronization Protocol", Luciani, Armitage, Halpern,
  357.     draft-ietf-ion-scsp-01.txt.
  358.  
  359. [3] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700.
  360.  
  361. [4] "Classic IP and ARP over ATM", Mark Laubach, RFC 1577.
  362.  
  363. [5] "Redundant MARS architectures and SCSP, Armitage,
  364.     draft-armitage-ion-mars-scsp-03.txt.
  365.  
  366.  
  367. Acknowledgments
  368.  
  369.    The authors would like to thank Grenville Armitage for his previous
  370.    distributed MARS work and also the members of the ION working group
  371.    of the IETF, whose review and discussion of this document has been
  372.    invaluable.
  373.  
  374.  
  375. Author's Address
  376.  
  377.    James V. Luciani
  378.    Bay Networks, Inc.
  379.    3 Federal Street, BL3-04
  380.    Billerica, MA  01821
  381.    phone: +1-508-916-4734
  382.    email: luciani@baynetworks.com
  383.  
  384.    Anthony M. Gallo
  385.    IBM, Networking Hardware Division
  386.    Dept. M6LA/B664
  387.    P.O. Box 12195
  388.    Research Triangle Park, NC 27709
  389.    phone: +1-919-254-9889
  390.    email: gallo@raliegh.ibm.com
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.