Network Working Group J. Luciani
Request for Comments: 2335 Bay Networks
Category: Standards Track April 1998
Network Working Group J. Luciani
Request for Comments: 2335 Bay Networks
Category: Standards Track April 1998
A Distributed NHRP Service Using SCSP
使用SCSP的分布式NHRP服务
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document describes a method for distributing an NHRP service within a LIS [1]. This method uses the Server Cache Synchronization Protocol (SCSP) [2] to synchronize the client information databases held by NHRP Servers (NHSs) within a LIS.
本文档描述了在LIS中分发NHRP服务的方法[1]。此方法使用服务器缓存同步协议（SCSP）[2]同步LIS中NHRP服务器（NHS）持有的客户端信息数据库。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [4].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[4]中的说明进行解释。
NHRP Clients (NHCs) register their existence and reachability information with NHRP Servers (NHSs). There may be multiple NHSs in a given Logical IP Subnet (LIS). NHCs do not necessarily register with all NHSs in a LIS; however, all NHCs need to be able to query at least one NHS about any NHC within the LIS. Thus, the contents of the NHS databases in a LIS need to be synchronized across the LIS. The Server Cache Synchronization Protocol (SCSP) solves the generalized server synchronization/cache-replication problem for distributed databases and thus SCSP may be applied to the NHS database synchronization problem within the LIS.
NHRP客户端（NHC）向NHRP服务器（NHS）注册其存在和可达性信息。给定的逻辑IP子网（LIS）中可能有多个NHS。NHC不一定向LIS中的所有NHS注册；然而，所有NHC都需要能够查询至少一个NHS关于LIS中任何NHC的信息。因此，LIS中NHS数据库的内容需要在整个LIS中同步。服务器缓存同步协议（SCSP）解决了分布式数据库的通用服务器同步/缓存复制问题，因此SCSP可应用于LIS中的NHS数据库同步问题。
SCSP is defined in two parts: the protocol independent part and the client/server protocol specific part. The protocol independent part is defined in [2] whereas this document will specify the client/server protocol specific part where NHRP is the client/server protocol.
SCSP由两部分定义：协议独立部分和客户机/服务器协议特定部分。协议独立部分在[2]中定义，而本文件将指定特定于客户端/服务器协议的部分，其中NHRP是客户端/服务器协议。
This document is separate from [2] because it was felt that it was desirable to allow the client/server protocol specific part specification for NHRP to progress independently from the protocol independent specification.
本文件与[2]分开，因为认为允许NHRP的客户机/服务器协议特定部分规范独立于协议独立规范进行是可取的。
All NHSs belonging to a Logical IP Subnet (LIS) [1] are said to belong to a Server Group (SG). An SG is identified by, not surprisingly, its SGID which is contained in a field in all SCSP packets. All SCSP packets contain a Protocol ID (PID) field as well. This PID field is set to 0x0002 to signify that SCSP synchronizing NHS databases as opposed to synchronizing some other protocol's databases (see Section B.2.0.1 of [2] for more details). In general, PIDs for SCSP will be assigned by IANA as described in Section C of [2]. In the case of NHRP, the client/server protocol specific specification was initially written at the same time as SCSP, and thus a PID=0x0002 was assigned by the author.
所有属于逻辑IP子网（LIS）[1]的NHS都被称为属于服务器组（SG）。毫不奇怪，SG由其SGID标识，该SGID包含在所有SCSP数据包的字段中。所有SCSP数据包也包含一个协议ID（PID）字段。此PID字段设置为0x0002，表示SCSP正在同步NHS数据库，而不是同步某些其他协议的数据库（有关更多详细信息，请参阅[2]的B.2.0.1节）。通常，SCSP的PID将由IANA分配，如[2]第C节所述。在NHRP的情况下，客户机/服务器协议特定规范最初与SCSP同时编写，因此作者分配了一个PID=0x0002。
SCSP places no topological requirements upon an NHRP SG. Obviously, however, the resultant graph of NHSs must span the set of NHSs to be synchronized. For more information about the client/server protocol independent part of SCSP, the reader is encouraged to see [2].
SCSP对NHRP SG无拓扑要求。然而，显然，NHS的结果图必须跨越要同步的NHS集。有关SCSP的客户机/服务器协议独立部分的更多信息，请读者参阅[2]。
When a SG is using SCSP for synchronization, an NHC will register with only one NHS, but the NHC MAY use any NHS in the SG. When an NHC wishes to leave a SG, the NHC MUST do one of the following: 1) the NHC MUST send an NHRP Purge Request for itself requesting a reply, and it MUST wait for an NHRP Purge Reply, 2) the NHC MUST keep the Request ID it used when registering itself in non-volatile RAM and use a Request ID larger than the one saved when re-registering, or 3) the NHC MUST not re-register for a time equal to the Holding Time specified in the previous registration. It is necessary to do one of the previous in order to prevent the unlikely case of race conditions from occurring during updated. In the case where method 2 is used, the NHS with which the NHC registered uses its ID as the OID and the Request ID from the NHC as the CSA Sequence Number in the CSA(S) Record.
当SG使用SCSP进行同步时，NHC将仅向一个NHS注册，但NHC可以使用SG中的任何NHS。当NHC希望离开SG时，NHC必须执行以下操作之一：1）NHC必须为自己发送NHRP清除请求，请求回复，并且必须等待NHRP清除回复，2）NHC必须保留在非易失性RAM中注册时使用的请求ID，并使用大于重新注册时保存的请求ID的请求ID，或3）NHC不得在与先前注册中规定的保持时间相等的时间内重新注册。为了防止更新期间出现不太可能出现的竞态情况，有必要执行上述操作之一。在使用方法2的情况下，NHC注册的NHS将其ID用作OID，并将来自NHC的请求ID用作CSA（S）记录中的CSA序列号。
CSA Records in SCSP contain a "Client/Server Protocol Specific Part" which contains the non-protocol independent information for a given server's cache entry.
SCSP中的CSA记录包含“客户端/服务器协议特定部分”，其中包含给定服务器缓存项的非协议独立信息。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Number | NHRP Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Snap | NHRP Vers Num | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Subnetwork Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Subnetwork Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Number | NHRP Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Snap | NHRP Vers Num | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Subnetwork Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Subnetwork Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following six fields contain values specified in the common header of the mandatory part of an NHRP Registration Request or NHRP Purge Request packet which caused the creation/deletion/modification/update/etc. of an NHS's cache entry.
以下六个字段包含NHRP注册请求或NHRP清除请求数据包强制部分的公共头中指定的值，该数据包导致NHS缓存项的创建/删除/修改/更新/等。
Address Family Number Defines the type of "link layer" addresses being carried. This number is taken from the 'address family number' list specified in [3]. This field is the same field which would be supplied in an NHRP packet in the ar$afn field.
地址族编号定义所承载的“链路层”地址的类型。此编号取自[3]中指定的“地址族编号”列表。该字段与ar$afn字段中的NHRP数据包中提供的字段相同。
NHRP Protocol Type This field is the same field which would be supplied in an NHRP packet in the ar$pro.type field.
NHRP协议类型此字段与ar$pro.Type字段中NHRP数据包中提供的字段相同。
Snap This field is the same field which would be supplied in an NHRP packet in the ar$pro.snap field.
Snap此字段与ar$pro.Snap字段中的NHRP数据包中提供的字段相同。
NHRP Vers Num This field indicates what version of generic address mapping and management protocol that is represented by this message. This field contains 0x01 for the NHRP protocol version 1. This field is the same field which would be supplied in an NHRP packet in the ar$op.version field.
NHRP Vers Num此字段指示此消息表示的通用地址映射和管理协议的版本。此字段包含NHRP协议版本1的0x01。该字段与ar$op.version字段中的NHRP数据包中提供的字段相同。
Flags Defined flags are as follows:
标志定义的标志如下：
0 1
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|A| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|A| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U This is the Uniqueness bit.
这是唯一性。
A When set, this bit specifies that the cache entry was created as a result of ATMARP client interaction with the NHS.
A设置时，该位指定缓存项是ATMARP客户端与NHS交互的结果。
Request ID This field contains the Request ID value placed in the cache entry of the NHS as a result of an NHRP Registration Request. This NHS is the NHS causing a synchronization event.
请求ID此字段包含由于NHRP注册请求而放置在NHS缓存条目中的请求ID值。该NHS是导致同步事件的NHS。
State This field contains a value which represents the new state of the client.
状态此字段包含表示客户端新状态的值。
0 - Client is registered and available. 1 - Client reregistered. 2 - Client has been purged. 3 - No such client data in server cache
0-客户端已注册且可用。1-客户端已重新注册。2-客户端已被清除。3-服务器缓存中没有此类客户端数据
Note that a time-out of a cache entry does not cause a CSA Record to be sent because, if everything is working properly then all NHSs have the cache entry timing out at the same time. Thus, the individual NHSs would take the appropriate actions necessary.
请注意，缓存项超时不会导致发送CSA记录，因为如果一切正常，则所有NHS都会同时超时缓存项。因此，各个国家卫生服务机构将采取必要的适当行动。
The following ten fields contain values specified in or derived from the CIE of an NHRP Registration Request or NHRP Purge Request packet which caused the creation/deletion/modification/update/etc. of an NHS's cache entry.
以下十个字段包含NHRP注册请求或NHRP清除请求数据包的CIE中指定或派生的值，该数据包导致NHS缓存项的创建/删除/修改/更新/等。
Prefix Length This field contains the internetwork layer address prefix length value covered by the cache entry being synchronized.
前缀长度此字段包含正在同步的缓存项所覆盖的网络层地址前缀长度值。
Maximum Transmission Unit This field contains a value supplied by or derived from information in the CIE of the NHRP Registration Request packet.
最大传输单位该字段包含由NHRP注册请求数据包的CIE中的信息提供或派生的值。
Holding Time The Holding Time field specifies the number of seconds remaining for which the Next Hop NBMA information specified in the CIE of the NHRP Registration Request is considered to be valid by the NHS initiating the synchronization event.
保持时间保持时间字段指定NHRP注册请求的CIE中指定的下一跳NBMA信息被NHS启动同步事件视为有效的剩余秒数。
Cli Addr T/L Type & length of next hop NBMA address (see [1]).
Cli Addr下一跳NBMA地址的T/L类型和长度（请参见[1]）。
Cli SAddr T/L Type & length of next hop NBMA subaddress (see [1]).
Cli SADD下一跳NBMA子地址的T/L类型和长度（参见[1]）。
Cli Proto Len This field holds the length in octets of the Client Protocol Address.
Cli Proto Len此字段保存客户端协议地址的长度（以八位字节为单位）。
Preference This field specifies the preference value for use of the next hop NBMA information specified.
首选项此字段指定使用指定的下一跳NBMA信息的首选项值。
Client NBMA Address This is the client's NBMA address.
客户NBMA地址这是客户的NBMA地址。
Client NBMA SubAddress This is the client's NBMA subaddress.
客户端NBMA子地址这是客户端的NBMA子地址。
Client Protocol Address This is the client's internetworking layer address.
客户端协议地址这是客户端的互连层地址。
The following sections give values for fields of the SCSP Protocol Independent Part of the various SCSP messages.
以下各节给出了各种SCSP消息的SCSP协议独立部分的字段值。
Protocol ID = 0x0002 Sender ID Len = 0x04 Recvr ID Len = 0x04
协议ID=0x0002发送方ID Len=0x04 Recvr ID Len=0x04
See Section B.2.0.1 of [2] for a detailed description of these fields.
有关这些字段的详细说明，请参见[2]第B.2.0.1节。
Cache Key Len = 0x04 Orig ID Len = 0x04
缓存键Len=0x04原始ID Len=0x04
See Section B.2.0.2 of [2] for a detailed description of these fields.
有关这些字段的详细说明，请参见[2]第B.2.0.2节。
Relevant security considerations are documented in [1] and [2].
[1]和[2]中记录了相关的安全注意事项。
References
工具书类
[1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[1] Luciani，J.，Katz，D.，Piscitello，D.，Cole，B.，和N.Doraswamy，“NMBA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[2] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[2] Luciani，J.，Armitage，G.，Halpern，J.，和N.Doraswamy，“服务器缓存同步协议（SCSP）”，RFC 2334，1998年4月。
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[3] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Acknowledgments
致谢
I would like to thank (in no particular order) Maxine Burns of ISR and Joel Halpern of Newbridge. I would also like to thank the members of the ION working group of the IETF, whose review and discussion of this document has been invaluable.
我要感谢（没有特别顺序）ISR的Maxine Burns和新桥的Joel Halpern。我还要感谢IETF离子工作组的成员，他们对本文件的审查和讨论非常宝贵。
Author's Address
作者地址
James V. Luciani Bay Networks, Inc. 3 Federal Street, BL3-03 Billerica, MA 01821
詹姆斯诉卢西亚尼湾网络公司，马萨诸塞州比尔里卡联邦街3号，BL3-03，邮编01821
Phone: +1-978-916-4734
EMail: luciani@baynetworks.com
Phone: +1-978-916-4734
EMail: luciani@baynetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。