As per Relevance of the word document, we have this rfc below:
Network Working Group J.
Request for Comments: 2335 Bay
Category: Standards Track April 1998
A Distributed NHRP Service Using
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document describes a method for distributing an NHRP
within a LIS [1]. This method uses the Server Cache
Protocol (SCSP) [2] to synchronize the client information
held by NHRP Servers (NHSs) within a LIS
1.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [4].
NHRP Clients (NHCs) register their existence and
information with NHRP Servers (NHSs). There may be multiple NHSs
a given Logical IP Subnet (LIS). NHCs do not necessarily
with all NHSs in a LIS; however, all NHCs need to be able to query
least one NHS about any NHC within the LIS. Thus, the contents
the NHS databases in a LIS need to be synchronized across the LIS
The Server Cache Synchronization Protocol (SCSP) solves
generalized server synchronization/cache-replication problem
distributed databases and thus SCSP may be applied to the
database synchronization problem within the LIS
Luciani Standards Track [Page 1]
RFC 2335 NHRP Using SCSP April 1998
SCSP is defined in two parts: the protocol independent part and
client/server protocol specific part. The protocol independent
is defined in [2] whereas this document will specify
client/server protocol specific part where NHRP is the client/
protocol
This document is separate from [2] because it was felt that it
desirable to allow the client/server protocol specific
specification for NHRP to progress independently from the
independent specification
2.
All NHSs belonging to a Logical IP Subnet (LIS) [1] are said
belong to a Server Group (SG). An SG is identified by,
surprisingly, its SGID which is contained in a field in all
packets. All SCSP packets contain a Protocol ID (PID) field as well
This PID field is set to 0x0002 to signify that SCSP
NHS databases as opposed to synchronizing some other protocol'
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
[2]. In the case of NHRP, the client/server protocol
specification was initially written at the same time as SCSP,
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
synchronized. For more information about the client/server
independent part of SCSP, the reader is encouraged to see [2].
When a SG is using SCSP for synchronization, an NHC will
with only one NHS, but the NHC MAY use any NHS in the SG. When
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
reply, and it MUST wait for an NHRP Purge Reply, 2) the NHC MUST
the Request ID it used when registering itself in non-volatile
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
Time specified in the previous registration. It is necessary to
one of the previous in order to prevent the unlikely case of
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
and the Request ID from the NHC as the CSA Sequence Number in
CSA(S) Record
Luciani Standards Track [Page 2]
RFC 2335 NHRP Using SCSP April 1998
3. Format of the CSA Record NHRP Specific
CSA Records in SCSP contain a "Client/Server Protocol Specific Part
which contains the non-protocol independent information for a
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
header of the mandatory part of an NHRP Registration Request or
Purge Request packet which caused
creation/deletion/modification/update/etc. of an NHS's cache entry
Address Family
Defines the type of "link layer" addresses being carried.
number is taken from the 'address family number' list specified
[3]. This field is the same field which would be supplied in
NHRP packet in the ar$afn field
NHRP Protocol
This field is the same field which would be supplied in an
packet in the ar$pro.type field
This field is the same field which would be supplied in an
packet in the ar$pro.snap field
Luciani Standards Track [Page 3]
RFC 2335 NHRP Using SCSP April 1998
NHRP Vers
This field indicates what version of generic address mapping
management protocol that is represented by this message.
field contains 0x01 for the NHRP protocol version 1. This field
the same field which would be supplied in an NHRP packet in
ar$op.version field
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the Uniqueness bit
When set, this bit specifies that the cache entry was
as a result of ATMARP client interaction with the NHS
Request
This field contains the Request ID value placed in the cache
of the NHS as a result of an NHRP Registration Request. This
is the NHS causing a synchronization event
This field contains a value which represents the new state of
client
0 - Client is registered and available
1 - Client reregistered
2 - Client has been purged
3 - No such client data in server
Note that a time-out of a cache entry does not cause a CSA
to be sent because, if everything is working properly then all
have the cache entry timing out at the same time. Thus,
individual NHSs would take the appropriate actions necessary
The following ten fields contain values specified in or derived
the CIE of an NHRP Registration Request or NHRP Purge Request
which caused the creation/deletion/modification/update/etc. of
NHS's cache entry
Luciani Standards Track [Page 4]
RFC 2335 NHRP Using SCSP April 1998
Prefix
This field contains the internetwork layer address prefix
value covered by the cache entry being synchronized
Maximum Transmission
This field contains a value supplied by or derived from
in the CIE of the NHRP Registration Request packet
Holding
The Holding Time field specifies the number of seconds
for which the Next Hop NBMA information specified in the CIE of
NHRP Registration Request is considered to be valid by the
initiating the synchronization event
Cli Addr T/
Type & length of next hop NBMA address (see [1]).
Cli SAddr T/
Type & length of next hop NBMA subaddress (see [1]).
Cli Proto
This field holds the length in octets of the Client
Address
This field specifies the preference value for use of the next
NBMA information specified
Client NBMA
This is the client's NBMA address
Client NBMA
This is the client's NBMA subaddress
Client Protocol
This is the client's internetworking layer address
4. Values for SCSP Protocol Independent
The following sections give values for fields of the SCSP
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
Luciani Standards Track [Page 5]
RFC 2335 NHRP Using SCSP April 1998
See Section B.2.0.1 of [2] for a detailed description of
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
fields
5. Security
Relevant security considerations are documented in [1] and [2].
[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, "
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
Levels", BCP 14, RFC 2119, March 1997.
I would like to thank (in no particular order) Maxine Burns of
and Joel Halpern of Newbridge. I would also like to thank
members of the ION working group of the IETF, whose review
discussion of this document has been invaluable
Author's
James V.
Bay Networks, Inc
3 Federal Street, BL3-03
Billerica, MA 01821
Phone: +1-978-916-4734
EMail: luciani@baynetworks.
Luciani Standards Track [Page 6]
RFC 2335 NHRP Using SCSP April 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Luciani Standards Track [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
