RFC 2335

A Distributed NHRP Service Using SCSP

📅 published April 1998, from ietf

RFC 2335: A Distributed NHRP Service Using SCSP ✨

Network Working Group 🎀 Request for Comments: 2335 🎀 Category: Standards Track 🎀 Date: April 1998

Author: J. Luciani (James V. Luciani) of Bay Networks 💖 The header doesn't list anything this RFC obsoletes or updates.

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 (C) The Internet Society (1998). All Rights Reserved.

Abstract 🌸

Okay so this doc describes a way to spread an NHRP service around inside a LIS [1]. It uses the Server Cache Synchronization Protocol (SCSP) [2] to keep the client info databases held by NHRP Servers (NHSs) within a LIS in sync. Main character energy 💅

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 info with NHRP Servers (NHSs). A LIS can have multiple NHSs ✨ NHCs don't have to register with every NHS in a LIS, BUT every NHC needs to be able to ask at least one NHS about any NHC in the LIS. So the contents of the NHS databases in a LIS need to be synced across the whole LIS. That's where SCSP comes in 🔥 It solves the general server synchronization and cache-replication problem for distributed databases, so SCSP can be used for the NHS database sync problem inside 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], and this document covers the client/server protocol specific part, where NHRP is the client/server protocol.

This doc is separate from [2] because it was felt that it was desirable to let the NHRP client/server protocol specific part progress independently from the protocol independent spec. Honestly, it's giving modular 💜

2. Overview 🧚

All NHSs in a Logical IP Subnet (LIS) [1] belong to a Server Group (SG). An SG is identified by, not surprisingly, its SGID, which sits in a field in all SCSP packets. All SCSP packets also have a Protocol ID (PID) field. This PID field is set to 0x0002 to signal that SCSP is syncing NHS databases, as opposed to syncing some other protocol's databases (see Section B.2.0.1 of [2] for more details). In general, PIDs for SCSP get assigned by IANA as described in Section C of [2]. For NHRP, the client/server protocol specific spec was written at the same time as SCSP, so the author assigned PID=0x0002 ✨

SCSP places no topological requirements on an NHRP SG. Obviously, though, the resulting graph of NHSs has to span the set of NHSs being synced. For more info about the client/server protocol independent part of SCSP, the reader is encouraged to check out [2] 📖

When an SG is using SCSP for sync, an NHC registers with only one NHS, but the NHC MAY use any NHS in the SG. 💅 When an NHC wants to leave an SG, the NHC MUST do one of the following:

  1. the NHC MUST send an NHRP Purge Request for itself asking for 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.

You have to do one of the previous in order to prevent the unlikely case of race conditions from happening during updated 🙈 When method 2 is used, the NHS the NHC registered with 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 holds the non-protocol-independent info for a given server's cache entry. Here's the layout 👑

  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 hold values from the common header of the mandatory part of an NHRP Registration Request or NHRP Purge Request packet, the one that 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]. It's the same field that would be supplied in an NHRP packet in the ar$afn field.

NHRP Protocol Type This is the same field that would be supplied in an NHRP packet in the ar$pro.type field.

Snap This is the same field that would be supplied in an NHRP packet in the ar$pro.snap field.

NHRP Vers Num This field says which version of the generic address mapping and management protocol this message represents. It contains 0x01 for NHRP protocol version 1. It's the same field that would be supplied in an NHRP packet in the ar$op.version field.

Flags Here are the defined flags 🎀

    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 says the cache entry was created because of ATMARP client interaction with the NHS.

Request ID This field holds the Request ID value that was put in the NHS's cache entry because of an NHRP Registration Request. This NHS is the one causing a synchronization event. 🌈

State This field holds a value that 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, all NHSs have the cache entry timing out at the same time. So the individual NHSs take whatever actions they need on their own. ⭐

The following ten fields hold values specified in or derived from the CIE of an NHRP Registration Request or NHRP Purge Request packet, the one that caused the creation/deletion/modification/update/etc. of an NHS's cache entry. 💜

Prefix Length This field holds the internetwork layer address prefix length covered by the cache entry being synchronized.

Maximum Transmission Unit This field holds a value supplied by, or derived from, info in the CIE of the NHRP Registration Request packet.

Holding Time The Holding Time field gives the number of seconds remaining for which the Next Hop NBMA info in the CIE of the NHRP Registration Request is considered valid by the NHS starting the synchronization event. ⏳

Cli Addr T/L Type and length of the next hop NBMA address (see [1]).

Cli SAddr T/L Type and length of the next hop NBMA subaddress (see [1]).

Cli Proto Len This field holds the length, in octets, of the Client Protocol Address.

Preference This field gives the preference value for using the next hop NBMA info 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 🍓

These sections give values for fields in the SCSP Protocol Independent Part of the various SCSP messages. Let's go 🔥

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]. Read those carefully, bestie, this part is serious 💀

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. Such a squad 🌸

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

Okay bestie, this is the legal bit at the very end, but it's actually pretty simple. The Internet Society owns the copyright: Copyright (C) The Internet Society (1998). All Rights Reserved. 📜

You're allowed to copy this document and pass it around, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no real restrictions 💖. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 🎀.

The document itself can't be changed in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations 🙅‍♀️. There are two exceptions. First, you can change it when you're developing Internet standards, but then you have to follow the copyright procedures in the Internet Standards process 🔥. Second, you can change it to translate it into another language besides English 🌸.

These permissions are perpetual, which means they're forever. The Internet Society, its successors, and its assigns can't take them back 🦋✨.

Now the disclaimer, which is a bit dramatic but important 😭. This document and the info in it are 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. So basically, they're not promising it's perfect or that it'll work for your exact use case 💀. Use it at your own risk, babe 🫶.

📦 where this page comes from