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-nhrp-02.txt < prev    next >
Text File  |  1997-10-29  |  12KB  |  335 lines
  1.  
  2. Internetworking Over NBMA                               James V. Luciani
  3. INTERNET-DRAFT                                            (Bay Networks)
  4. <draft-ietf-ion-scsp-nhrp-02.txt>                     Expires April 1998
  5.  
  6.  
  7.  
  8.  
  9.  
  10.                  A Distributed NHRP Service Using SCSP
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This document is an Internet-Draft.  Internet-Drafts are working
  16.    documents of the Internet Engineering Task Force (IETF), its areas,
  17.    and its working groups.  Note that other groups may also distribute
  18.    working documents as Internet-Drafts.
  19.  
  20.    Internet-Drafts are draft documents valid for a maximum of six months
  21.    and may be updated, replaced, or obsoleted by other documents at any
  22.    time.  It is inappropriate to use Internet-Drafts as reference
  23.    material or to cite them other than as ``work in progress.''
  24.  
  25.    To learn the current status of any Internet-Draft, please check the
  26.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  27.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  28.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  29.    Rim).
  30.  
  31. Abstract
  32.  
  33.    This document describes a method for distributing an NHRP service
  34.    within a LIS[1].  This method uses the Server Cache Synchronization
  35.    Protocol (SCSP)[2] to synchronize the client information databases
  36.    held by NHRP Servers (NHSs) within a LIS.
  37.  
  38.  
  39. 1. Introduction
  40.  
  41.    NHRP Clients (NHCs) register their existence and reachability
  42.    information with NHRP Servers (NHSs).  There may be multiple NHSs in
  43.    a given Logical IP Subnet (LIS).  NHCs do not necessarily register
  44.    with all NHSs in a LIS; however, all NHCs need to be able to query at
  45.    least one NHS about any NHC within the LIS.  Thus, the contents of
  46.    the NHS databases in a LIS need to be synchronized across the LIS.
  47.    The Server Cache Synchronization Protocol (SCSP) solves the
  48.    generalized server synchronization/cache-replication problem for
  49.    distributed databases and thus SCSP may be applied to the NHS
  50.  
  51.  
  52.  
  53. Luciani, et al.                                                 [Page 1]
  54.  
  55. INTERNET-DRAFT               SCSP for NHRP            Expires April 1998
  56.  
  57.  
  58.    database synchronization problem within the LIS.
  59.  
  60.    SCSP is defined in two parts: the protocol independent part and the
  61.    client/server protocol specific part.  The protocol independent part
  62.    is defined in [2] whereas this document will specify the
  63.    client/server protocol specific part where NHRP is the client/server
  64.    protocol.
  65.  
  66.    This document is separate from [2] because it was felt that it was
  67.    desirable to allow the client/server protocol specific part
  68.    specification for NHRP to progress independently from the protocol
  69.    independent specification.
  70.  
  71.  
  72. 2. Overview
  73.  
  74.    All NHSs belonging to a Logical IP Subnet (LIS)[1] are said to belong
  75.    to a Server Group (SG).  An SG is identified by, not surprisingly,
  76.    its SGID which is contained in a field in all SCSP packets.  All SCSP
  77.    packets contain a Protocol ID (PID) field as well.  This PID field is
  78.    set to 0x0002 to signify that SCSP synchronizing NHS databases as
  79.    opposed to synchronizing some other protocol's databases (see Section
  80.    B.2.0.1 of [2] for more details).  In general, PIDs for SCSP will be
  81.    assigned by IANA upon request given that a client/server protocol
  82.    specific specification has been written (as described in [2]).  In
  83.    the case of NHRP, the client/server protocol specific specification
  84.    was initially written at the same time as SCSP, and thus a PID=0x0002
  85.    was assigned by the author.
  86.  
  87.    SCSP places no topological requirements upon an NHRP SG.  Obviously,
  88.    however, the resultant graph of NHSs must span the set of NHSs to be
  89.    synchronized.  For more information about the client/server protocol
  90.    independent part of SCSP, the reader is encouraged to see [2].
  91.  
  92.    When a SG is using SCSP for synchronization, an NHC will register
  93.    with only one NHS, but the NHC MAY use any NHS in the SG.  When an
  94.    NHC wishes to leave a SG, the NHC MUST do one of the following: 1)
  95.    the NHC MUST send an NHRP Purge Request for itself requesting a
  96.    reply, and it MUST wait for an NHRP Purge Reply, 2) the NHC MUST keep
  97.    the Request ID it used when registering itself in non-volatile RAM
  98.    and use a Request ID larger than the one saved when re-registering,
  99.    or 3) the NHC MUST not re-register for a time equal to the Holding
  100.    Time specified in the previous registration.  It is necessary to do
  101.    one of the previous in order to prevent the unlikely case of race
  102.    conditions from occurring during updated.  In the case where method 2
  103.    is used, the NHS with which the NHC registered uses its ID as the OID
  104.    and the Request ID from the NHC as the CSA Sequence Number in the
  105.    CSA(S) Record.
  106.  
  107.  
  108.  
  109. Luciani, et al.                                                 [Page 2]
  110.  
  111. INTERNET-DRAFT               SCSP for NHRP            Expires April 1998
  112.  
  113.  
  114. 3.  Format of the CSA Record NHRP Specific Part
  115.  
  116. CSA Records in SCSP contain a "Client/Server Protocol Specific Part"
  117. which contains the non-protocol independent information for a given
  118. server's cache entry.
  119.  
  120.       0                   1                   2                   3
  121.       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
  122.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  123.      |     Address Family Number     |     NHRP Protocol Type        |
  124.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  125.      |                             Snap                              |
  126.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  127.      |     Snap      | NHRP Vers Num |            Flags              |
  128.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  129.      |                         Request ID                            |
  130.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  131.      |    State      | Prefix Length |            unused             |
  132.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  133.      |  Maximum Transmission Unit    |        Holding Time           |
  134.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  135.      |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
  136.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  137.      |          Client Subnetwork Address (variable length)          |
  138.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  139.      |         Client Subnetwork Subaddress (variable length)        |
  140.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  141.      |          Client Protocol Address (variable length)            |
  142.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  143.  
  144.    The following six fields contain values specified in the common
  145.    header of the mandatory part of an NHRP Registration Request or NHRP
  146.    Purge Request packet which caused the
  147.    creation/deletion/modification/update/etc. of an NHS's cache entry.
  148.  
  149.    Address Family Number
  150.      Defines the type of "link layer" addresses being carried.  This
  151.      number is taken from the 'address family number' list specified in
  152.      [3].  This field is the same field which would be supplied in an
  153.      NHRP packet in the ar$afn field.
  154.  
  155.    NHRP Protocol Type
  156.      This field is the same field which would be supplied in an NHRP
  157.      packet in the ar$pro.type field.
  158.  
  159.    Snap
  160.      This field is the same field which would be supplied in an NHRP
  161.      packet in the ar$pro.snap field.
  162.  
  163.  
  164.  
  165. Luciani, et al.                                                 [Page 3]
  166.  
  167. INTERNET-DRAFT               SCSP for NHRP            Expires April 1998
  168.  
  169.  
  170.    NHRP Vers Num
  171.      This field indicates what version of generic address mapping and
  172.      management protocol that is represented by this message.  This
  173.      field contains 0x01 for the NHRP protocol version 1.  This field is
  174.      the same field which would be supplied in an NHRP packet in the
  175.      ar$op.version field.
  176.  
  177.    Flags
  178.      Defined flags are as follows:
  179.  
  180.       0                   1
  181.       0                   1
  182.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  183.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.      |U|A|       unused              |
  185.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.  
  187.        U
  188.          This is the Uniqueness bit.
  189.  
  190.        A
  191.          When set, this bit specifies that the cache entry was created
  192.          as a result of ATMARP client interaction with the NHS.
  193.  
  194.    Request ID
  195.      This field contains the Request ID value placed in the cache entry
  196.      of the NHS as a result of an NHRP Registration Request.  This NHS
  197.      is the NHS causing a synchronization event.
  198.  
  199.    State
  200.      This field contains a value which represents the new state of the
  201.      client.
  202.  
  203.        0 - Client is registered and available.
  204.        1 - Client reregistered.
  205.        2 - Client has been purged.
  206.        3 - No such client data in server cache
  207.  
  208.      Note that a time-out of a cache entry does not cause a CSA Record
  209.      to be sent because, if everything is working properly then all NHSs
  210.      have the cache entry timing out at the same time.  Thus, the
  211.      individual NHSs would take the appropriate actions necessary.
  212.  
  213.    The following ten fields contain values specified in or derived from
  214.    the CIE of an NHRP Registration Request or NHRP Purge Request packet
  215.    which caused the creation/deletion/modification/update/etc. of an
  216.    NHS's cache entry.
  217.  
  218.  
  219.  
  220.  
  221. Luciani, et al.                                                 [Page 4]
  222.  
  223. INTERNET-DRAFT               SCSP for NHRP            Expires April 1998
  224.  
  225.  
  226.    Prefix Length
  227.      This field contains the internetwork layer address prefix length
  228.      value covered by the cache entry being synchronized.
  229.  
  230.    Maximum Transmission Unit
  231.      This field contains a value supplied by or derived from information
  232.      in the CIE of the NHRP Registration Request packet.
  233.  
  234.    Holding Time
  235.      The Holding Time field specifies the number of seconds remaining
  236.      for which the Next Hop NBMA information specified in the CIE of the
  237.      NHRP Registration Request is considered to be valid by the NHS
  238.      initiating the synchronization event.
  239.  
  240.    Cli Addr T/L
  241.      Type & length of next hop NBMA address (see [1]).
  242.  
  243.    Cli SAddr T/L
  244.      Type & length of next hop NBMA subaddress (see [1]).
  245.  
  246.    Cli Proto Len
  247.      This field holds the length in octets of the Client Protocol
  248.      Address.
  249.  
  250.    Preference
  251.      This field specifies the preference value for use of the next hop
  252.      NBMA information specified.
  253.  
  254.    Client NBMA Address
  255.      This is the client's NBMA address.
  256.  
  257.    Client NBMA SubAddress
  258.      This is the client's NBMA subaddress.
  259.  
  260.    Client Protocol Address
  261.      This is the client's internetworking layer address.
  262.  
  263.  
  264. 4.  Values for SCSP Protocol Independent Part
  265.  
  266.    The following sections give values for fields of the SCSP Protocol
  267.    Independent Part of the various SCSP messages.
  268.  
  269. 4.1 Values for the SCSP "Mandatory Common Part"
  270.  
  271.    Protocol ID = 0x0002
  272.    Sender ID Len = 0x04
  273.    Recvr ID Len = 0x04
  274.  
  275.  
  276.  
  277. Luciani, et al.                                                 [Page 5]
  278.  
  279. INTERNET-DRAFT               SCSP for NHRP            Expires April 1998
  280.  
  281.  
  282.    See Section B.2.0.1 of [2] for a detailed description of these
  283.    fields.
  284.  
  285. 4.2 Values for the SCSP "CSAS Record"
  286.  
  287.    Cache Key Len = 0x04
  288.    Orig ID Len = 0x04
  289.  
  290.    See Section B.2.0.2 of [2] for a detailed description of these
  291.    fields.
  292.  
  293. 5. Security Considerations
  294.  
  295.    Relevant security considerations are documented in [1] and [2].
  296.  
  297. References
  298.  
  299. [1] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello,
  300.     Cole, draft-ietf-rolc-nhrp-12.txt.
  301.  
  302. [2] "Server Cache Synchronization Protocol", Luciani, Armitage, Halpern,
  303.     draft-ietf-ion-scsp-02.txt.
  304.  
  305. [3] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700.
  306.  
  307. Acknowledgments
  308.    I would like to thank (in no particular order) Maxine Burns of ISR
  309.    and Joel Halpern of Newbridge.  I would also like to thank the
  310.    members of the ION working group of the IETF, whose review and
  311.    discussion of this document has been invaluable.
  312.  
  313. Author's Address
  314.  
  315.    James V. Luciani
  316.    Bay Networks, Inc.
  317.    3 Federal Street, BL3-04
  318.    Billerica, MA  01821
  319.    phone: +1-508-916-4734
  320.    email: luciani@baynetworks.com
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Luciani, et al.                                                 [Page 6]
  334.  
  335.