idnits 2.17.1 draft-ietf-ion-scsp-02.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-23) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 32 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The SCSP Vendor-Private Extension is carried in SCSP packets to convey vendor-private information between an LS and a DCS in the same SG and is thus of limited use. If a finer granularity (e.g., CSA record level) is desired then then given client/server protocol specific SCSP document MUST define such a mechanism. Obviously, however, such a protocol specific mechanism might look exactly like this extension. The Vendor Private Extension MAY NOT appear more than once in an SCSP packet for a given Vendor ID value. -- 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 (March 1998) is 9536 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) == Unused Reference: '5' is defined on line 1672, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1675, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1577 (ref. '1') (Obsoleted by RFC 2225) == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-12 ** Obsolete normative reference: RFC 1583 (ref. '3') (Obsoleted by RFC 2178) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1700 (ref. '7') (Obsoleted by RFC 3232) == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-nhrp-02 -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '11') Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internetworking Over NBMA James V. Luciani 2 INTERNET-DRAFT (Bay Networks) 3 Grenville Armitage 4 (Bellcore) 5 Joel Halpern 6 (Newbridge) 7 Expires March 1998 9 Server Cache Synchronization Protocol (SCSP) 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 30 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 31 document, are to be interpreted as described in [10]. 33 Abstract 35 This document describes the Server Cache Synchronization Protocol 36 (SCSP) and is written in terms of SCSP's use within Non Broadcast 37 Multiple Access (NBMA) networks; although, a somewhat straight 38 forward usage is applicable to BMA networks. SCSP attempts to solve 39 the generalized cache synchronization/cache-replication problem for 40 distributed protocol entities. However, in this document, SCSP is 41 couched in terms of the client/server paradigm in which distributed 42 server entities, which are bound to a Server Group (SG) through some 43 means, wish to synchronize the contents (or a portion thereof) of 44 their caches which contain information about the state of clients 45 being served. 47 1. Introduction 49 It is perhaps an obvious goal for any protocol to not limit itself to 50 a single point of failure such as having a single server in a 51 client/server paradigm. Even when there are redundant servers, there 52 still remains the problem of cache synchronization; i.e., when one 53 server becomes aware of a change in state of cache information then 54 that server must propagate the knowledge of the change in state to 55 all servers which are actively mirroring that state information. 56 Further, this must be done in a timely fashion without putting undo 57 resource strains on the servers. Assuming that the state information 58 kept in the server cache is the state of clients of the server, then 59 in order to minimize the burden placed upon the client it is also 60 highly desirable that clients need not have complete knowledge of all 61 servers which they may use. However, any mechanism for 62 synchronization should not preclude a client from having access to 63 several (or all) servers. Of course, any solution must be reasonably 64 scalable, capable of using some auto-configuration service, and lend 65 itself to a wide range of authentication methodologies. 67 This document describes the Server Cache Synchronization Protocol 68 (SCSP). SCSP solves the generalized server synchronization/cache- 69 replication problem while addressing the issues described above. 70 SCSP synchronizes caches (or a portion of the caches) of a set of 71 server entities of a particular protocol which are bound to a Server 72 Group (SG) through some means (e.g., all NHRP servers belonging to a 73 Logical IP Subnet (LIS)[1]). The client/server protocol which a 74 particular server uses is identified by a Protocol ID (PID). SGs are 75 identified by an ID which, not surprisingly, is called a SGID. Note, 76 therefore, that the combination PID/SGID identifies both the 77 client/server protocol for which the servers of the SG are being 78 synchronized as well as the instance of that protocol. This implies 79 that multiple instances of the same protocol may be in operation at 80 the same time and have their servers synchronized independently of 81 each other. An example of types of information that must be 82 synchronized can be seen in NHRP[2] using IP where the information 83 includes the registered clients' IP to NBMA mappings in the SG LIS. 85 The simplest way to understand SCSP is to understand that the 86 algorithm used here is quite similar to that used in OSPF[3]. In 87 fact, if the reader wishes to understand more details of the 88 tradeoffs and reliability aspects of SCSP, they should refer to the 89 Hello, Database Synchronization, and Flooding Procedures in OSPF [3]. 91 As described later, the protocol goes through three phases. The 92 first, very brief phase is the hello phase where two devices 93 determine that they can talk to each other. Following that is 94 database synchronization. The operation of SCSP assumes that up to 95 the point when new information is received, two entities have the 96 same data available. The database synchronization phase ensures 97 this. 99 In database synchronization, the two neighbors exchange summary 100 information about each entry in their database. Summaries are used 101 since the database itself is potentially quite large. Based on these 102 summaries, the neighbors can determine if there is information that 103 each needs from the other. If so, that is requested and provided. 104 Therefore, at the end of this phase of operation, the two neighbors 105 have the same data in their databases. 107 After that, the entities enter and remain in flooding state. In 108 flooding state, any new information that is learned is sent to all 109 neighbors, except the one (if any) that the information was learned 110 from. This causes all new information in the system to propagate to 111 all nodes, thus restoring the state that everyone knows the same 112 thing. Flooding is done reliably on each link, so no pattern of low 113 rate packet loss will cause a disruption. (Obviously, a sufficiently 114 high rate of packet loss will cause the entire neighbor relationship 115 to come down, but if the link does not work, then that is what one 116 wants.) 118 Because the database synchronization procedure is run whenever a link 119 comes up, the system robustly ensures that all participating nodes 120 have all available information. It properly recovers from 121 partitions, and copes with other failures. 123 The SCSP specification is not useful as a stand alone protocol. It 124 must be coupled with the use of an SCSP Protocol Specific 125 specification which defines how a given protocol would make use of 126 the synchronization primitives supplied by SCSP. Such specification 127 will be done in separate documents; e.g., [8][9]. 129 2. Overview 131 SCSP places no topological requirements upon the SG. Obviously, 132 however, the resultant graph must span the set of servers to be 133 synchronized. SCSP borrows its cache distribution mechanism from the 134 link state protocols [3,4]. However, unlike those technologies, 135 there is no mandatory Shortest Path First (SPF) calculation, and SCSP 136 imposes no additional memory requirements above and beyond that which 137 is required to save the cached information which would exist 138 regardless of the synchronization technology. 140 In order to give a frame of reference for the following discussion, 141 the terms Local Server (LS), Directly Connected Server (DCS), and 142 Remote Server (RS) are introduced. The LS is the server under 143 scrutiny; i.e., all statements are made from the perspective of the 144 LS when discussing the SCSP protocol. The DCS is a server which is 145 directly connected to the LS; e.g., there exists a VC between the LS 146 and DCS. Thus, every server is a DCS from the point of view of every 147 other server which connects to it directly, and every server is an LS 148 which has zero or more DCSs directly connected to it. From the 149 perspective of an LS, an RS is a server, separate from the LS, which 150 is not directly connected to the LS (i.e., an RS is always two or 151 more hops away from an LS whereas a DCS is always one hop away from 152 an LS). 154 SCSP contains three sub protocols: the "Hello" protocol, the "Cache 155 Alignment" protocol, and the "Cache State Update" protocol. The 156 "Hello" protocol is used to ascertain whether a DCS is operational 157 and whether the connection between the LS and DCS is bidirectional, 158 unidirectional, or non-functional. The "Cache Alignment" (CA) 159 protocol allows an LS to synchronize its entire cache with that of 160 the cache of its DCSs. The "Cache State Update" (CSU) protocol is 161 used to update the state of cache entries in servers for a given SG. 162 Sections 2.1, 2.2, and 2.3 contain a more in-depth explanation of the 163 Hello, CA, and CSU protocols and the messages they use. 165 SCSP based synchronization is performed on a per protocol instance 166 basis. That is, a separate instance of SCSP is run for each instance 167 of the given protocol running in a given box. The protocol is 168 identified in SCSP via a Protocol ID and the instance of the protocol 169 is identified by a Server Group ID (SGID). Thus the PID/SGID pair 170 uniquely identify an instance of SCSP. In general, this is not an 171 issue since it is seldom the case that many instances of a given 172 protocol (which is distributed and needs cache synchronization) are 173 running within the same physical box. However, when this is the 174 case, there is a mechanism called the Family ID (described briefly in 175 the Hello Protocol) which enables a substantial reduction in 176 maintenance traffic at little real cost in terms of control. The use 177 of the Family ID mechanism, when appropriate for a given protocol 178 which is using SCSP, will be fully defined in the given SCSP protocol 179 specific specification. 181 +---------------+ 182 | | 183 +------->| DOWN |<-------+ 184 | | | | 185 | +---------------+ | 186 | | ^ | 187 | | | | 188 | | | | 189 | | | | 190 | @ | | 191 | +---------------+ | 192 | | | | 193 | | WAITING | | 194 | +--| |--+ | 195 | | +---------------+ | | 196 | | ^ ^ | | 197 | | | | | | 198 | @ | | @ | 199 +---------------+ +---------------+ 200 | BIDIRECTIONAL |---->| UNIDIRECTIONAL| 201 | | | | 202 | CONNECTION |<----| CONNECTION | 203 +---------------+ +---------------+ 205 Figure 1: Hello Finite State Machine (HFSM) 207 2.1 Hello Protocol 209 "Hello" messages are used to ascertain whether a DCS is operational 210 and whether the connections between the LS and DCS are bidirectional, 211 unidirectional, or non-functional. In order to do this, every LS MUST 212 periodically send a Hello message to its DCSs. 214 An LS must be configured with a list of NBMA addresses which 215 represent the addresses of peer servers in a SG to which the LS 216 wishes to have a direct connection for the purpose of running SCSP; 217 that is, these addresses are the addresses of would-be DCSs. The 218 mechanism for the configuration of an LS with these NBMA address is 219 beyond the scope of this document; although one possible mechanism 220 would be an autoconfiguration server. 222 An LS has a Hello Finite State Machine (HFSM) associated with each of 223 its DCSs (see Figure 1) for a given SG, and the HFSM monitors the 224 state of the connectivity between the servers. 226 The HFSM starts in the "Down" State and transitions to the "Waiting" 227 State after NBMA level connectivity has been established. Once in 228 the Waiting State, the LS starts sending Hello messages to the DCS. 229 The Hello message includes: a Sender ID which is set to the LS's ID 230 (LSID), zero or more Receiver IDs which identify the DCSs from which 231 the LS has recently heard a Hello message (as described below), and a 232 HelloInterval and DeadFactor which will be described below. At this 233 point, the DCS may or may not already be sending its own Hello 234 messages to the LS. 236 When the LS receives a Hello message from one of its DCSs, the LS 237 checks to see if its LSID is in one of the Receiver ID fields of that 238 message which it just received, and the LS saves the Sender ID from 239 that Hello message. If the LSID is in one of the Receiver ID fields 240 then the LS transitions the HFSM to the Bidirectional Connection 241 state otherwise it transitions the HFSM into the Unidirectional 242 Connection state. The Sender ID which was saved is the DCS's ID 243 (DCSID). At some point before the next time that the LS sends its 244 own Hello message to the DCS, the LS will check the saved DCSID 245 against a list of Receiver IDs which the LS uses when sending the 246 LS's own Hello messages. If the DCSID is not found in the list of 247 Receiver IDs then it is added to that list before the LS sends its 248 Hello message. 250 Hello messages also contain a HelloInterval and a DeadFactor. The 251 Hello interval advertises the time (in seconds) between sending of 252 consecutive Hello messages by the server which is sending the 253 "current" Hello message. That is, if the time between reception of 254 Hello messages from a DCS exceeds the HelloInterval advertised by 255 that DCS then the next Hello message is to be considered late by the 256 LS. If the LS does not receive a Hello message, which contains the 257 LS's LSID in one of the Receiver ID fields, within the interval 258 HelloInterval*DeadFactor seconds (where DeadFactor was advertised by 259 the DCS in a previous Hello message) then the LS MUST consider the 260 DCS to be stalled. At which point one of two things will happen: 1) 261 if any Hello messages have been received during the last 262 HelloInterval*DeadFactor seconds then the LS should transition the 263 HFSM for that DCS to the Unidirectional Connection State; otherwise, 264 the LS should transition the HFSM for that DCS to the Waiting State 265 and remove the DCSID from the Receiver ID list. 267 Note that the Hello Protocol is on a per PID/SGID basis. Thus, for 268 example, if there are two servers (one in SG A and the other in SG B) 269 associated with an NBMA address X and another two servers (also one 270 in SG A and the other in SG B) associated with NBMA address Y and 271 there is a suitable point-to-point VC between the NBMA addresses then 272 there are two HFSMs running on each side of the VC (one per 273 PID/SGID). 275 Hello messages contain a list of Receiver IDs instead of a single 276 Receiver ID in order to make use of point to multipoint connections. 277 While there is an HFSM per DCS, an LS MUST send only a single Hello 278 message to its DCSs attached as leaves of a point to multipoint 279 connection. The LS does this by including DCSIDs in the list of 280 Receiver IDs when the LS's sends its next Hello message. Only the 281 DCSIDs from non-stalled DCSs from which the LS has heard a Hello 282 message are included. 284 Any abnormal event, such as receiving a malformed SCSP message, 285 causes the HFSM to transition to the Waiting State; however, a loss 286 of NBMA connectivity causes the HFSM to transition to the Down State. 287 Until the HFSM is in the Bidirectional Connection State, if any 288 properly formed SCSP messages other than Hello messages are received 289 then those messages MUST be ignored (this is for the case where, for 290 example, there is a point to multipoint connection involved). 292 +------------+ 293 | | 294 +--->| DOWN | 295 | | | 296 | +------------+ 297 | | 298 ^ | 299 | @ 300 | +------------+ 301 | |Master/Slave| 302 |-<--| |<---+ 303 | |Negotiation | | 304 | +------------+ | 305 | | | 306 ^ | ^ 307 | @ | 308 | +------------+ | 309 | | Cache | | 310 |-<--| |-->-| 311 | | Summarize | | 312 | +------------+ | 313 | | | 314 ^ | ^ 315 | @ | 316 | +------------+ | 317 | | Update | | 318 |-<--| |-->-| 319 | | Cache | | 320 | +------------+ | 321 | | | 322 ^ | ^ 323 | @ | 324 | +------------+ | 325 | | | | 326 +-<--| Aligned |-->-+ 327 | | 328 +------------+ 330 Figure 2: Cache Alignment Finite State Machine 332 2.2 Cache Alignment Protocol 334 "Cache Alignment" (CA) messages are used by an LS to synchronize its 335 cache with that of the cache of each of its DCSs. That is, CA 336 messages allow a booting LS to synchronize with each of its DCSs. A 337 CA message contains a CA header followed by zero or more Cache State 338 Advertisement Summary records (CSAS records). 340 An LS has a Cache Alignment Finite State Machine (CAFSM) associated 341 (see Figure 2) with each of its DCSs on a per PID/SGID basis, and the 342 CAFSM monitors the state of the cache alignment between the servers. 343 The CAFSM starts in the Down State. The CAFSM is associated with an 344 HFSM, and when that HFSM reaches the Bidirectional State, the CAFSM 345 transitions to the Master/Slave Negotiation State. The Master/Slave 346 Negotiation State causes either the LS or DCS to take on the role of 347 master over the cache alignment process. In a sense, the master 348 server sets the tempo for the cache alignment. 350 When the LS's CAFSM reaches the Master/Slave Negotiation State, the 351 LS will send a CA message to the DCS associated with the CAFSM. The 352 format of CA messages are described in Section B.2.1. The first CA 353 message which the LS sends includes no CSAS records and a CA header 354 which contains the LSID in the Sender ID field, the DCSID in the 355 Receiver ID field, a CA sequence number, and three bits. These three 356 bits are the M (Master/Slave) bit, the I (Initialization of master) 357 bit, and the O (More) bit. In the first CA message sent by the LS to 358 a particular DCS, the M, O, and I bits are set to one. If the LS 359 does not receive a CA message from the DCS in CAReXmtInterval seconds 360 then it resends the CA message it just sent. The LS continues to do 361 this until the CAFSM transitions to the Cache Summarize State or 362 until the HFSM transitions out of the Bidirectional State. Any time 363 the HFSM transitions out of the Bidirectional State, the CAFSM 364 transitions to the Down State. 366 2.2.1 Master Slave Negotiation State 368 When the LS receives a CA message from the DCS while in the 369 Master/Slave Negotiation State, the role the LS plays in the exchange 370 depends on packet processing as follows: 372 1) If the CA from the DCS has the M, I, and O bits set to one and there 373 are no CSAS records in the CA message and the Sender ID as specified 374 in the DCS's CA message is larger than the LSID then 375 a) The timer counting down the CAReXmtInterval is stopped. 376 b) The CAFSM corresponding to that DCS transitions to the 377 Cache Summarize State and the LS takes on the role of slave. 378 c) The LS adopts the CA sequence number it received in the CA message 379 as its own CA sequence number. 380 d) The LS sends a CA message to the DCS which is formated as follows: 381 the M and I bits are set to zero, the Sender ID field is set to the 382 LSID, the Receiver ID field is set to the DCSID, and the 383 CA sequence number is set to the CA sequence number that appeared 384 in the DCS's CA message. If there are CSAS records to be sent 385 (i.e., if the LS's cache is not empty), and if all of them will not 386 fit into this CA message then the O bit is set to one and the initial 387 set of CSAS records are included in the CA message; otherwise the O bit 388 is set to zero and if any CSAS Records need to be sent then those 389 records are included in the CA message. 391 2) If the CA message from the DCS has the M and I bits off and the 392 Sender ID as specified in the DCS's CA message is smaller than 393 the LSID then 394 a) The timer counting down the CAReXmtInterval is stopped. 395 b) The CAFSM corresponding to that DCS transitions to the 396 Cache Summarize State and the LS takes on the role of master. 397 c) The LS must process the received CA message. 398 An explanation of CA message processing is given below. 399 d) The LS sends a CA message to the DCS which is formated as follows: 400 the M bit is set to one, I bit is set to zero, the Sender ID 401 field is set to the LSID, the Receiver ID field is set to the DCSID, 402 and the LS's current CA sequence number is incremented by one and 403 placed in the CA message. If there are any CSAS records to be sent 404 from the LS to the DCS (i.e., if the LS's cache is not empty) then 405 the O bit is set to one and the initial set of CSAS records are 406 included in the CA message that the LS is sending to the DCS. 408 3) Otherwise, the packet must be ignored. 410 2.2.2 The Cache Summarize State 412 At any given time, the master or slave have at most one outstanding 413 CA message. Once the LS's CAFSM has transitioned to the Cache 414 Summarize State the sequence of exchanges of CA messages occurs as 415 follows. 417 1) If the LS receives a CA message with the M bit set incorrectly 418 (e.g., the M bit is set in the CA of the DCS and the LS is master) 419 or if the I bit is set then the CAFSM transitions back to the 420 Master/Slave Negotiation State. 422 2) If the LS is master and the LS receives a CA message with a 423 CA sequence number which is one less than the LS's current 424 CA sequence number then the message is a duplicate and the message 425 MUST be discarded. 427 3) If the LS is master and the LS receives a CA message with a 428 CA sequence number which is equal to the LS's current CA sequence 429 number then the CA message MUST be processed. An explanation of 430 "CA message processing" is given below. As a result of having 431 received the CA message from the DCS the following will occur: 432 a) The timer counting down the CAReXmtInterval is stopped. 433 b) The LS must process any CSAS records in the received CA message. 435 c) Increment the LS's CA sequence number by one. 436 d) The cache exchange continues as follows: 437 1) If the LS has no more CSAS records to send and the received CA 438 message has the O bit off then the CAFSM transitions to the 439 Update Cache State. 440 2) If the LS has no more CSAS records to send and the received CA 441 message has the O bit on then the LS sends back a CA message 442 (with new CA sequence number) which contains no CSAS records and 443 with the O bit off. Reset the timer counting down the 444 CAReXmtInterval. 445 3) If the LS has more CSAS records to send then the LS sends the 446 next CA message with the LS's next set of CSAS records. If LS 447 is sending its last set of CSAS records then the O bit is set 448 off otherwise the O bit is set on. Reset the timer counting 449 down the CAReXmtInterval. 451 4) If the LS is slave and the LS receives a CA message with a 452 CA sequence number which is equal to the LS's current 453 CA sequence number then the CA message is a duplicate and the 454 LS MUST resend the CA message which it had just sent to the DCS. 456 5) If the LS is slave and the LS receives a CA message with a 457 CA sequence number which is one more than the LS's current 458 CA sequence number then the message is valid and MUST be 459 processed. An explanation of "CA message processing" is given 460 below. As a result of having received the CA message from the 461 DCS the following will occur: 463 a) The LS must process any CSAS records in the received CA message. 464 b) Set the LS's CA sequence number to the CA sequence number in the CA 465 message. 466 c) The cache exchange continues as follows: 467 1) If the LS had just sent a CA message with the O bit off and the 468 received CA message has the O bit off then the CAFSM transitions 469 to the Update Cache State and the LS sends a CA message with no 470 CSAS records and with the O bit off. 471 2) If the LS still has CSAS records to send then the LS MUST send 472 a CA message with CSAS records in it. 473 a) If the message being sent from the LS to the DCS does not contain 474 the last CSAS records that the LS needs to send then the CA 475 message is sent with the O bit on. 476 b) If the message being sent from the LS to the DCS does contain 477 the last CSAS records that the LS needs to send and 478 the CA message just received from the DCS had the O bit off then 479 the CA message is sent with the O bit off, and the LS transitions 480 the CAFSM to the Update Cache State. 481 c) If the message being sent from the LS to the DCS does contain 482 the last CSAS records that the LS needs to send and 483 the CA message just received from the DCS had the O bit on 484 then the CA message is sent with the O bit off and the alignment 485 process continues. 487 6) If the LS is slave and the LS receives a CA message with a 488 CA sequence number that is neither equal to nor one more than 489 the current LS's CA sequence number then an error has occurred 490 and the CAFSM transitions to the Master/Slave Negotiation State. 492 Note that if the LS was slave during the CA process then the LS upon 493 transitioning the CAFSM to the Update Cache state MUST keep a copy of 494 the last CA message it sent and the LS SHOULD set a timer equal to 495 CAReXmtInterval. If either the timer expires or the LS receives a CSU 496 Solicit (CSUS) message (CSUS messages are described in Section 2.2.3) 497 from the DCS then the LS releases the copy of the CA message. The 498 reason for this is that if the DCS (which is master) loses the last 499 CA message sent by the LS then the DCS will resend its previous CA 500 message with the last CA Sequence number used. If that were to occur 501 the LS would need to resend its last sent CA message as well. 503 2.2.2.1 "CA message processing": 505 The LS makes a list of those cache entries which are more "up to 506 date" in the DCS than the LS's own cache. This list is called the 507 CSA Request List (CRL). See Section 2.4 for a description of what it 508 means for a CSA (Client State Advertisement) record or CSAS record to 509 be more "up to date" than an LS's cache entry. 511 2.2.3 The Update Cache State 513 If the CRL of the associated CAFSM of the LS is empty upon transition 514 into the Update Cache State then the CAFSM immediately transitions 515 into the Aligned State. 517 If the CRL is not empty upon transition into the Update Cache State 518 then the LS solicits the DCS to send the CSA records corresponding to 519 the summaries (i.e., CSAS records) which the LS holds in its CRL. The 520 solicited CSA records will contain the entirety of the cached 521 information held in the DCS's cache for the given cache entry. The 522 LS solicits the relevant CSA records by forming CSU Solicit (CSUS) 523 messages from the CRL. See Section B.2.4 for the description of the 524 CSUS message format. The LS then sends the CSUS messages to the DCS. 525 The DCS responds to the CSUS message by sending to the LS one or more 526 CSU Request messages containing the entirety of newer cached 527 information identified in the CSUS message. Upon receiving the CSU 528 Request the LS will send one or more CSU Replies as described in 529 Section 2.3. Note that the LS may have at most one CSUS message 530 outstanding at any given time. 532 Just before the first CSUS message is sent from an LS to the DCS 533 associated with the CAFSM, a timer is set to CSUSReXmtInterval 534 seconds. If all the CSA records corresponding to the CSAS records in 535 the CSUS message have not been received by the time that the timer 536 expires then a new CSUS message will be created which contains all 537 the CSAS records for which no appropriate CSA record has been 538 received plus additional CSAS records not covered in the previous 539 CSUS message. The new CSUS message is then sent to the DCS. If, at 540 some point before the timer expires, all CSA record updates have been 541 received for all the CSAS records included in the previously sent 542 CSUS message then the timer is stopped. Once the timer is stopped, 543 if there are additional CSAS records that were not covered in the 544 previous CSUS message but were in the CRL then the timer is reset and 545 a new CSUS message is created which contains only those CSAS records 546 from the CRL which have not yet been sent to the DCS. This process 547 continues until all the CSA records corresponding CSAS records that 548 were in the CRL have been received by the LS. When the LS has a 549 completely updated cache then the LS transitions CAFSM associated 550 with the DCS to the Aligned State. 552 If an LS receives a CSUS message or a CA message with a Receiver ID 553 which is not the LS's LSID then the message must be discarded and 554 ignored. This is necessary since an LS may be a leaf of a point to 555 multipoint connection with other servers in the SG. 557 2.2.4 The Aligned State 559 While in the Aligned state, an LS will perform the Cache State Update 560 Protocol as described in Section 2.3. 562 Note that an LS may receive a CSUS message while in the Aligned State 563 and, the LS MUST respond to the CSUS message with the appropriate CSU 564 Request message in a similar fashion to the method previously 565 described in Section 2.2.3. 567 2.3 Cache State Update Protocol 569 "Cache State Update" (CSU) messages are used to dynamically update 570 the state of cache entries in servers on a given PID/SGID basis. CSU 571 messages contain zero or more "Cache State Advertisement" (CSA) 572 records each of which contains its own snapshot of the state of a 573 particular cache entry. An LS may send/receive a CSU to/from a DCS 574 only when the corresponding CAFSM is in either the Aligned State or 575 the Update Cache State. 577 There are two types of CSU messages: CSU Requests and CSU Replies. 578 See Sections B.2.2 and B.2.3 respectively for message formats. A CSU 579 Request message is sent from an LS to one or more DCSs for one of two 580 reasons: either the LS has received a CSUS message and MUST respond 581 only to the DCS which originated the CSUS message, or the LS has 582 become aware of a change of state of a cache entry. An LS becomes 583 aware of a change of state of a cache entry either through receiving 584 a CSU Request from one of its DCSs or as a result of a change of 585 state being observed in a cached entry originated by the LS. In the 586 former case, the LS will send a CSU Request to each of its DCSs 587 except the DCS from which the LS became aware of the change in state. 588 In the latter case, the LS will send a CSU Request to each of its 589 DCSs. The change in state of a particular cache entry is noted in a 590 CSA record which is then appended to the end of the CSU Request 591 message mandatory part. In this way, state changes are propagated 592 throughout the SG. 594 Examples of such changes in state are as follows: 596 1) a server receives a request from a client to add an entry to its 597 cache, 598 2) a server receives a request from a client to remove an entry from 599 its cache, 600 3) a cache entry has timed out in the server's cache, has been 601 refreshed in the server's cache, or has been administratively 602 modified. 604 When an LS receives a CSU Request from one of its DCSs, the LS 605 acknowledges one or more CSA Records which were contained in the CSU 606 Request by sending a CSU Reply. The CSU Reply contains one or more 607 CSAS records which correspond to those CSA records which are being 608 acknowledged. Thus, for example, if a CSA record is dropped (or 609 delayed in processing) by the LS because there are insufficient 610 resources to process it then a corresponding CSAS record is not 611 included in the CSU Reply to the DCS. 613 Note that an LS may send multiple CSU Request messages before 614 receiving a CSU Reply acknowledging any of the CSA Records contained 615 in the CSU Requests. Note also that a CSU Reply may contain 616 acknowledgments for CSA Records from multiple CSU Requests. Thus, 617 the terms "request" and "reply" may be a bit confusing. 619 Note that a CSA Record contains a CSAS Record followed by 620 client/server protocol specific information contained in a cache 621 entry (see Section B.2.0.2 for CSAS record format information and 622 Section B.2.2.1 for CSA record format information). When a CSA 623 record is considered by the LS to represent cached information which 624 is more "up to date" (see Section 2.4) than the cached information 625 contained within the cache of the LS then two things happen: 1) the 626 LS's cache is updated with the more up to date information, and 2) 627 the LS sends a CSU Request containing the CSA Record to each of its 628 DCSs except the one from which the CSA Record arrived. In this way, 629 state changes are propagated within the PID/SGID. Of course, at some 630 point, the LS will also acknowledge the reception of the CSA Record 631 by sending the appropriate DCS a CSU Reply message containing the 632 corresponding CSAS Record. 634 When an LS sends a new CSU Request, the LS keeps track of the 635 outstanding CSA records in that CSU Request and to which DCSs the LS 636 sent the CSU Request. For each DCS to which the CSU Request was 637 sent, a timer set to CSUReXmtInterval seconds is started just prior 638 to sending the CSU Request. This timer is associated with the CSA 639 Records contained in that CSU Request such that if that timer expires 640 prior to having all CSA Records acknowledged from that DCS then (and 641 only then) a CSU Request is re-sent by the LS to that DCS. However, 642 the re-sent CSU Request only contains those CSA Records which have 643 not yet been acknowledged. If all CSA Records associated with a 644 timer becomes acknowledged then the timer is stopped. Note that the 645 re-sent CSA Records follow the same time-out and retransmit rules as 646 if they were new. Retransmission will occur a configured number of 647 times for a given CSA Record and if acknowledgment fails to occur 648 then an "abnormal event" has occurred at which point the then the 649 HFSM associated with the DCS is transitioned to the Waiting State. 651 A CSA Record instance is said to be on a "DCS retransmit queue" when 652 it is associated with the previously mentioned timer. Only the most 653 up-to-date CSA Record is permitted to be queued to a given DCS 654 retransmit queue. Thus, if a less up-to-date CSA Record is queued to 655 the DCS retransmit queue when a newer CSA Record instance is about to 656 be queued to that DCS retransmit queue then the older CSA Record 657 instance is dequeued and disassociated with its timer immediately 658 prior to enqueuing the newer instance of the CSA Record. 660 When an LS receives a CSU Reply from one of its DCSs then the LS 661 checks each CSAS record in the CSU Reply against the CSAS Record 662 portion of the CSA Records which are queued to the DCS retransmit 663 queue. 665 1) If there exists an exact match between the CSAS record portion 666 of the CSA record and a CSAS Record in the CSU Reply then 667 that CSA Record is considered to be acknowledged and is thus 668 dequeued from the DCS retransmit queue and is 669 disassociated with its timer. 671 2) If there exists a match between the CSAS record portion 672 of the CSA record and a CSAS Record in the CSU Reply except 673 for the CSA Sequence number then 674 a) If the CSA Record queued to the DCS retransmit queue has a 675 CSA Sequence Number which is greater than the 676 CSA Sequence Number in the CSAS Record of the the CSU Reply then 677 the CSAS Record in the CSU Reply is ignored. 678 b) If the CSA Record queued to the DCS retransmit queue has a 679 CSA Sequence Number which is less than the 680 CSA Sequence Number in the CSAS Record of the the CSU Reply then 681 CSA Record which is queued to the DCS retransmit queue is 682 dequeued and the CSA Record is disassociated with its timer. 683 Further, a CSUS Message is sent to that DCS which sent the 684 more up-to-date CSAS Record. All normal CSUS processing 685 occurs as if the CSUS were sent as part of the CA protocol. 687 When an LS receives a CSU Request message which contains a CSA Record 688 which contains a CSA Sequence Number which is smaller than the CSA 689 Sequence number of the cached CSA then the LS MUST acknowledge the 690 CSA record in the CSU Request but it MUST do so by sending a CSU 691 Reply message containing the CSAS Record portion of the CSA Record 692 stored in the cache and not the CSAS Record portion of the CSA Record 693 contained in the CSU Request. 695 An LS responds to CSUS messages from its DCSs by sending CSU Request 696 messages containing the appropriate CSA records to the DCS. If an LS 697 receives a CSUS message containing a CSAS record for an entry which 698 is no longer in its database (e.g., the entry timed out and was 699 discarded after the Cache Alignment exchange completed but before the 700 entry was requested through a CSUS message), then the LS will respond 701 by copying the CSAS Record from the CSUS message into a CSU Request 702 message and the LS will set the N bit signifying that this record is 703 a NULL record since the cache entry no longer exists in the LS's 704 cache. Note that in this case, the "CSA Record" included in the CSU 705 Request to signify the NULL cache entry is literally only a CSAS 706 Record since no client/server protocol specific information exists 707 for the cache entry. 709 If an LS receives a CSA Record in a CSU Request from a DCS for which 710 the LS has an identical CSA record posted to the corresponding DCS's 711 DCS retransmit queue then the CSA Record on the DCS retransmit queue 712 is considered to be implicitly acknowledged. Thus, the CSA Record is 713 dequeued from the DCS retransmit queue and is disassociated with its 714 timer. The CSA Record sent by the DCS MUST still be acknowledged by 715 the LS in a CSU Reply, however. This is useful in the case of point 716 to multipoint connections where the rule that "when an LS receives a 717 CSA record from a DCS, that LS floods the CSA Record to every DCS 718 except the DCS from which it was received" might be broken. 720 If an LS receives a CSU with a Receiver ID which is not equal to the 721 LSID and is not set to all 0xFFs then the CSU must be discarded and 722 ignored. This is necessary since the LS may be a leaf of a point to 723 multipoint connection with other servers in the LS's SG. 725 An LS MAY send a CSU Request to the all 0xFFs Receiver ID when the LS 726 is a root of a point to multipoint connection with a set of its DCSs. 727 If an LS receives a CSU Request with the all 0xFFs Receiver ID then 728 it MUST use the Sender ID in the CSU Request as the Receiver ID of 729 the CSU Reply (i.e., it MUST unicast its response to the sender of 730 the request) when responding. If the LS wishes to send a CSU Request 731 to the all 0xFFs Receiver ID then it MUST create a time-out and 732 retransmit timer for each of the DCSs which are leaves of the point 733 to multipoint connection prior to sending the CSU Request. If in 734 this case, the time-out and retransmit timer expires for a given DCS 735 prior to acknowledgment of a given CSA Record then the LS MUST use 736 the specific DCSID as the Receiver ID rather than the all 0xFFs 737 Receiver ID. Similarly, if it is necessary to re-send a CSA Record 738 then the LS MUST specify the specific DCSID as the Receiver ID rather 739 than the all 0xFFs Receiver ID. 741 Note that if a set of servers are in a full mesh of point to 742 multipoint connections, and one server of that mesh sends a CSU 743 Request into that full mesh, and the sending server sends the CSA 744 Records in the CSU Request to the all 0xFFs Receiver ID then it would 745 not be necessary for every other server in the mesh to source their 746 own CSU Request containing those CSA Records into the mesh in order 747 to properly flood the CSA Records. This is because every server in 748 the mesh would have heard the CSU Request and would have processed 749 the included CSA Records as appropriate. Thus, a server in a full 750 mesh could consider the mesh to be a single logical port and so the 751 rule that "when an LS receives a CSA record from a DCS, that LS 752 floods the CSA Record to every DCS except the DCS from which it was 753 received" is not broken. A receiving server in the full mesh would 754 still need to acknowledge the CSA records with CSU Reply messages 755 which contain the LSID of the replying server as the Sender ID and 756 the ID of the server which sent the CSU Request as the Receiver ID 757 field. In the time out and retransmit case, the Receiver ID of the 758 CSU Request would be set to the specific DCSID which did not 759 acknowledge the CSA Record (as opposed to the all 0xFFs Receiver ID). 760 Since a full mesh emulates a broadcast media for the servers attached 761 to the full mesh, use of SCSP on a broadcast medium might use this 762 technique as well. Further discussion of this use of a full mesh or 763 use of a broadcast media is left to the client/server protocol 764 specific documents. 766 2.4 The meaning of "More Up To Date"/"Newness" 768 During the cache alignment process and during normal CSU processing, 769 a CSAS Record is compared against the contents of an LS's cache entry 770 to decide whether the information contained in the record is more "up 771 to date" than the corresponding cache entry of the LS. 773 There are three pieces of information which are used in determining 774 whether a record contains information which is more "up to date" than 775 the information contained in the cache entry of an LS which is 776 processing the record: 1) the Cache Key, 2) the Originator which is 777 described by an Originator ID (OID), and 3) the CSA Sequence number. 778 See Section B.2.0.2 for more information on these fields. 780 Given these three pieces of information, a CSAS record (be it part of 781 a CSA Record or be it stand-alone) is considered to be more "up to 782 date" than the information contained in the cache of an LS if all of 783 the following are true: 784 1) The Cache Key in the CSAS Record matches the stored Cache Key 785 in the LS's cache entry, 786 2) The OID in the CSAS Record matches the stored OID 787 in the LS's cache entry, 788 3) The CSA Sequence Number in the CSAS Record is greater than 789 CSA Sequence Number in the LS's cache entry. 791 Discussion and conclusions 793 While the above text is couched in terms of synchronizing the 794 knowledge of the state of a client within the cache of servers 795 contained in a SG, this solution generalizes easily to any number of 796 database synchronization problems (e.g., LECS synchronization). 798 SCSP defines a generic flooding protocol. There are a number of 799 related issues relative to cache maintenance and topology maintenance 800 which are more appropriately defined in the client/server protocol 801 specific documents; for example, it might be desirable to define a 802 generic cache entry time-out mechanism for a given protocol or to 803 advertise adjacency information between servers so that one could 804 obtain a topo-map of the servers in a SG. When mechanisms like these 805 are desirable, they will be defined in the client/server protocol 806 specific documents. 808 Appendix A: Terminology and Definitions 810 CA Message - Cache Alignment Message 811 These messages allow an LS to synchronize its entire cache with 812 that of the cache of one of its DCSs. 814 CAFSM - Cache Alignment Finite State Machine 815 The CAFSM monitors the state of the cache alignment between an LS 816 and a particular DCS. There exists one CAFSM per DCS as seen from 817 an LS. 819 CSA Record - Cache State Advertisement Record 820 A CSA is a record within a CSU message which identifies an update 821 to the status of a "particular" cache entry. 823 CSAS Record - Cache State Advertisement Summary Record 824 A CSAS contains a summary of the information in a CSA. A server 825 will send CSAS records describing its cache entries to another 826 server during the cache alignment process. CSAS records are also 827 included in a CSUS messages when an LS wants to request the entire 828 CSA from the DCS. The LS is requesting the CSA from the DCS 829 because the LS believes that the DCS has a more recent view of the 830 state of the cache entry in question. 832 CSU Message - Cache State Update message 833 This is a message sent from an LS to its DCSs when the LS becomes 834 aware of a change in state of a cache entry. 836 CSUS Message - Cache State Update Solicit Message 837 This message is sent by an LS to its DCS after the LS and DCS have 838 exchanged CA messages. The CSUS message contains one or more CSAS 839 records which represent solicitations for entire CSA records (as 840 opposed to just the summary information held in the CSAS). 842 DCS - Directly Connected Server 843 The DCS is a server which is directly connected to the LS; e.g., 844 there exists a VC between the LS and DCS. This term, along with the 845 terms LS and RS, is used to give a frame of reference when talking 846 about servers and their synchronization. Unless explicitly stated 847 to the contrary, there is no implied difference in functionality 848 between a DCS, LS, and RS. 850 HFSM - Hello Finite State Machine 851 An LS has a HFSM associated with each of its DCSs. The HFSM 852 monitors the state of the connectivity between the LS and a 853 particular DCS. 855 LS - Local Server 856 The LS is the server under scrutiny; i.e., all statements are made 857 from the perspective of the LS. This term, along with the terms 858 DCS and RS, is used to give a frame of reference when talking about 859 servers and their synchronization. Unless explicitly stated to the 860 contrary, there is no implied difference in functionality between a 861 DCS, LS, and RS. 863 LSID - Local Server ID 864 The LSID is a unique token that identifies an LS. This value might 865 be taken from the protocol address of the LS. 867 PID - Protocol ID 868 This field contains an identifier which identifies the 869 client/server protocol which is making use of SCSP for the given 870 message. The assignment of Protocol IDs for this field is given 871 over to IANA (see Section C). 873 RS - Remote Server (RS) 874 From the perspective of an LS, an RS is a server, separate from the 875 LS, which is not directly connected to the LS (i.e., an RS is 876 always two or more hops away from an LS whereas a DCS is always one 877 hop away from an LS). Unless otherwise stated an RS refers to a 878 server in the SG. This term, along with the terms LS and DCS, is 879 used to give a frame of reference when talking about servers and 880 their synchronization. Unless explicitly stated to the contrary, 881 there is no implied difference in functionality between a DCS, LS, 882 and RS. 884 SG - Server Group 885 The SCSP synchronizes caches (or a portion of the caches) of a set 886 of server entities which are bound to a SG through some means 887 (e.g., all servers belonging to a Logical IP Subnet (LIS)[1]). 888 Thus an SG is just a grouping of servers around some commonality. 890 SGID - Server Group ID 891 This ID is a 16 bit identification field that uniquely identifies 892 the instance client/server protocol for which the servers of the SG 893 are being synchronized. This implies that multiple instances of 894 the same protocol may be in operation at the same time and have 895 their servers synchronized independently of each other. 897 Appendix B: SCSP Message Formats 899 This section of the appendix includes the message formats for SCSP. 900 SCSP protocols are LLC/SNAP encapsulated with an LLC=0xAA-AA-03 and 901 OUI=0x00-00-5e and PID=0x00-05. 903 SCSP has 3 parts to every packet: the fixed part, the mandatory part, 904 and the extensions part. The fixed part of the message exists in 905 every packet and is shown below. The mandatory part is specific to 906 the particular message type (i.e., CA, CSU Request/Reply, Hello, 907 CSUS) and, it includes (among other packet elements) a Mandatory 908 Common Part and zero or more records each of which contains 909 information pertinent to the state of a particular cache entry 910 (except in the case of a Hello message) whose information is being 911 synchronized within a SG. The extensions part contains the set of 912 extensions for the SCSP message. 914 In the following message formats, the fields marked as "unused" MUST 915 be set to zero upon transmission of such a message and ignored upon 916 receipt of such a message. 918 B.1 Fixed Part 920 0 1 2 3 921 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 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Version | Type Code | Packet Size | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Checksum | Start Of Extensions | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Version 929 This is the version of the SCSP protocol being used. The current 930 version is 1. 932 Type Code 933 This is the code for the message type (e.g., Hello (5), CSU 934 Request(2), CSU Reply(3), CSUS (4), CA (1)). 936 Packet Size 937 The total length of the SCSP packet, in octets (excluding link 938 layer and/or other protocol encapsulation). 940 Checksum 941 The standard IP checksum over the entire SCSP packet starting at 942 the fixed header. If the packet is an odd number of bytes in 943 length then this calculation is performed as if a byte set to 0x00 944 is appended to the end of the packet. 946 Start Of Extensions 947 This field is coded as zero when no extensions are present in the 948 message. If extensions are present then this field will be coded 949 with the offset from the top of the fixed header to the beginning 950 of the first extension. 952 B.2.0 Mandatory Part 954 The mandatory part of the SCSP packet contains the operation specific 955 information for a given message type (e.g., SCSP Cache State Update 956 Request/Reply, etc.), and it includes (among other packet elements) a 957 Mandatory Common Part (described in Section B.2.0.1) and zero or more 958 records each of which contains information pertinent to the state of 959 a particular cache entry (except in the case of a Hello message) 960 whose information is being synchronized within a SG. These records 961 may, depending on the message type, be either Cache State 962 Advertisement Summary (CSAS) Records (described in Section B.2.0.2) 963 or Cache State Advertisement (CSA) Records (described in Section 964 B.2.2.1). CSA Records contain a summary of a cache entry's 965 information (i.e., a CSAS Record) plus some additional client/server 966 protocol specific information. The mandatory common part format and 967 CSAS Record format is shown immediately below, prior to showing their 968 use in SCSP messages, in order to prevent replication within the 969 message descriptions. 971 B.2.0.1 Mandatory Common Part 973 Sections B.2.1 through B.2.5 have a substantial overlap in format. 974 This overlapping format is called the mandatory common part and its 975 format is shown below: 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Protocol ID | Server Group ID | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | unused | Flags | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Sender ID Len | Recvr ID Len | Number of Records | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Sender ID (variable length) | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Receiver ID (variable length) | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 Protocol ID 992 This field contains an identifier which identifies the 993 client/server protocol which is making use of SCSP for the given 994 message. The assignment of Protocol IDs for this field is given 995 over to IANA (see Section C). Protocols with current documents 996 have the the following defined values: 997 1 - ATMARP 998 2 - NHRP 999 3 - MARS 1000 4 - DHCP 1001 5 - LNNI 1003 Server Group ID 1004 This ID is uniquely identifies the instance of a given 1005 client/server protocol for which servers are being synchronized. 1007 Flags 1008 The Flags field is message specific, and its use will be described 1009 in the specific message format sections below. 1011 Sender ID Len 1012 This field holds the length in octets of the Sender ID. 1014 Recvr ID Len 1015 This field holds the length in octets of the Receiver ID. 1017 Number of Records 1018 This field contains the number of additional records associated 1019 with the given message. The exact format of these records is 1020 specific to the message and will be described for each message type 1021 in the sections below. 1023 Sender ID 1024 This is an identifier assigned to the server which is sending the 1025 given message. One possible assignment might be the protocol 1026 address of the sending server. 1028 Receiver ID 1029 This is an identifier assigned to the server which is to receive 1030 the given message. One possible assignment might be the protocol 1031 address of the server which is to receive the given message. 1033 B.2.0.2 Cache State Advertisement Summary Record (CSAS record) 1035 CSAS records contain a summary of information contained in a cache 1036 entry of a given client/server database which is being synchronized 1037 through the use of SCSP. The summary includes enough information for 1038 SCSP to look into the client/server database for the appropriate 1039 database cache entry and then compare the "newness" of the summary 1040 against the "newness" of the cached entry. 1042 Note that CSAS records do not contain a Server Group ID (SGID) nor do 1043 they contain a Protocol ID. These IDs are necessary to identify 1044 which protocol and which instance of that protocol for which the 1045 summary is applicable. These IDs are present in the mandatory common 1046 part of each message. 1048 Note also that the values of the Hop Count and Record Length fields 1049 of a CSAS Record are dependent on whether the CSAS record exists as a 1050 "stand-alone" record or whether the CSAS record is "embedded" in CSA 1051 Record. This is further described below. 1053 0 1 2 3 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Hop Count | Record Length | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Cache Key Len | Orig ID Len |N| unused | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | CSA Sequence Number | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Cache Key ... | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Originator ID ... | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 Hop Count 1068 This field represents the number of hops that the record may take 1069 before being dropped. Thus, at each server that the record 1070 traverses, the Hop Count is decremented. This field is set to 1 1071 when the CSAS record is a "stand-alone" record (i.e., it is not 1072 embedded within a CSA record) since summaries do not go beyond one 1073 hop during the cache alignment process. If a CSAS record is 1074 "embedded" within a CSA record then the Hop Count is set to an 1075 administratively defined value which is almost certainly greater 1076 than or equal to the the cardinality of the SG minus one. Note 1077 that an exception to the previous rule occurs when the CSA Record 1078 is carried within a CSU Request which was sent in response to a 1079 solicitation (i.e., in response to a CSAS Record which was sent in 1080 a CSUS message); in which case, the Hop Count SHOULD be set to 1. 1082 Record Length 1083 If the CSAS record is a "stand-alone" record then this value is 1084 12+"Cache Key Leng"+"Orig ID Len" in bytes; otherwise, this value 1085 is set to 12+"Cache Key Leng"+"Orig ID Len"+ sizeof("Client/Server 1086 Protocol Specific Part for cache entry"). The size of the 1087 Client/Server Protocol Specific Part may be obtained from the 1088 client/server protocol specific document for the given Protocol ID. 1090 Cache Key Len 1091 Length of the Cache Key field in bytes. 1093 Orig ID Len. 1094 Length of the Originator ID field in bytes. 1096 N 1097 The "N" bit signifies that this CSAS Record is actually a Null 1098 record. This bit is only used in a CSAS Record contained in a CSU 1099 Request/Reply which is sent in response to a CSUS message. It is 1100 possible that an LS may receive a solicitation for a CSA record 1101 when the cache entry represented by the solicited CSA Record no 1102 longer exists in the LS's cache (see Section 2.3 for details). In 1103 this case, the LS copies the CSAS Record directly from the CSUS 1104 message into the CSU Request, and the LS sets the N bit signifying 1105 that the cache entry does not exist any longer. The DCS which 1106 solicited the CSA record which no longer exists will still respond 1107 with a CSU Reply. This bit is usually set to zero. 1109 CSA Sequence Number 1110 This field contains a sequence number that identifies the "newness" 1111 of a CSA record instance being summarized. A "larger" sequence 1112 number means a more recent advertisement. Thus, if the state of 1113 part (or all) of a cache entry needs to be updated then the CSA 1114 record advertising the new state MUST contain a CSA Sequence Number 1115 which is larger than the one corresponding to the previous 1116 advertisement. This number is assigned by the originator of the 1117 CSA record. The CSA Sequence Number may be assigned by the 1118 originating server or by the client which caused its server to 1119 advertise its existence. 1121 The CSA Sequence Number is a signed 32 bit number. Within the CSA 1122 Sequence Number space, the number -2^31 (0x80000000) is reserved. 1123 Thus, the usable portion of the CSA Sequence Number space for a 1124 given Cache Key is between the numbers -2^31+1 (0x80000001) and 1125 2^31-1 (0x7fffffff). An LS uses -2^31+1 the first time it 1126 originates a CSA Record for a cache entry that it created. Each 1127 time the cache entry is modified in some manner and when that 1128 modification needs to be synchronized with the other servers in the 1129 SG, the LS increments the CSA Sequence number associated with the 1130 given Cache Key and uses that new CSA Sequence Number when 1131 advertising the update. If it is ever the case that a given CSA 1132 Sequence Number has reached 2^31-2 and the associated cache entry 1133 has been modified such that an update must be sent to the rest of 1134 the servers in the SG then the given cache entry MUST first be 1135 purged from the SG by the LS by sending a CSA Record which causes 1136 the cache entry to be removed from other servers and this CSA 1137 Record carries a CSA Sequence Number of 2^31-1. The exact packet 1138 format and mechanism by which a cache entry is purged is defined in 1139 the appropriate protocol specific document. After the purging CSA 1140 Record has been acknowledged by each DCS, an LS will then send a 1141 new CSA Record carrying the updated information, and this new CSA 1142 Record will carry a CSA Sequence Number of -2^31+1. 1144 After a restart occurs and after the restarting LS's CAFSM has 1145 achieved the Aligned state, if an update to an existing cache entry 1146 needs to be synchronized or a new cache entry needs to be 1147 synchronized then the ensuing CSA Record MUST contain a CSA 1148 Sequence Number which is unique within the SG for the given OID and 1149 Cache Key. The RECOMMENDED method of obtaining this number (unless 1150 explicitly stated to the contrary in the protocol specific 1151 document) is to set the CSA Sequence Number in the CSA Record to 1152 the CSA Sequence Number associated with the existing cache entry 1153 (if an out of date cache entry already exists and zero if not) plus 1154 a configured constant. Note that the protocol specific document 1155 may require that all cache entries containing the OID of the 1156 restarting LS be purged prior to updating the cache entries; in 1157 this case, the updating CSA Record will still contain a CSA 1158 Sequence Number set to the CSA Sequence Number associated with the 1159 previously existing cache entry plus a configured constant. 1161 Cache Key 1162 This is a database lookup key that uniquely identifies a piece of 1163 data which the originator of a CSA Record wishes to synchronize 1164 with its peers for a given "Protocol ID/Server Group ID" pair. 1165 This key will generally be a small opaque byte string which SCSP 1166 will associate with a given piece of data in a cache. Thus, for 1167 example, an originator might assign a particular 4 byte string to 1168 the binding of an IP address with that of an ATM address. 1169 Generally speaking, the originating server of a CSA record is 1170 responsible for generating a Cache Key for every element of data 1171 that the the given server originates and which the server wishes to 1172 synchronize with its peers in the SG. 1174 Originator ID 1175 This field contains an ID administratively assigned to the server 1176 which is the originator of CSA Records. 1178 B.2.1 Cache Alignment (CA) 1180 The Cache Alignment (CA) message allows an LS to synchronize its 1181 entire cache with that of the cache of its DCSs within a server 1182 group. The CA message type code is 1. The CA message mandatory part 1183 format is as follows: 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | CA Sequence Number | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Mandatory Common Part | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | CSAS Record | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 ....... 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | CSAS Record | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 CA Sequence Number 1200 A value which provides a unique identifier to aid in the sequencing 1201 of the cache alignment process. A "larger" sequence number means a 1202 more recent CA message. The slave server always copies the 1203 sequence number from the master server's previous CA message into 1204 its current CA message which it is sending and the the slave 1205 acknowledges the master's CA message. Since the initial CA process 1206 is lock-step, if the slave does not receive the same sequence 1207 number which it previously received then the information in the 1208 slave's previous CA message is implicitly acknowledged. Note that 1209 there is a separate CA Sequence Number space associated with each 1210 CAFSM. 1212 Whenever it is necessary to (re)start cache alignment and the CAFSM 1213 enters the Master/Slave Negotiation state, the CA Sequence Number 1214 should be set to a value not previously seen by the DCS. One 1215 possible scheme is to use the machine's time of day counter. 1217 Mandatory Common Part 1218 The mandatory common part is described in detail in Section 1219 B.2.0.1. There are two fields in the mandatory common part whose 1220 codings are specific to a given message type. These fields are the 1221 "Number of Records" field and the "Flags" field. 1223 Number of Records 1224 The Number of Records field of the mandatory common part for the 1225 CA message gives the number of CSAS Records appended to the CA 1226 message mandatory part. 1228 Flags 1229 The Flags field of the mandatory common part for the CA message 1230 has the following format: 1232 0 1 1233 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 |M|I|O| unused | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 M 1239 This bit is part of the negotiation process for the cache 1240 alignment. When this bit is set then the sender of the CA 1241 message is indicating that it wishes to lead the alignment 1242 process. This bit is the "Master/Slave bit". 1244 I 1245 When set, this bit indicates that the sender of the CA message 1246 believes that it is in a state where it is negotiating for the 1247 status of master or slave. This bit is the "Initialization 1248 bit". 1250 O 1251 This bit indicates that the sender of the CA message has more 1252 CSAS records to send. This implies that the cache alignment 1253 process must continue. This bit is the "mOre bit" despite its 1254 dubious name. 1256 All other fields of the mandatory common part are coded as 1257 described in Section B.2.0.1. 1259 CSAS record 1260 The CA message appends CSAS records to the end of its mandatory 1261 part. These CSAS records are NOT embedded in CSA records. See 1262 Section B.2.0.2 for details on CSAS records. 1264 B.2.2 Cache State Update Request (CSU Request) 1266 The Cache State Update Request (CSU Request) message is used to 1267 update the state of cache entries in servers which are directly 1268 connected to the server sending the message. A CSU Request message 1269 is sent from one server (the LS) to directly connected server (the 1270 DCS) when the LS observes changes in the state of one or more cache 1271 entries. An LS observes such a change in state by either receiving a 1272 CSU request which causes an update to the LS's database or by 1273 observing a change of state of a cached entry originated by the LS. 1274 The change in state of a cache entry is noted in a CSU message by 1275 appending a "Cache State Advertisement" (CSA) record to the end of 1276 the mandatory part of the CSU Request as shown below. 1278 The CSU Request message type code is 2. The CSU Request message 1279 mandatory part format is as follows: 1281 0 1 2 3 1282 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 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | Mandatory Common Part | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | CSA Record | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 ....... 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | CSA Record | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 Mandatory Common Part 1294 The mandatory common part is described in detail in Section 1295 B.2.0.1. There are two fields in the mandatory common part whose 1296 codings are specific to a given message type. These fields are the 1297 "Number of Records" field and the "Flags" field. 1299 Number of Records 1300 The Number of Records field of the mandatory common part for the 1301 CSU Request message gives the number of CSA Records appended to 1302 the CSU Request message mandatory part. 1304 Flags 1305 Currently, there are no flags defined for the Flags field of the 1306 mandatory common part for the CSU Request message. 1308 All other fields of the mandatory common part are coded as 1309 described in Section B.2.0.1. 1311 CSA Record 1312 See Section B.2.2.1. 1314 B.2.2.1 Cache State Advertisement Record (CSA record) 1316 CSA records contain the information necessary to relate the current 1317 state of a cache entry in an SG to the servers being synchronized. 1318 CSA records contain a CSAS Record header and a client/server protocol 1319 specific part. The CSAS Record includes enough information for SCSP 1320 to look into the client/server database for the appropriate database 1321 cache entry and then compare the "newness" of the summary against the 1322 "newness" of the cached entry. If the information contained in the 1323 CSA is more new than the cached entry of the receiving server then 1324 the cached entry is updated accordingly with the contents of the CSA 1325 Record. The client/server protocol specific part of the CSA Record 1326 is documented separately for each such protocol. Examples of the 1327 protocol specific parts for NHRP and ATMARP are shown in [8] and [9] 1328 respectively. 1330 The amount of information carried by a specific CSA record may exceed 1331 the size of a link layer PDU. Hence, such CSA records MUST be 1332 fragmented across a number of CSU Request messages. The method by 1333 which this is done, is client/server protocol specific and is 1334 documented in the appropriate protocol specific document. 1336 The content of a CSA record is as follows: 1338 0 1 2 3 1339 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 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | CSAS Record | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Client/Server Protocol Specific Part for cache entry ... | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 CSAS Record 1347 See Section B.2.0.2 for rules and format for filling out a CSAS 1348 Record when it is "embedded" in a CSA Record. 1350 Client/Server Protocol Specific Part for cache entry 1351 This field contains the fields which are specific to the protocol 1352 specific portion of SCSP processing. The particular set of fields 1353 are defined in separate documents for each protocol user of SCSP. 1354 The Protocol ID, which identifies which protocol is using SCSP in 1355 the given packet, is located in the mandatory part of the message. 1357 B.2.3 Cache State Update Reply (CSU Reply) 1359 The Cache State Update Reply (CSU Reply) message is sent from a DCS 1360 to an LS to acknowledge one or more CSA records which were received 1361 in a CSU Request. Reception of a CSA record in a CSU Request is 1362 acknowledged by including a CSAS record in the CSU Reply which 1363 corresponds to the CSA record being acknowledged. The CSU Reply 1364 message is the same in format as the CSU Request message except for 1365 the following: the type code is 3, only CSAS Records (rather than CSA 1366 records) are returned, and only those CSAS Records for which CSA 1367 Records are being acknowledged are returned. This implies that a 1368 given LS sending a CSU Request may not receive an acknowledgment in a 1369 single CSU Reply for all the CSA Records included in the CSU Request. 1371 B.2.4 Cache State Update Solicit Message (CSUS message) 1372 This message allows one server (LS) to solicit the entirety of CSA 1373 record data stored in the cache of a directly connected server (DCS). 1374 The DCS responds with CSU Request messages containing the appropriate 1375 CSA records. The CSUS message type code is 4. The CSUS message 1376 format is the same as that of the CSU Reply message. CSUS messages 1377 solicit CSU Requests from only one server (the one identified by the 1378 Receiver ID in the Mandatory Part of the message). 1380 B.2.5 Hello: 1382 The Hello message is used to check connectivity between the sending 1383 server (the LS) and one of its directly connected neighbor servers 1384 (the DCSs). The Hello message type code is 5. The Hello message 1385 mandatory part format is as follows: 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | HelloInterval | DeadFactor | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | unused | Family ID | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Mandatory Common Part | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Additional Receiver ID Record | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 ......... 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Additional Receiver ID Record | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 HelloInterval 1404 The hello interval advertises the time between sending of 1405 consecutive Hello Messages. If the LS does not receive a Hello 1406 message from the DCS (which contains the LSID as a Receiver ID) 1407 within the HelloInterval advertised by the DCS then the DCS's Hello 1408 is considered to be late. Also, the LS MUST send its own Hello 1409 message to a DCS within the HelloInterval which it advertised to 1410 the DCS in the LS's previous Hello message to that DCS (otherwise 1411 the DCS would consider the LS's Hello to be late). 1413 DeadFactor 1414 This is a multiplier to the HelloInterval. If an LS does not 1415 receive a Hello message which contains the LS's LSID as a Receiver 1416 ID within the interval HelloInterval*DeadFactor from a given DCS, 1417 which advertised the HelloInterval and DeadFactor in a previous 1418 Hello message, then the LS MUST consider the DCS to be stalled; at 1419 this point, one of two things MUST happen: 1) if the LS has 1420 received any Hello messages from the DCS during this time then the 1421 LS transitions the corresponding HFSM to the Unidirectional State; 1422 otherwise, 2) the LS transitions the corresponding HFSM to the 1423 Waiting State. 1425 Family ID 1426 This is an opaque bit string which is used to refer to an aggregate 1427 of Protocol ID/SGID pairs. Only a single HFSM is run for all 1428 Protocol ID/SGID pairs assigned to a Family ID. Thus, there is a 1429 one to many mapping between the single HFSM and the CAFSMs 1430 corresponding to each of the Protocol ID/SGID pairs. This might 1431 have the net effect of substantially reducing HFSM maintenance 1432 traffic. See the protocol specific SCSP documents for further 1433 details. 1435 Mandatory Common Part 1436 The mandatory common part is described in detail in Section 1437 B.2.0.1. There are two fields in the mandatory common part whose 1438 codings are specific to a given message type. These fields are the 1439 "Number of Records" field and the "Flags" field. 1441 Number of Records 1442 The Number of Records field of the mandatory common part for the 1443 Hello message contains the number of "Additional Receiver ID" 1444 records which are included in the Hello. Additional Receiver ID 1445 records contain a length field and a Receiver ID field. Note 1446 that the count in "Number of Records" does NOT include the 1447 Receiver ID which is included in the Mandatory Common Part. 1449 Flags 1450 Currently, there are no flags defined for the Flags field of the 1451 mandatory common part for the Hello message. 1453 All other fields of the mandatory common part are coded as 1454 described in Section B.2.0.1. 1456 Additional Receiver ID Record 1457 This record contains a length field followed by a Receiver ID. 1458 Since it is conceivable that the length of a given Receiver ID may 1459 vary even within an SG, each additional Receiver ID heard (beyond 1460 the first one) will have both its length in bytes and value encoded 1461 in an "Additional Receiver ID Record". Receiver IDs are IDs of a 1462 DCS from which the LS has heard a recent Hello (i.e., within 1463 DeadFactor*HelloInterval as advertised by the DCS in a previous 1464 Hello message). 1466 The format for this record is as follows: 1468 0 1 2 3 1469 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 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Rec ID Len | Receiver ID | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 If the LS has not heard from any DCS then the LS sets the Hello 1475 message fields as follows: Recvr ID Len is set to zero and no storage 1476 is allocated for the Receiver ID in the Common Mandatory Part, 1477 "Number of Records" is set to zero, and no storage is allocated for 1478 "Additional Receiver ID Records". 1480 If the LS has heard from exactly one DCS then the LS sets the Hello 1481 message fields as follows: the Receiver ID of the DCS which was heard 1482 and the length of that Receiver ID are encoded in the Common 1483 Mandatory Part, "Number of Records" is set to zero, and no storage is 1484 allocated for "Additional Receiver ID Records". 1486 If the LS has heard from two or more DCSs then the LS sets the Hello 1487 message fields as follows: the Receiver ID of the first DCS which was 1488 heard and the length of that Receiver ID are encoded in the Common 1489 Mandatory Part, "Number of Records" is set to the number of 1490 "Additional" DCSs heard, and for each additional DCS an "Additional 1491 Receiver ID Record" is formed and appended to the end of the Hello 1492 message. 1494 B.3 Extensions Part 1496 The Extensions Part, if present, carries one or more extensions in 1497 {Type, Length, Value} triplets. 1499 Extensions have the following format: 1501 0 1 2 3 1502 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 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | Type | Length | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Value... | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 Type 1510 The extension type code (see below). 1512 Length 1513 The length in octets of the value (not including the Type and 1514 Length fields; a null extension will have only an extension header 1515 and a length of zero). 1517 When extensions exist, the extensions part is terminated by the End 1518 of Extensions extension, having Type = 0 and Length = 0. 1520 Extensions may occur in any order but any particular extension type 1521 may occur only once in an SCSP packet. An LS MUST NOT change the 1522 order of extensions. 1524 B.3.0 The End Of Extensions 1526 Type = 0 1527 Length = 0 1529 When extensions exist, the extensions part is terminated by the End 1530 Of Extensions extension. 1532 B.3.1 SCSP Authentication Extension 1534 Type = 1 Length = variable 1536 The SCSP Authentication Extension is carried in SCSP packets to 1537 convey the authentication information between an LS and a DCS in the 1538 same SG. 1540 Authentication is done pairwise on an LS to DCS basis; i.e., the 1541 authentication extension is generated at each LS. If a received 1542 packet fails the authentication test then an "abnormal event" has 1543 occurred. The packet is discarded and this event is logged. 1545 The presence or absence of authentication is a local matter. 1547 B.3.1.1 Header Format 1549 The authentication header has the following format: 1551 0 1 2 3 1552 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 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | Security Parameter Index (SPI) | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | | 1557 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1558 | | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 Security Parameter Index (SPI) can be thought of as an index into a 1562 table that maintains the keys and other information such as hash 1563 algorithm. LS and DCS communicate either off-line using manual keying 1564 or online using a key management protocol to populate this table. The 1565 receiving SCSP entity always allocates the SPI and the parameters 1566 associated with it. 1568 The authentication data field contains the MAC (Message 1569 Authentication Code) calculated over the entire SCSP payload. The 1570 length of this field is dependent on the hash algorithm used to 1571 calculate the MAC. 1573 B.3.1.2 Supported Hash Algorithms 1575 The default hash algorithm to be supported is HMAC-MD5-128 [11]. HMAC 1576 is safer than normal keyed hashes. Other hash algorithms MAY be 1577 supported by def. 1579 IANA will assign the numbers to identify the algorithm being used 1580 (see Section C). The WG will approve requests as they come in. 1582 B.3.1.3 SPI and Security Parameters Negotiation 1584 SPI's can be negotiated either manually or using an Internet Key 1585 Management protocol. Manual keying MUST be supported. The following 1586 parameters are associated with the tuple - lifetime, 1587 Algorithm, Key. Lifetime indicates the duration in seconds for which 1588 the key is valid. In case of manual keying, this duration can be 1589 infinite. Also, in order to better support manual keying, there may 1590 be multiple tuples active at the same time (DCS ID being the same). 1592 Any Internet standard key management protocol MAY be used to 1593 negotiate the SPI and parameters. 1595 B.3.1.4 Message Processing 1597 At the time of adding the authentication extension header, LS looks 1598 up in a table to fetch the SPI and the security parameters based on 1599 the DCS ID. If there are no entries in the table and if there is 1600 support for key management, the LS initiates the key management 1601 protocol to fetch the necessary parameters. The LS then calculates 1602 the hash by zeroing authentication data field before calculating the 1603 MAC on the sending end. The result replaces in the zeroed 1604 authentication data field. If key management is not supported and 1605 authentication is mandatory, the packet is dropped and this 1606 information is logged. 1608 When receiving traffic, an LS fetches the parameters based on the SPI 1609 and its ID. The authentication data field is extracted before zeroing 1610 out to calculate the hash. It computes the hash on the entire payload 1611 and if the hash does not match, then an "abnormal event" has 1612 occurred. 1614 B.3.1.5 Security Considerations 1616 It is important that the keys chosen are strong as the security of 1617 the entire system depends on the keys being chosen properly and the 1618 correct implementation of the algorithms. 1620 B.3.2 SCSP Vendor-Private Extension 1622 Type = 2 1623 Length = variable 1625 The SCSP Vendor-Private Extension is carried in SCSP packets to 1626 convey vendor-private information between an LS and a DCS in the same 1627 SG and is thus of limited use. If a finer granularity (e.g., CSA 1628 record level) is desired then then given client/server protocol 1629 specific SCSP document MUST define such a mechanism. Obviously, 1630 however, such a protocol specific mechanism might look exactly like 1631 this extension. The Vendor Private Extension MAY NOT appear more 1632 than once in an SCSP packet for a given Vendor ID value. 1634 0 1 2 3 1635 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 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Vendor ID | Data.... | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 Vendor ID 1641 802 Vendor ID as assigned by the IEEE [7]. 1643 Data 1644 The remaining octets after the Vendor ID in the payload are 1645 vendor-dependent data. 1647 If the receiver does not handle this extension, or does not match the 1648 Vendor ID in the extension then the extension may be completely 1649 ignored by the receiver. 1651 C. IANA Considerations 1652 IANA will redirect requests for numbers in the various number spaces 1653 described herein to the working group chairs. Currently, these 1654 chairs are Andy Malis (malis@ascend.com) and George Swallow 1655 (swallow@cisco.com). The working group chair(s) will accept any and 1656 all requests for value assignment as long as the client/server 1657 protocol specific document exists (i.e., the protocol specific 1658 document has been published as an internet draft or informational 1659 RFC). 1661 References 1663 [1] "Classical IP and ARP over ATM", Laubach, RFC 1577. 1665 [2] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello, 1666 Cole, draft-ietf-rolc-nhrp-12.txt. 1668 [3] "OSPF Version 2", Moy, RFC1583. 1670 [4] "P-NNI V1", Dykeman, Goguen, 1996. 1672 [5] "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", 1673 Armitage, RFC2022. 1675 [6] "LAN Emulation over ATM Version 2 - LNNI specification", Keene, 1676 btd-lane-lnni-02.08. 1678 [7] "Assigned Numbers", Reynolds, Postel, RFC 1700. 1680 [8] "A Distributed NHRP Service Using SCSP", Luciani, 1681 draft-ietf-ion-scsp-nhrp-02.txt. 1683 [9] "A Distributed ATMARP Service Using SCSP", Luciani, 1684 Work In Progress. 1686 [10] "Key words for use in RFCs to Indicate Requirement Levels", 1687 S. Bradner, RFC 2119. 1689 [11] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare, 1690 Canetti, RFC 2104. 1692 Acknowledgments 1694 This I-D is a distillation of issues raised during private 1695 discussions, on the IP-ATM mailing list, and during the Dallas IETF 1696 (12/95). Thanks to all who have contributed but particular thanks to 1697 following people (in no particular order): Naganand Doraswami of Bay 1698 Networks; Barbara Fox of Harris and Jeffries; Colin Verrilli of IBM; 1699 Raj Nair, and Matthew Doar of Ascom Nexion; Andy Malis of Cascade; 1700 Andre Fredette of Bay Networks; James Watt of Newbridge; and Carl 1701 Marcinik of Fore. 1703 Author's Address 1705 James V. Luciani 1706 Bay Networks, Inc. 1707 3 Federal Street, BL3-04 1708 Billerica, MA 01821 1709 phone: +1-508-916-4734 1710 email: luciani@baynetworks.com 1712 Grenville Armitage 1713 Bellcore, 445 South Street 1714 Morristown, NJ, 07960 1715 Email: gja@thumper.bellcore.com 1716 Ph. +1 201 829 2635 1718 Joel M. Halpern 1719 Newbridge Networks Corp. 1720 593 Herndon Parkway 1721 Herndon, VA 22070-5241 1722 Phone: +1-703-708-5954 1723 Email: jhalpern@Newbridge.COM