NHRP over SCSP: A Distributed NHRP Service Using SCSP
How several NHRP servers in one subnet keep their client databases in step using SCSP.
Luciani, J., "A Distributed NHRP Service Using SCSP", RFC 2335, DOI 10.17487/RFC2335, April 1998, <https://www.rfc-editor.org/info/rfc2335>.
@misc{rfc2335,
series = {Request for Comments},
number = 2335,
howpublished = {RFC 2335},
publisher = {RFC Editor},
doi = {10.17487/RFC2335},
url = {https://www.rfc-editor.org/info/rfc2335},
author = {J. Luciani},
title = {{A Distributed NHRP Service Using SCSP}},
pagetotal = 7,
year = 1998,
month = apr,
} RFC text
Contents
Network Working Group J. Luciani
Request for Comments: 2335 Bay Networks
Category: Standards Track April 1998
A Distributed NHRP Service Using SCSP
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.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
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.
1. Introduction
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].
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.
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.
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. Overview
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.
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].
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.
3. Format of the CSA Record NHRP Specific Part
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.
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.
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.
NHRP Protocol Type
This field is the same field which would be supplied in an NHRP
packet in the ar$pro.type field.
Snap
This field is the same field which would be supplied in an NHRP
packet in the ar$pro.snap field.
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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
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.
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.
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.
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.
Cli Addr T/L
Type & length of next hop NBMA address (see [1]).
Cli SAddr T/L
Type & length of next hop NBMA subaddress (see [1]).
Cli Proto Len
This field holds the length in octets of the Client Protocol
Address.
Preference
This field specifies the preference value for use of the next hop
NBMA information specified.
Client NBMA Address
This is the client's NBMA address.
Client NBMA SubAddress
This is the client's NBMA subaddress.
Client Protocol Address
This is the client's internetworking layer address.
4. Values for SCSP Protocol Independent Part
The following sections give values for fields of the SCSP Protocol
Independent Part of the various SCSP messages.
4.1 Values for the SCSP "Mandatory Common Part"
Protocol ID = 0x0002
Sender ID Len = 0x04
Recvr ID Len = 0x04
See Section B.2.0.1 of [2] for a detailed description of these
fields.
4.2 Values for the SCSP "CSAS Record"
Cache Key Len = 0x04
Orig ID Len = 0x04
See Section B.2.0.2 of [2] for a detailed description of these
fields.
5. Security Considerations
Relevant security considerations are documented in [1] and [2].
References
[1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332,
April 1998.
[2] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server
Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
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.
Author's Address
James V. Luciani
Bay Networks, Inc.
3 Federal Street, BL3-03
Billerica, MA 01821
Phone: +1-978-916-4734
EMail: luciani@baynetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
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.
AI ELI5
On this page
§1The Synchronization Problem
NHRP Clients (NHCs) register their existence and reachability with NHRP Servers (NHSs). A Logical IP Subnet (LIS) may have several NHSs. Clients need not register with all of them, but every client must be able to query at least one NHS about any client in the LIS. The databases of the servers therefore have to be synchronized across the LIS.
The Server Cache Synchronization Protocol (SCSP, RFC 2334) solves the generalized server synchronization problem for distributed databases. It has a protocol-independent part, defined in RFC 2334, and a client/server protocol specific part. This document specifies the second part, with NHRP (RFC 2332) as the client/server protocol. It is separate so that it could progress independently of the protocol-independent specification. The key words MUST, SHOULD and MAY are used as in RFC 2119.
Several helpers each keep a list of who is where. They must all keep the same list, and a standard way of sharing updates does that job.
§2Server Groups and Client Registration
All NHSs in a LIS form a Server Group (SG). The group is identified by its SGID, carried in every SCSP packet. Every SCSP packet also has a Protocol ID (PID) field, which is set to 0x0002 to show that SCSP is synchronizing NHS databases. The RFC notes that this PID was assigned by the author because the NHRP specification was written at the same time as SCSP; PIDs are in general assigned by IANA.
SCSP puts no topological requirement on the group, though the resulting graph of NHSs must span all the servers to be synchronized.
With SCSP in use, an NHC registers with only one NHS, but it MAY use any NHS in the group.
All the helpers in one neighbourhood are one team with a team number. Each visitor signs in with just one helper, but can ask any helper a question.
§3Leaving the Server Group
To prevent unlikely race conditions during updates, an NHC that wants to leave a group MUST do one of the following:
- send an NHRP Purge Request for itself, asking for a reply, and wait for the NHRP Purge Reply;
- keep the Request ID it used when registering in non-volatile RAM, and use a larger Request ID when it re-registers;
- not re-register for a time equal to the Holding Time given in its previous registration.
When the second method is used, the NHS the client registered with uses its own ID as the OID and the client's Request ID as the CSA Sequence Number in the CSA(S) Record.
When you leave the team, you have to make sure everyone knows. Either you tell them you are gone, or you write down your last ticket number so the next one is bigger, or you wait long enough that your old sign-in has expired.
§4The NHRP Part of the CSA Record
Each SCSP CSA Record carries a client/server protocol specific part with one server's cache entry. For NHRP, the first six fields copy values from the common header of the NHRP Registration Request or Purge Request that created, deleted or changed the cache entry:
Address Family Number, the type of link layer addresses carried (same asar$afn);NHRP Protocol Type(same asar$pro.type) andSnap(same asar$pro.snap);NHRP Vers Num, which is0x01for NHRP version 1;Flags, with theUbit (the Uniqueness bit) and theAbit, which is set when the entry came from ATMARP client interaction with the NHS;Request ID, the value placed in the cache entry as a result of the Registration Request, by the NHS causing the synchronization event.
The State field then gives the client's new state. Next come ten fields taken from, or derived from, the CIE of the same request: Prefix Length, Maximum Transmission Unit, Holding Time (the seconds remaining that the NHS starting the event considers the next hop NBMA information valid), Cli Addr T/L, Cli SAddr T/L, Cli Proto Len, Preference, and the variable-length client NBMA address, NBMA subaddress and protocol address.
Each update is like a small card that copies the details from the sign-in form: who the visitor is, where to reach them, how long the entry is good for, and whether they just arrived or left.
§5Client State Values and Fixed SCSP Fields
The State field takes one of four values. A cache entry that merely times out does not cause a CSA Record to be sent: if everything works, all NHSs time the entry out at the same moment and act on their own.
For the protocol-independent part, the RFC fixes these values: in the Mandatory Common Part, Protocol ID 0x0002, Sender ID Len 0x04 and Recvr ID Len 0x04; in the CSAS Record, Cache Key Len 0x04 and Orig ID Len 0x04. Their meaning is described in Section B.2.0.1 and B.2.0.2 of RFC 2334.
A visitor can be in one of four situations, like checked in, checked in again, checked out, or never heard of. Running out of time is not announced, because every helper already knows the clock.
- 0Registered — Client is registered and available.
- 1Reregistered — Client reregistered.
- 2Purged — Client has been purged.
- 3No such client — No such client data in server cache.
§6Security Considerations
The RFC adds no security text of its own. It says that the relevant security considerations are documented in RFC 2332 (NHRP) and RFC 2334 (SCSP).
This note does not add new safety rules. It points to the rules in the two bigger documents.