A Distributed NHRP Service Using SCSP
RFC 2335

Document Type RFC - Proposed Standard (April 1998; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2335 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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

   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.

Luciani                     Standards Track                     [Page 1]
RFC 2335                    NHRP Using SCSP                   April 1998

   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

   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.

Luciani                     Standards Track                     [Page 2]
RFC 2335                    NHRP Using SCSP                   April 1998

3.  Format of the CSA Record NHRP Specific Part

   CSA Records in SCSP contain a "Client/Server Protocol Specific Part"
Show full document text