idnits 2.17.1 draft-ietf-ion-scsp-nhrp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1998) is 9447 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-12 == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-02 ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internetworking Over NBMA James V. Luciani 3 INTERNET-DRAFT (Bay Networks) 4 Expires June 1998 6 A Distributed NHRP Service Using SCSP 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 27 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 28 document, are to be interpreted as described in [4]. 30 Abstract 32 This document describes a method for distributing an NHRP service 33 within a LIS[1]. This method uses the Server Cache Synchronization 34 Protocol (SCSP)[2] to synchronize the client information databases 35 held by NHRP Servers (NHSs) within a LIS. 37 1. Introduction 39 NHRP Clients (NHCs) register their existence and reachability 40 information with NHRP Servers (NHSs). There may be multiple NHSs in 41 a given Logical IP Subnet (LIS). NHCs do not necessarily register 42 with all NHSs in a LIS; however, all NHCs need to be able to query at 43 least one NHS about any NHC within the LIS. Thus, the contents of 44 the NHS databases in a LIS need to be synchronized across the LIS. 45 The Server Cache Synchronization Protocol (SCSP) solves the 46 generalized server synchronization/cache-replication problem for 47 distributed databases and thus SCSP may be applied to the NHS 48 database synchronization problem within the LIS. 50 SCSP is defined in two parts: the protocol independent part and the 51 client/server protocol specific part. The protocol independent part 52 is defined in [2] whereas this document will specify the 53 client/server protocol specific part where NHRP is the client/server 54 protocol. 56 This document is separate from [2] because it was felt that it was 57 desirable to allow the client/server protocol specific part 58 specification for NHRP to progress independently from the protocol 59 independent specification. 61 2. Overview 63 All NHSs belonging to a Logical IP Subnet (LIS)[1] are said to belong 64 to a Server Group (SG). An SG is identified by, not surprisingly, 65 its SGID which is contained in a field in all SCSP packets. All SCSP 66 packets contain a Protocol ID (PID) field as well. This PID field is 67 set to 0x0002 to signify that SCSP synchronizing NHS databases as 68 opposed to synchronizing some other protocol's databases (see Section 69 B.2.0.1 of [2] for more details). In general, PIDs for SCSP will be 70 assigned by IANA as described in Section C of [2]. In the case of 71 NHRP, the client/server protocol specific specification was initially 72 written at the same time as SCSP, and thus a PID=0x0002 was assigned 73 by the author. 75 SCSP places no topological requirements upon an NHRP SG. Obviously, 76 however, the resultant graph of NHSs must span the set of NHSs to be 77 synchronized. For more information about the client/server protocol 78 independent part of SCSP, the reader is encouraged to see [2]. 80 When a SG is using SCSP for synchronization, an NHC will register 81 with only one NHS, but the NHC MAY use any NHS in the SG. When an 82 NHC wishes to leave a SG, the NHC MUST do one of the following: 1) 83 the NHC MUST send an NHRP Purge Request for itself requesting a 84 reply, and it MUST wait for an NHRP Purge Reply, 2) the NHC MUST keep 85 the Request ID it used when registering itself in non-volatile RAM 86 and use a Request ID larger than the one saved when re-registering, 87 or 3) the NHC MUST not re-register for a time equal to the Holding 88 Time specified in the previous registration. It is necessary to do 89 one of the previous in order to prevent the unlikely case of race 90 conditions from occurring during updated. In the case where method 2 91 is used, the NHS with which the NHC registered uses its ID as the OID 92 and the Request ID from the NHC as the CSA Sequence Number in the 93 CSA(S) Record. 95 3. Format of the CSA Record NHRP Specific Part 97 CSA Records in SCSP contain a "Client/Server Protocol Specific Part" 98 which contains the non-protocol independent information for a given 99 server's cache entry. 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Address Family Number | NHRP Protocol Type | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Snap | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Snap | NHRP Vers Num | Flags | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Request ID | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | State | Prefix Length | unused | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Maximum Transmission Unit | Holding Time | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Client Subnetwork Address (variable length) | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Client Subnetwork Subaddress (variable length) | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Client Protocol Address (variable length) | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 The following six fields contain values specified in the common 126 header of the mandatory part of an NHRP Registration Request or NHRP 127 Purge Request packet which caused the 128 creation/deletion/modification/update/etc. of an NHS's cache entry. 130 Address Family Number 131 Defines the type of "link layer" addresses being carried. This 132 number is taken from the 'address family number' list specified in 133 [3]. This field is the same field which would be supplied in an 134 NHRP packet in the ar$afn field. 136 NHRP Protocol Type 137 This field is the same field which would be supplied in an NHRP 138 packet in the ar$pro.type field. 140 Snap 141 This field is the same field which would be supplied in an NHRP 142 packet in the ar$pro.snap field. 144 NHRP Vers Num 145 This field indicates what version of generic address mapping and 146 management protocol that is represented by this message. This 147 field contains 0x01 for the NHRP protocol version 1. This field is 148 the same field which would be supplied in an NHRP packet in the 149 ar$op.version field. 151 Flags 152 Defined flags are as follows: 154 0 1 155 0 1 156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 |U|A| unused | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 U 162 This is the Uniqueness bit. 164 A 165 When set, this bit specifies that the cache entry was created 166 as a result of ATMARP client interaction with the NHS. 168 Request ID 169 This field contains the Request ID value placed in the cache entry 170 of the NHS as a result of an NHRP Registration Request. This NHS 171 is the NHS causing a synchronization event. 173 State 174 This field contains a value which represents the new state of the 175 client. 177 0 - Client is registered and available. 178 1 - Client reregistered. 179 2 - Client has been purged. 180 3 - No such client data in server cache 182 Note that a time-out of a cache entry does not cause a CSA Record 183 to be sent because, if everything is working properly then all NHSs 184 have the cache entry timing out at the same time. Thus, the 185 individual NHSs would take the appropriate actions necessary. 187 The following ten fields contain values specified in or derived from 188 the CIE of an NHRP Registration Request or NHRP Purge Request packet 189 which caused the creation/deletion/modification/update/etc. of an 190 NHS's cache entry. 192 Prefix Length 193 This field contains the internetwork layer address prefix length 194 value covered by the cache entry being synchronized. 196 Maximum Transmission Unit 197 This field contains a value supplied by or derived from information 198 in the CIE of the NHRP Registration Request packet. 200 Holding Time 201 The Holding Time field specifies the number of seconds remaining 202 for which the Next Hop NBMA information specified in the CIE of the 203 NHRP Registration Request is considered to be valid by the NHS 204 initiating the synchronization event. 206 Cli Addr T/L 207 Type & length of next hop NBMA address (see [1]). 209 Cli SAddr T/L 210 Type & length of next hop NBMA subaddress (see [1]). 212 Cli Proto Len 213 This field holds the length in octets of the Client Protocol 214 Address. 216 Preference 217 This field specifies the preference value for use of the next hop 218 NBMA information specified. 220 Client NBMA Address 221 This is the client's NBMA address. 223 Client NBMA SubAddress 224 This is the client's NBMA subaddress. 226 Client Protocol Address 227 This is the client's internetworking layer address. 229 4. Values for SCSP Protocol Independent Part 231 The following sections give values for fields of the SCSP Protocol 232 Independent Part of the various SCSP messages. 234 4.1 Values for the SCSP "Mandatory Common Part" 236 Protocol ID = 0x0002 237 Sender ID Len = 0x04 238 Recvr ID Len = 0x04 240 See Section B.2.0.1 of [2] for a detailed description of these 241 fields. 243 4.2 Values for the SCSP "CSAS Record" 245 Cache Key Len = 0x04 246 Orig ID Len = 0x04 248 See Section B.2.0.2 of [2] for a detailed description of these 249 fields. 251 5. Security Considerations 253 Relevant security considerations are documented in [1] and [2]. 255 References 257 [1] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello, 258 Cole, draft-ietf-rolc-nhrp-12.txt. 260 [2] "Server Cache Synchronization Protocol", Luciani, Armitage, Halpern, 261 draft-ietf-ion-scsp-02.txt. 263 [3] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 265 [4] "Key words for use in RFCs to Indicate Requirement Levels", 266 S. Bradner, RFC 2119. 268 Acknowledgments 269 I would like to thank (in no particular order) Maxine Burns of ISR 270 and Joel Halpern of Newbridge. I would also like to thank the 271 members of the ION working group of the IETF, whose review and 272 discussion of this document has been invaluable. 274 Author's Address 276 James V. Luciani 277 Bay Networks, Inc. 278 3 Federal Street, BL3-04 279 Billerica, MA 01821 280 phone: +1-508-916-4734 281 email: luciani@baynetworks.com