home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2335.txt < prev   
Encoding:
Text File  |  2003-06-11  |  13.7 KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         J. Luciani
  8. Request for Comments: 2335                                  Bay Networks
  9. Category: Standards Track                                     April 1998
  10.  
  11.  
  12.                  A Distributed NHRP Service Using SCSP
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  25.  
  26. Abstract
  27.  
  28.    This document describes a method for distributing an NHRP service
  29.    within a LIS [1].  This method uses the Server Cache Synchronization
  30.    Protocol (SCSP) [2] to synchronize the client information databases
  31.    held by NHRP Servers (NHSs) within a LIS.
  32.  
  33. 1. Introduction
  34.  
  35.    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
  36.    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
  37.    document, are to be interpreted as described in [4].
  38.  
  39.    NHRP Clients (NHCs) register their existence and reachability
  40.    information with NHRP Servers (NHSs).  There may be multiple NHSs in
  41.    a given Logical IP Subnet (LIS).  NHCs do not necessarily register
  42.    with all NHSs in a LIS; however, all NHCs need to be able to query at
  43.    least one NHS about any NHC within the LIS.  Thus, the contents of
  44.    the NHS databases in a LIS need to be synchronized across the LIS.
  45.    The Server Cache Synchronization Protocol (SCSP) solves the
  46.    generalized server synchronization/cache-replication problem for
  47.    distributed databases and thus SCSP may be applied to the NHS
  48.    database synchronization problem within the LIS.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Luciani                     Standards Track                     [Page 1]
  59.  
  60. RFC 2335                    NHRP Using SCSP                   April 1998
  61.  
  62.  
  63.    SCSP is defined in two parts: the protocol independent part and the
  64.    client/server protocol specific part.  The protocol independent part
  65.    is defined in [2] whereas this document will specify the
  66.    client/server protocol specific part where NHRP is the client/server
  67.    protocol.
  68.  
  69.    This document is separate from [2] because it was felt that it was
  70.    desirable to allow the client/server protocol specific part
  71.    specification for NHRP to progress independently from the protocol
  72.    independent specification.
  73.  
  74. 2. Overview
  75.  
  76.    All NHSs belonging to a Logical IP Subnet (LIS) [1] are said to
  77.    belong to a Server Group (SG).  An SG is identified by, not
  78.    surprisingly, its SGID which is contained in a field in all SCSP
  79.    packets.  All SCSP packets contain a Protocol ID (PID) field as well.
  80.    This PID field is set to 0x0002 to signify that SCSP synchronizing
  81.    NHS databases as opposed to synchronizing some other protocol's
  82.    databases (see Section B.2.0.1 of [2] for more details).  In general,
  83.    PIDs for SCSP will be assigned by IANA as described in Section C of
  84.    [2].  In the case of NHRP, the client/server protocol specific
  85.    specification was initially written at the same time as SCSP, and
  86.    thus a PID=0x0002 was assigned by the author.
  87.  
  88.    SCSP places no topological requirements upon an NHRP SG.  Obviously,
  89.    however, the resultant graph of NHSs must span the set of NHSs to be
  90.    synchronized.  For more information about the client/server protocol
  91.    independent part of SCSP, the reader is encouraged to see [2].
  92.  
  93.    When a SG is using SCSP for synchronization, an NHC will register
  94.    with only one NHS, but the NHC MAY use any NHS in the SG.  When an
  95.    NHC wishes to leave a SG, the NHC MUST do one of the following: 1)
  96.    the NHC MUST send an NHRP Purge Request for itself requesting a
  97.    reply, and it MUST wait for an NHRP Purge Reply, 2) the NHC MUST keep
  98.    the Request ID it used when registering itself in non-volatile RAM
  99.    and use a Request ID larger than the one saved when re-registering,
  100.    or 3) the NHC MUST not re-register for a time equal to the Holding
  101.    Time specified in the previous registration.  It is necessary to do
  102.    one of the previous in order to prevent the unlikely case of race
  103.    conditions from occurring during updated.  In the case where method 2
  104.    is used, the NHS with which the NHC registered uses its ID as the OID
  105.    and the Request ID from the NHC as the CSA Sequence Number in the
  106.    CSA(S) Record.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Luciani                     Standards Track                     [Page 2]
  115.  
  116. RFC 2335                    NHRP Using SCSP                   April 1998
  117.  
  118.  
  119. 3.  Format of the CSA Record NHRP Specific Part
  120.  
  121.    CSA Records in SCSP contain a "Client/Server Protocol Specific Part"
  122.    which contains the non-protocol independent information for a given
  123.    server's cache entry.
  124.  
  125.       0                   1                   2                   3
  126.       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
  127.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  128.      |     Address Family Number     |     NHRP Protocol Type        |
  129.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  130.      |                             Snap                              |
  131.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  132.      |     Snap      | NHRP Vers Num |            Flags              |
  133.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  134.      |                         Request ID                            |
  135.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  136.      |    State      | Prefix Length |            unused             |
  137.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  138.      |  Maximum Transmission Unit    |        Holding Time           |
  139.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  140.      |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
  141.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  142.      |          Client Subnetwork Address (variable length)          |
  143.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  144.      |         Client Subnetwork Subaddress (variable length)        |
  145.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  146.      |          Client Protocol Address (variable length)            |
  147.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  148.  
  149.    The following six fields contain values specified in the common
  150.    header of the mandatory part of an NHRP Registration Request or NHRP
  151.    Purge Request packet which caused the
  152.    creation/deletion/modification/update/etc. of an NHS's cache entry.
  153.  
  154.    Address Family Number
  155.      Defines the type of "link layer" addresses being carried.  This
  156.      number is taken from the 'address family number' list specified in
  157.      [3].  This field is the same field which would be supplied in an
  158.      NHRP packet in the ar$afn field.
  159.  
  160.    NHRP Protocol Type
  161.      This field is the same field which would be supplied in an NHRP
  162.      packet in the ar$pro.type field.
  163.  
  164.    Snap
  165.      This field is the same field which would be supplied in an NHRP
  166.      packet in the ar$pro.snap field.
  167.  
  168.  
  169.  
  170. Luciani                     Standards Track                     [Page 3]
  171.  
  172. RFC 2335                    NHRP Using SCSP                   April 1998
  173.  
  174.  
  175.    NHRP Vers Num
  176.      This field indicates what version of generic address mapping and
  177.      management protocol that is represented by this message.  This
  178.      field contains 0x01 for the NHRP protocol version 1.  This field is
  179.      the same field which would be supplied in an NHRP packet in the
  180.      ar$op.version field.
  181.  
  182.    Flags
  183.      Defined flags are as follows:
  184.  
  185.         0                   1
  186.         0                   1
  187.         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  188.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  189.        |U|A|       unused              |
  190.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  191.  
  192.        U
  193.          This is the Uniqueness bit.
  194.  
  195.        A
  196.          When set, this bit specifies that the cache entry was created
  197.          as a result of ATMARP client interaction with the NHS.
  198.  
  199.    Request ID
  200.      This field contains the Request ID value placed in the cache entry
  201.      of the NHS as a result of an NHRP Registration Request.  This NHS
  202.      is the NHS causing a synchronization event.
  203.  
  204.    State
  205.      This field contains a value which represents the new state of the
  206.      client.
  207.  
  208.        0 - Client is registered and available.
  209.        1 - Client reregistered.
  210.        2 - Client has been purged.
  211.        3 - No such client data in server cache
  212.  
  213.      Note that a time-out of a cache entry does not cause a CSA Record
  214.      to be sent because, if everything is working properly then all NHSs
  215.      have the cache entry timing out at the same time.  Thus, the
  216.      individual NHSs would take the appropriate actions necessary.
  217.  
  218.    The following ten fields contain values specified in or derived from
  219.    the CIE of an NHRP Registration Request or NHRP Purge Request packet
  220.    which caused the creation/deletion/modification/update/etc. of an
  221.    NHS's cache entry.
  222.  
  223.  
  224.  
  225.  
  226. Luciani                     Standards Track                     [Page 4]
  227.  
  228. RFC 2335                    NHRP Using SCSP                   April 1998
  229.  
  230.  
  231.    Prefix Length
  232.      This field contains the internetwork layer address prefix length
  233.      value covered by the cache entry being synchronized.
  234.  
  235.    Maximum Transmission Unit
  236.      This field contains a value supplied by or derived from information
  237.      in the CIE of the NHRP Registration Request packet.
  238.  
  239.    Holding Time
  240.      The Holding Time field specifies the number of seconds remaining
  241.      for which the Next Hop NBMA information specified in the CIE of the
  242.      NHRP Registration Request is considered to be valid by the NHS
  243.      initiating the synchronization event.
  244.  
  245.    Cli Addr T/L
  246.      Type & length of next hop NBMA address (see [1]).
  247.  
  248.    Cli SAddr T/L
  249.      Type & length of next hop NBMA subaddress (see [1]).
  250.  
  251.    Cli Proto Len
  252.      This field holds the length in octets of the Client Protocol
  253.      Address.
  254.  
  255.    Preference
  256.      This field specifies the preference value for use of the next hop
  257.      NBMA information specified.
  258.  
  259.    Client NBMA Address
  260.      This is the client's NBMA address.
  261.  
  262.    Client NBMA SubAddress
  263.      This is the client's NBMA subaddress.
  264.  
  265.    Client Protocol Address
  266.      This is the client's internetworking layer address.
  267.  
  268. 4.  Values for SCSP Protocol Independent Part
  269.  
  270.    The following sections give values for fields of the SCSP Protocol
  271.    Independent Part of the various SCSP messages.
  272.  
  273. 4.1 Values for the SCSP "Mandatory Common Part"
  274.  
  275.    Protocol ID = 0x0002
  276.    Sender ID Len = 0x04
  277.    Recvr ID Len = 0x04
  278.  
  279.  
  280.  
  281.  
  282. Luciani                     Standards Track                     [Page 5]
  283.  
  284. RFC 2335                    NHRP Using SCSP                   April 1998
  285.  
  286.  
  287.    See Section B.2.0.1 of [2] for a detailed description of these
  288.    fields.
  289.  
  290. 4.2 Values for the SCSP "CSAS Record"
  291.  
  292.    Cache Key Len = 0x04
  293.    Orig ID Len = 0x04
  294.  
  295.    See Section B.2.0.2 of [2] for a detailed description of these
  296.    fields.
  297.  
  298. 5. Security Considerations
  299.  
  300.    Relevant security considerations are documented in [1] and [2].
  301.  
  302. References
  303.  
  304.    [1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
  305.    Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332,
  306.    April 1998.
  307.  
  308.    [2] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server
  309.    Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
  310.  
  311.    [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  312.    October 1994.
  313.  
  314.    [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
  315.    Levels", BCP 14, RFC 2119, March 1997.
  316.  
  317. Acknowledgments
  318.  
  319.    I would like to thank (in no particular order) Maxine Burns of ISR
  320.    and Joel Halpern of Newbridge.  I would also like to thank the
  321.    members of the ION working group of the IETF, whose review and
  322.    discussion of this document has been invaluable.
  323.  
  324. Author's Address
  325.  
  326.    James V. Luciani
  327.    Bay Networks, Inc.
  328.    3 Federal Street, BL3-03
  329.    Billerica, MA  01821
  330.  
  331.    Phone: +1-978-916-4734
  332.    EMail: luciani@baynetworks.com
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Luciani                     Standards Track                     [Page 6]
  339.  
  340. RFC 2335                    NHRP Using SCSP                   April 1998
  341.  
  342.  
  343. Full Copyright Statement
  344.  
  345.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  346.  
  347.    This document and translations of it may be copied and furnished to
  348.    others, and derivative works that comment on or otherwise explain it
  349.    or assist in its implementation may be prepared, copied, published
  350.    and distributed, in whole or in part, without restriction of any
  351.    kind, provided that the above copyright notice and this paragraph are
  352.    included on all such copies and derivative works.  However, this
  353.    document itself may not be modified in any way, such as by removing
  354.    the copyright notice or references to the Internet Society or other
  355.    Internet organizations, except as needed for the purpose of
  356.    developing Internet standards in which case the procedures for
  357.    copyrights defined in the Internet Standards process must be
  358.    followed, or as required to translate it into languages other than
  359.    English.
  360.  
  361.    The limited permissions granted above are perpetual and will not be
  362.    revoked by the Internet Society or its successors or assigns.
  363.  
  364.    This document and the information contained herein is provided on an
  365.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  366.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  367.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  368.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  369.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Luciani                     Standards Track                     [Page 7]
  395.  
  396.