idnits 2.17.1 draft-ietf-ion-scsp-01.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-16) 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 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 are 49 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 174: '...al. In order to do this, every LS MUST...' RFC 2119 keyword, line 220: '...message) then the LS MUST consider the...' RFC 2119 keyword, line 238: '...M per DCS, an LS MUST send only a sing...' RFC 2119 keyword, line 383: '...ate and the message MUST be discarded....' RFC 2119 keyword, line 387: '... CA message MUST be processed. A...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 1997) is 9710 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 1528, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1531, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1534, 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-11 ** 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-00 == Outdated reference: A later version (-01) exists of draft-ietf-ion-scsp-atmarp-00 -- Possible downref: Normative reference to a draft: ref. '9' -- Duplicate reference: RFC1700, mentioned in '10', was also mentioned in '7'. ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 7 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 Grenville Armitage 5 (Bellcore) 6 Joel Halpern 7 (Newbridge) 8 Expires September 1997 10 Server Cache Synchronization Protocol (SCSP) 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 30 Abstract 32 This document describes the Server Cache Synchronization Protocol 33 (SCSP) and is written in terms of SCSP's use within Non Broadcast 34 Multiple Access (NBMA) networks; although, a somewhat straight 35 forward usage is applicable to BMA networks. SCSP attempts to solve 36 the generalized cache synchronization/cache-replication problem for 37 distributed protocol entities. However, in this document, SCSP is 38 couched in terms of the client/server paradigm in which distributed 39 server entities, which are bound to a Server Group (SG) through some 40 means, wish to synchronize the contents (or a portion thereof) of 41 their caches which contain information about the state of clients 42 being served. 44 1. Introduction 46 It is perhaps an obvious goal for any protocol to not limit itself to 47 a single point of failure such as having a single server in a 48 client/server paradigm. Even when there are redundant servers, there 49 still remains the problem of cache synchronization; i.e., when one 50 server becomes aware of a change in state of cache information then 51 that server must propagate the knowledge of the change in state to 52 all servers which are actively mirroring that state information. 53 Further, this must be done in a timely fashion without putting undo 54 resource strains on the servers. Assuming that the state information 55 kept in the server cache is the state of clients of the server, then 56 in order to minimize the burden placed upon the client it is also 57 highly desirable that clients need not have complete knowledge of all 58 servers which they may use. However, any mechanism for 59 synchronization should not preclude a client from having access to 60 several (or all) servers. Of course, any solution must be reasonably 61 scalable, capable of using some auto-configuration service, and lend 62 itself to a wide range of authentication methodologies. 64 This document describes the Server Cache Synchronization Protocol 65 (SCSP). SCSP solves the generalized server synchronization/cache- 66 replication problem while addressing the issues described above. 67 SCSP synchronizes caches (or a portion of the caches) of a set of 68 server entities of a particular protocol which are bound to a Server 69 Group (SG) through some means (e.g., all NHRP servers belonging to a 70 Logical IP Subnet (LIS)[1]). The client/server protocol which a 71 particular server uses is identified by a Protocol ID (PID). SGs are 72 identified by an ID which, not surprisingly, is called a SGID. Note 73 therefore that the combination PID/SGID identifies both the 74 client/server protocol for which the servers of the SG are being 75 synchronized as well as the instance of that protocol. This implies 76 that multiple instances of the same protocol may be in operation at 77 the same time and have their servers synchronized independently of 78 each other. SGs may exist in any topology as long as the resultant 79 graph spans the set of servers that need to be synchronized. The 80 caches which are to be synchronized contain information on the state 81 of the clients within the scope of interest of the SG. An example of 82 types of information that must be synchronized can be seen in NHRP[2] 83 using IP where the information includes the REGISTERED clients' IP to 84 NBMA mappings in the SG LIS. 86 The SCSP specification is not useful as a stand alone protocol. It 87 must be coupled with the use of an SCSP Protocol Specific 88 specification which defines how a given protocol would make use of 89 the synchronization primitives supplied by SCSP. Such specification 90 will be done in separate documents; e.g., [8][9]. 92 2. Overview 94 SCSP places no topological requirements upon the SG. Obviously, 95 however, the resultant graph must span the set of servers to be 96 synchronized. SCSP borrows its cache distribution mechanism from the 97 link state protocols [3,4]. However, unlike those technologies, 98 there is no mandatory Shortest Path First (SPF) calculation, and SCSP 99 imposes no additional memory requirements above and beyond that which 100 is required to save the cached information which would exist 101 regardless of the synchronization technology. 103 In order to give a frame of reference for the following discussion, 104 the terms Local Server (LS), Directly Connected Server (DCS), and 105 Remote Server (RS) are introduced. The LS is the server under 106 scrutiny; i.e., all statements are made from the perspective of the 107 LS when discussing the SCSP protocol. The DCS is a server which is 108 directly connected to the LS; e.g., there exists a VC between the LS 109 and DCS. Thus, every server is a DCS from the point of view of every 110 other server which connects to it directly, and every server is an LS 111 which has zero or more DCSs directly connected to it. From the 112 perspective of an LS, an RS is a server, separate from the LS, which 113 is not directly connected to the LS (i.e., an RS is always two or 114 more hops away from an LS whereas a DCS is always one hop away from 115 an LS). 117 SCSP contains three sub protocols: the "Hello" protocol, the "Cache 118 Alignment" protocol, and the "Cache State Update" protocol. The 119 "Hello" protocol is used to ascertain whether a DCS is operational 120 and whether the connection between the LS and DCS is bidirectional, 121 unidirectional, or non-functional. The "Cache Alignment" (CA) 122 protocol allows an LS to synchronize its entire cache with that of 123 the cache of its DCSs. The "Cache State Update" (CSU) protocol is 124 used to update the state of cache entries in servers for a given SG. 125 Sections 2.1, 2.2, and 2.3 contain a more in-depth explanation of the 126 Hello, CA, and CSU protocols and the messages they use. 128 SCSP based synchronization is performed on a per protocol instance 129 basis. That is, a separate instance of SCSP is run for each instance 130 of the given protocol running in a given box. The protocol is 131 identified in SCSP via a Protocol ID and the instance of the protocol 132 is identified by a Server Group ID (SGID). Thus the PID/SGID pair 133 uniquely identify an instance of SCSP. In general, this is not an 134 issue since it is seldom the case that many instances of a given 135 protocol (which is distributed and needs cache synchronization) are 136 running within the same physical box. However, when this is the 137 case, there is a mechanism called the Family ID (described briefly in 138 the Hello Protocol) which enables a substantial reduction in 139 maintenance traffic at little real cost in terms of control. The use 140 of the Family ID mechanism, when appropriate for a given protocol 141 which is using SCSP, will be fully defined in the given SCSP protocol 142 specific specification. 144 +---------------+ 145 | | 146 +-------@| DOWN |@-------+ 147 | | | | 148 | +---------------+ | 149 | | @ | 150 | | | | 151 | | | | 152 | | | | 153 | @ | | 154 | +---------------+ | 155 | | | | 156 | | WAITING | | 157 | +--| |--+ | 158 | | +---------------+ | | 159 | | @ @ | | 160 | | | | | | 161 | @ | | @ | 162 +---------------+ +---------------+ 163 | BIDIRECTIONAL |----@| UNIDIRECTIONAL| 164 | | | | 165 | CONNECTION |@----| CONNECTION | 166 +---------------+ +---------------+ 168 Figure 1: Hello Finite State Machine (HFSM) 170 2.1 Hello Protocol 172 "Hello" messages are used to ascertain whether a DCS is operational 173 and whether the connections between the LS and DCS are bidirectional, 174 unidirectional, or non-functional. In order to do this, every LS MUST 175 periodically send a Hello message to its DCSs. 177 An LS must be configured with a list of NBMA addresses which 178 represent the addresses of peer servers in a SG to which the LS 179 wishes to have a direct connection for the purpose of running SCSP; 180 that is, these addresses are the addresses of would-be DCSs. The 181 mechanism for the configuration of an LS with these NBMA address is 182 beyond the scope of this document; although one possible mechanism 183 would be an autoconfiguration server. 185 An LS has a Hello Finite State Machine (HFSM) associated with each of 186 its DCSs (see Figure 1) for a given SG, and the HFSM monitors the 187 state of the connectivity between the servers. 189 The HFSM starts in the "Down" State and transitions to the "Waiting" 190 State after NBMA level connectivity has been established. Once in 191 the Waiting State, the LS starts sending Hello messages to the DCS. 192 The Hello message includes: a Sender ID which is set to the LS's ID 193 (LSID), zero or more Receiver IDs which identify the DCSs from which 194 the LS has heard a Hello message, and a HelloInterval and DeadFactor 195 which will be described below. At this point, the DCS may or may 196 not already be sending its own Hello messages to the LS. 198 When the LS receives a Hello message from one of its DCSs, the LS 199 checks to see if its LSID is in one of the Receiver ID fields of that 200 message which it just received, and the LS saves the Sender ID from 201 that Hello message. If the LSID is in one of the Receiver ID fields 202 then the LS transitions the HFSM to the Bidirectional Connection 203 state otherwise it transitions the HFSM into the Unidirectional 204 Connection state. The Sender ID which was saved is the DCS's ID 205 (DCSID). The next time that the LS sends its own Hello message to 206 the DCS, the LS will check the saved DCSID against a list of Receiver 207 IDs which the LS uses when sending the LS's own Hello messages. If 208 the DCSID is not found in the list of Receiver IDs then it is added 209 to that list before the LS sends its Hello message. 211 Hello messages also contain a HelloInterval and a DeadFactor. The 212 Hello interval advertises the time (in seconds) between sending of 213 consecutive Hello messages by the server which is sending the 214 "current" Hello message. That is, if the time between reception of 215 Hello messages from a DCS exceeds the HelloInterval advertised by 216 that DCS then the next Hello message is to be considered late by the 217 LS. If the LS does not receive a Hello message, which contains the 218 LS's LSID in one of the Receiver ID fields, within the interval 219 HelloInterval*DeadFactor seconds (where DeadFactor was advertised by 220 the DCS in a previous Hello message) then the LS MUST consider the 221 DCS to be stalled. At which point one of two things will happen: 1) 222 if any Hello messages have been received during the last 223 HelloInterval*DeadFactor seconds then the LS should transition the 224 HFSM for that DCS to the Unidirectional Connection State; otherwise, 225 the LS should transition the HFSM for that DCS to the Waiting State 226 and remove the DCSID from the Receiver ID list. 228 Note that the Hello Protocol is on a per PID/SGID basis. Thus, for 229 example, if there are two servers (one in SG A and the other in SG B) 230 associated with an NBMA address X and another two servers (also one 231 in SG A and the other in SG B) associated with NBMA address Y and 232 there is a suitable point-to-point VC between the NBMA addresses then 233 there are two HFSMs running on each side of the VC (one per 234 PID/SGID). 236 Hello messages contain a list of Receiver IDs instead of a single 237 Receiver ID in order to make use of point to multipoint connections. 238 While there is an HFSM per DCS, an LS MUST send only a single Hello 239 message to its DCSs attached as leaves of a point to multipoint 240 connection. The LS does this by including DCSIDs in the list of 241 Receiver IDs when the LS's sends its next Hello message. Only the 242 DCSIDs from non-stalled DCSs from which the LS has heard a Hello 243 message are included. 245 Any abnormal event, such as receiving a malformed SCSP message, 246 causes the HFSM to transition to the Waiting State; however, a loss 247 of NBMA connectivity causes the HFSM to transition to the Down State. 248 Until, the HFSM is in the Bidirectional Connection State any properly 249 formed SCSP messages other than Hello messages must be ignored (this 250 is for the case where, for example, there is a point to multipoint 251 connection involved). 253 +------------+ 254 | | 255 +---@| DOWN | 256 | | | 257 | +------------+ 258 | | 259 | | 260 | @ 261 | +------------+ 262 | |Master/Slave| 263 |----| |@---+ 264 | |Negotiation | | 265 | +------------+ | 266 | | | 267 | | | 268 | @ | 269 | +------------+ | 270 | | Cache | | 271 |----| |----| 272 | | Summarize | | 273 | +------------+ | 274 | | | 275 | | | 276 | @ | 277 | +------------+ | 278 | | Update | | 279 |----| |----| 280 | | Cache | | 281 | +------------+ | 282 | | | 283 | | | 284 | @ | 285 | +------------+ | 286 | | | | 287 +----| Aligned |----+ 288 | | 289 +------------+ 291 Figure 2: Cache Alignment Finite State Machine 293 2.2 Cache Alignment Protocol 295 "Cache Alignment" (CA) messages are used by an LS to synchronize its 296 cache with that of the cache of each of its DCSs. That is, CA 297 messages allow a booting LS to synchronize with each of its DCSs. A 298 CA message contains a CA header followed by zero or more Cache State 299 Advertisement Summary records (CSAS records). 301 An LS has a Cache Alignment Finite State Machine (CAFSM) associated 302 (see Figure 2) with each of its DCSs on a per PID/SGID basis, and the 303 CAFSM monitors the state of the cache alignment between the servers. 304 The CAFSM starts in the Down State. The CAFSM is associated with an 305 HFSM, and when that HFSM reaches the Bidirectional State, the CAFSM 306 transitions to the Master/Slave Negotiation State. The Master/Slave 307 Negotiation State causes either the LS or DCS to take on the role of 308 master over the cache alignment process. 310 When the LS's CAFSM reaches the Master/Slave Negotiation State, the 311 LS will send a CA message to the DCS associated with the CAFSM. The 312 format of CA messages are described in Section B.2.1. The first CA 313 message which the LS sends includes no CSAS records and a CA header 314 which contains the LSID in the Sender ID field, the DCSID in the 315 Receiver ID field, a CA sequence number, and three bits. These three 316 bits are the M (Master/Slave) bit, the I (Initialization of master) 317 bit, and the O (More) bit. In the first CA message sent by the LS to 318 a particular DCS, the M, O, and I bits are set to one. If the LS 319 does not receive a CA message from the DCS in CAReXmtInterval seconds 320 then it resends the CA message it just sent. The LS continues to do 321 this until the CAFSM transitions to the Cache Summarize State or 322 until the HFSM transitions out of the Bidirectional State. Any time 323 the HFSM transitions out of the Bidirectional State, the CAFSM 324 transitions to the Down State. 326 2.2.1 Master Slave Negotiation State 328 When the LS receives a CA message from the DCS while in the 329 Master/Slave Negotiation State, the role the LS plays in the exchange 330 depends on packet processing as follows: 332 1) If the CA from the DCS has the M, I, and O bits set to one and there are 333 no CSAS records in the CA message and the Sender ID as specified in the 334 DCS's CA message is larger than the LSID then 335 a) The timer counting down the CAReXmtInterval is stopped. 336 b) The CAFSM corresponding to that DCS transitions to the Cache Summarize 337 State and the LS takes on the role of slave. 338 c) The LS adopts the CA sequence number it received in the CA message 339 as its 340 own CA sequence number. 341 d) The LS sends a CA message to the DCS which is formated as follows: 342 the M and I bits are set to zero, the Sender ID field is set to the 343 LSID, the Receiver ID field is set to the DCSID, and the CA sequence 344 number is set to the CA sequence number that appeared in the DCS's 345 CA message. If there are CSAS records to be sent (i.e., if the LS's 346 cache is not empty) then the O bit is set to one and the initial set 347 of CSAS records are included in the CA message. 349 2) If the CA message from the DCS has the M and I bits off and the 350 Sender ID 351 as specified in the DCS's CA message is smaller than the LSID then 352 a) The timer counting down the CAReXmtInterval is stopped. 353 b) The CAFSM corresponding to that DCS transitions to the Cache Summarize 354 State and the LS takes on the role of master. 355 c) The LS must process the received CA message. 356 An explanation of CA message processing is given below. 357 d) The LS sends a CA message to the DCS which is formated as follows: 358 the M bit is set to one, I bit is set to zero, the Sender ID 359 field is set to the LSID, the Receiver ID field is set to the DCSID, 360 and the LS's current CA sequence number is incremented by one and 361 placed 362 in the CA message. If there are any CSAS records to be sent from the 363 LS to the DCS (i.e., if the LS's cache is not empty) then the O bit is 364 set to one and the initial set of CSAS records are included in the 365 CA message that the LS is sending to the DCS. 367 3) Otherwise, the packet must be ignored. 369 2.2.2 The Cache Summarize State 371 At any given time, the master or slave have at most one outstanding 372 CA message. Once the LS's CAFSM has transitioned to the Cache 373 Summarize State the sequence of exchanges of CA messages occurs as 374 follows. 376 1) If the LS receives a CA message with the M bit set incorrectly 377 (e.g., the M bit is set in the CA of the DCS and the LS is master) 378 or if the I bit is set then the CAFSM transitions back to the 379 Master/Slave Negotiation State. 381 2) If the LS is master and the LS receives a CA message with a CA sequence 382 number which is one less than the LS's current CA sequence number then 383 the message is a duplicate and the message MUST be discarded. 385 3) If the LS is master and the LS receives a CA message with a CA sequence 386 number which is equal to the LS's current CA sequence number then the 387 CA message MUST be processed. An explanation of "CA message processing" 388 is given below. As a result of having received the CA message from 389 the DCS the following will occur: 390 a) The timer counting down the CAReXmtInterval is stopped. 391 b) The LS must process any CSAS records in the received CA message. 392 c) Increment the LS's CA sequence number by one. 393 d) The cache exchange continues as follows: 394 1) If the LS has no more CSAS records to send and the received CA 395 message has the O bit off then the CAFSM transitions to the Update 396 Cache State. 397 2) If the LS has no more CSAS records to send and the received CA 398 message has the O bit on then the LS sends back a CA message 399 (with new CA sequence number) which contains no CSAS records and 400 with the O bit off. Reset the timer counting down the 401 CAReXmtInterval. 402 3) If the LS has more CSAS records to send then the LS sends the next 403 CA message with the LS's next set of CSAS records. If LS is sending 404 its last set of CSAS records then the O bit is set off otherwise the 405 O bit is set on. Reset the timer counting down the CAReXmtInterval. 407 4) If the LS is slave and the LS receives a CA message with a CA sequence 408 number which is equal to the LS's current CA sequence number then the 409 CA message is a duplicate and the LS MUST resend the CA message 410 which it had just sent to the DCS. 412 5) If the LS is slave and the LS receives a CA message with a CA sequence 413 number which is one more than the LS's current CA sequence number then 414 the message is valid and MUST be processed. An explanation of "CA 415 message 416 processing" is given below. As a result of having received the CA 417 message from the DCS the following will occur: 419 a) The LS must process any CSAS records in the received CA message. 420 b) Set the LS's CA sequence number to the CA sequence number in the CA 421 message. 422 c) The cache exchange continues as follows: 423 1) If the LS had just sent a CA message with the O bit off and the 424 received CA message has the O bit off then the CAFSM transitions to 425 the Update Cache State and the LS sends a CA message with no CSAS 426 records and with the O bit off. 427 2) If the LS still has CSAS records to send then the LS MUST send 428 a CA message with CSAS records in it. 429 a) If the message being sent from the LS to the DCS does not contain 430 the last CSAS records that the LS needs to send then the CA 431 message is sent with the O bit on. 432 b) If the message being sent from the LS to the DCS does contain 433 the last CSAS records that the LS needs to send and 434 the CA message just received from the DCS had the O bit off then 435 the CA message is sent with the O bit off, and the LS transitions 436 the CAFSM to the Update Cache State. 437 c) If the message being sent from the LS to the DCS does contain 438 the last CSAS records that the LS needs to send and 439 the CA message just received from the DCS had the O bit on then 440 the CA message is sent with the O bit off and the alignment 441 process continues. 443 6) If the LS is slave and the LS receives a CA message with a CA sequence 444 number that is neither equal to nor one more than the current LS's 445 CA sequence number then an error has occurred and the CAFSM transitions 446 to the Master/Slave Negotiation State. 448 Note that if the LS was slave during the CA process then the LS upon 449 transitioning the CAFSM to the Update Cache state MUST keep a copy of 450 the last CA message it sent and set a timer equal to CAReXmtInterval. 451 If either the timer expires or the LS receives a CSU Solicit (CSUS) 452 message (CSUS messages are described in Section 2.2.3) from the DCS 453 then the LS releases the copy of the CA message. The reason for this 454 is that if the DCS (which is master) loses the last CA message sent 455 by the LS then the DCS will resend its previous CA message with the 456 last CA Sequence number used. If that were to occur the LS would 457 need to resend its last sent CA message as well. 459 2.2.2.1 "CA message processing": 461 The LS makes a list of those cache entries which are more "up to 462 date" in the DCS than the LS's own cache. This list is called the 463 CSA Request List (CRL). See Section 2.4 for a description of what it 464 means for a CSA (Client State Advertisement) record or CSAS record to 465 be more "up to date" than an LS's cache entry. 467 2.2.3 The Update Cache State 469 If the CRL of the associated CAFSM of the LS is empty upon transition 470 into the Update Cache State then the CAFSM immediately transitions 471 into the Aligned State. 473 If the CRL is not empty upon transition into the Update Cache State 474 then the LS solicits the DCS to send the CSA records corresponding to 475 the summaries (i.e., CSAS records) which the LS holds in its CRL. The 476 solicited CSA records will contain the entirety of the cached 477 information held in the DCS's cache for the given cache entry. The 478 LS solicits the relevant CSA records by forming CSU Solicit (CSUS) 479 messages from the CRL. See Section B.2.4 for the description of the 480 CSUS message format. The LS then sends the CSUS messages to the DCS. 481 The DCS responds to the CSUS message by sending to the LS one or more 482 CSU Request messages containing the entirety of newer cached 483 information identified in the CSUS message. Upon receiving the CSU 484 Request the LS will send one or more CSU Replies as described in 485 Section 2.3. Note that the LS may have at most one CSUS message 486 outstanding at any given time. 488 Just before the first CSUS message is sent from an LS to the DCS 489 associated with the CAFSM, a timer is set to CSUSReXmtInterval 490 seconds. If all the CSA records corresponding to the CSAS records in 491 the CSUS message have not been received by the time that the timer 492 expires then a new CSUS message will be created which contains all 493 the CSAS records for which no appropriate CSA record has been 494 received plus additional CSAS records not covered in the previous 495 CSUS message. The new CSUS message is then sent to the DCS. If, at 496 some point before the timer expires, all CSA record updates have been 497 received for all the CSAS records included in the previously sent 498 CSUS message then the timer is stopped. Once the timer is stopped, 499 if there are additional CSAS records that were not covered in the 500 previous CSUS message but were in the CRL then the timer is reset and 501 a new CSUS message is created which contains only those CSAS records 502 from the CRL which have not yet been sent to the DCS. This process 503 continues until all the CSA records corresponding CSAS records that 504 were in the CRL have been received by the LS. When the LS has a 505 completely updated cache then the LS transitions CAFSM associated 506 with the DCS to the Aligned State. 508 If an LS receives a CSUS message or a CA message with a Receiver ID 509 which is not the LS's LSID then the message must be discarded and 510 ignored. This is necessary since an LS may be a leaf of a point to 511 multipoint connection with other servers in the SG. 513 2.2.4 The Aligned State 515 While in the Aligned state, an LS will perform the Cache State Update 516 Protocol as described in Section 2.3. 518 Note that an LS may receive a CSUS message while in the Aligned State 519 and, the LS MUST respond to the CSUS message with the appropriate CSU 520 Request message in a similar fashion to the method previously 521 described in Section 2.2.3. 523 2.3 Cache State Update Protocol 525 "Cache State Update" (CSU) messages are used to dynamically update 526 the state of cache entries in servers on a given PID/SGID basis. CSU 527 messages contain zero or more "Cache State Advertisement" (CSA) 528 records each of which contains its own snapshot of the state of a 529 particular cache entry. An LS may send/receive a CSU to/from a DCS 530 only when the corresponding CAFSM is in either the Aligned State or 531 the Update Cache State. 533 There are two types of CSU messages: CSU Requests and CSU Replies. 534 See Sections B.2.2 and B.2.3 respectively for message formats. A CSU 535 Request message is sent from an LS to one or more DCSs for one of two 536 reasons: either the LS has received a CSUS message and MUST respond 537 only to the DCS which originated the CSUS message, or the LS has 538 become aware of a change of state of a cache entry. An LS becomes 539 aware of a change of state of a cache entry either through receiving 540 a CSU Request from one of its DCSs or as a result of a change of 541 state being observed in a cached entry originated by the LS. In the 542 former case, the LS will send a CSU Request to each of its DCSs 543 except the DCS from which the LS became aware of the change in state. 544 In the latter case, the LS will send a CSU Request to each of its 545 DCSs. The change in state of a particular cache entry is noted in a 546 CSA record which is then appended to the end of the CSU Request 547 message mandatory part. In this way, state changes are propagated 548 throughout the SG. 550 Examples of such changes in state are as follows: 552 1) an server receives a request from a client to add an entry to its 553 cache, 554 2) an server receives a request from a client to remove an entry 555 from its 556 cache 557 3) a cache entry has timed out in the server's cache, has been 558 refreshed 559 in the server's cache, or has been administratively modified 561 When an LS receives a CSU Request from one of its DCSs, the LS 562 acknowledges one or more CSA Records which were contained in the CSU 563 Request by sending a CSU Reply. The CSU Reply contains one or more 564 CSAS records which correspond to those CSA records which are being 565 acknowledged. Thus, for example, if a CSA record is dropped (or 566 delayed in processing) by the LS because there are insufficient 567 resources to process it then a corresponding CSAS record is not 568 included in the CSU Reply to the DCS. 570 Note that an LS may send multiple CSU Request messages before 571 receiving a CSU Reply acknowledging any of the CSA Records contained 572 in the CSU Requests. Note also that a CSU Reply may contain 573 acknowledgments for CSA Records from multiple CSU Requests. Thus, 574 the terms "request" and "reply" may be a bit confusing. 576 Note that a CSA Record contains a CSAS Record followed by 577 client/server protocol specific information contained in a cache 578 entry (see Section B.2.0.2 for CSAS record format information and 579 Section B.2.2.1 for CSA record format information). When a CSA 580 record is considered by the LS to represent cached information which 581 is more "up to date" (see Section 2.4) than the cached information 582 contained within the cache of the LS then two things happen: 1) the 583 LS's cache is updated with the more up to date information, and 2) 584 the LS sends a CSU Request containing the CSA Record to each of its 585 DCSs except the one from which the CSA Record arrived. In this way, 586 state changes are propagated within the PID/SGID. Of course, at some 587 point, the LS will also acknowledge the reception of the CSA Record 588 by sending the appropriate DCS a CSU Reply message containing the 589 corresponding CSAS Record. 591 When an LS sends a new CSU Request, the LS keeps track of the 592 outstanding CSA records in that CSU Request and to which DCSs the LS 593 sent the CSU Request. For each DCS to which the CSU Request was 594 sent, a timer set to CSUReXmtInterval seconds is started just prior 595 to sending the CSU Request. This timer is associated with the CSA 596 Records contained in that CSU Request such that if that timer expires 597 prior to having all CSA Records acknowledged from that DCS then (and 598 only then) a CSU Request is re-sent by the LS to that DCS. However, 599 the re-sent CSU Request only contains those CSA Records which have 600 not yet been acknowledged. If all CSA Records associated with a 601 timer becomes acknowledged then the timer is stopped. Note that the 602 re-sent CSA Records follow the same time-out and retransmit rules as 603 if they were new. Retransmission will occur a configured number of 604 times for a given CSA Record and if acknowledgment fails to occur 605 then an "abnormal event" has occurred at which point the then the 606 HFSM associated with the DCS is transitioned to the Waiting State. 608 A CSA Record instance is said to be on a "DCS retransmit queue" when 609 it is associated with the previously mentioned timer. Only the most 610 up-to-date CSA Record is permitted to be queued to a given DCS 611 retransmit queue. Thus, if a less up-to-date CSA Record is queued to 612 the DCS retransmit queue when a newer CSA Record instance is about to 613 be queued to that DCS retransmit queue then the older CSA Record 614 instance is dequeued and disassociated with its timer immediately 615 prior to enqueuing the newer instance of the CSA Record. 617 When an LS receives a CSU Reply from one of its DCSs then the LS 618 checks each CSAS record in the CSU Reply against the CSAS Record 619 portion of the CSA Records which are queued to the DCS retransmit 620 queue. 622 1) If there exists an exact match between the CSAS record portion 623 of the CSA record and a CSAS Record in the CSU Reply then 624 that CSA Record is considered to be acknowledged and is thus 625 dequeued from the DCS retransmit queue and is 626 disassociated with its timer. 628 2) If there exists a match between the CSAS record portion 629 of the CSA record and a CSAS Record in the CSU Reply except 630 for the CSA Sequence number then 631 a) If the CSA Record queued to the DCS retransmit queue has a 632 CSA Sequence Number which is greater than the 633 CSA Sequence Number in the CSAS Record of the the CSU Reply then 634 the CSAS Record in the CSU Reply is ignored. 635 b) If the CSA Record queued to the DCS retransmit queue has a 636 CSA Sequence Number which is less than the 637 CSA Sequence Number in the CSAS Record of the the CSU Reply then 638 CSA Record which is queued to the DCS retransmit queue is 639 dequeued and the CSA Record is disassociated with its timer. 640 Further, a CSUS Message is sent to that DCS which sent the 641 more up-to-date CSAS Record. All normal CSUS processing 642 occurs as if the CSUS were sent as part of the CA protocol. 644 When an LS receives a CSU Request message which contains a CSA Record 645 which contains a CSA Sequence Number which is smaller than the CSA 646 Sequence number of the cached CSA then the LS MUST acknowledge the 647 CSA record in the CSU Request but it MUST do so by sending a CSU 648 Reply message containing the CSAS Record portion of the CSA Record 649 stored in the cache and not the CSAS Record portion of the CSA Record 650 contained in the CSU Request. 652 An LS responds to CSUS messages from its DCSs by sending CSU Request 653 messages containing the appropriate CSA records to the DCS. If an LS 654 receives a CSUS message containing a CSAS record for an entry which 655 is no longer in its database (e.g., the entry timed out and was 656 discarded after the Cache Alignment exchange completed but before the 657 entry was requested through a CSUS message), then the LS will respond 658 by copying the CSAS Record from the CSUS message into a CSU Request 659 message and the LS will set the N bit signifying that this record is 660 a NULL record since the cache entry no longer exists in the LS's 661 cache. Note that in this case, the "CSA Record" included in the CSU 662 Request to signify the NULL cache entry is literally only a CSAS 663 Record since no client/server protocol specific information exists 664 for the cache entry. 666 If an LS receives a CSA Record in a CSU Request from a DCS for which 667 the LS has an identical CSA record posted to the corresponding DCS's 668 DCS retransmit queue then the CSA Record on the DCS retransmit queue 669 is considered to be implicitly acknowledged. Thus, the CSA Record is 670 dequeued from the DCS retransmit queue and is disassociated with its 671 timer. The CSA Record sent by the DCS MUST still be acknowledged by 672 the LS in a CSU Reply, however. This is useful in the case of point 673 to multipoint connections where the rule that "when an LS receives a 674 CSA record from a DCS, that LS floods the CSA Record to every DCS 675 except the DCS from which it was received" might be broken. 677 If an LS receives a CSU with a Receiver ID which is not equal to the 678 LSID and is not set to all 0xFFs then the CSU must be discarded and 679 ignored. This is necessary since the LS may be a leaf of a point to 680 multipoint connection with other servers in the LS's SG. 682 An LS MAY send a CSU Request to the all 0xFFs Receiver ID when the LS 683 is a root of a point to multipoint connection with a set of its DCSs. 684 If an LS receives a CSU Request with the all 0xFFs Receiver ID then 685 it MUST use the Sender ID in the CSU Request as the Receiver ID of 686 the CSU Reply (i.e., it MUST unicast its response to the sender of 687 the request) when responding. If the LS wishes to send a CSU Request 688 to the all 0xFFs Receiver ID then it MUST create a time-out and 689 retransmit timer for each of the DCSs which are leaves of the point 690 to multipoint connection prior to sending the CSU Request. If in 691 this case, the time-out and retransmit timer expires for a given DCS 692 prior to acknowledgment of a given CSA Record then the LS MUST use 693 the specific DCSID as the Receiver ID rather than the all 0xFFs 694 Receiver ID. Similarly, if it is necessary to re-send a CSA Record 695 then the LS MUST specify the specific DCSID as the Receiver ID rather 696 than the all 0xFFs Receiver ID. 698 Note that if a set of servers are in a full mesh of point to 699 multipoint connections, and one server of that mesh sends a CSU 700 Request into that full mesh, and the sending server sends the CSA 701 Records in the CSU Request to the all 0xFFs Receiver ID then it would 702 not be necessary for every other server in the mesh to source their 703 own CSU Request containing those CSA Records into the mesh in order 704 to properly flood the CSA Records. This is because every server in 705 the mesh would have heard the CSU Request and would have processed 706 the included CSA Records as appropriate. Thus, a server in a full 707 mesh could consider the mesh to be a single logical port and so the 708 rule that "when an LS receives a CSA record from a DCS, that LS 709 floods the CSA Record to every DCS except the DCS from which it was 710 received" is not broken. A receiving server in the full mesh would 711 still need to acknowledge the CSA records with CSU Reply messages 712 which contain the LSID of the replying server as the Sender ID and 713 the ID of the server which sent the CSU Request as the Receiver ID 714 field. In the time out and retransmit case, the Receiver ID of the 715 CSU Request would be set to the specific DCSID which did not 716 acknowledge the CSA Record (as opposed to the all 0xFFs Receiver ID). 717 Since a full mesh emulates a broadcast media for the servers attached 718 to the full mesh, use of SCSP on a broadcast medium might use this 719 technique as well. Further discussion of this use of a full mesh or 720 use of a broadcast media is left to the client/server protocol 721 specific documents. 723 2.4 The meaning of "More Up To Date"/"Newness" 725 During the cache alignment process and during normal CSU processing, 726 a CSAS Record is compared against the contents of an LS's cache entry 727 to decide whether the information contained in the record is more "up 728 to date" than the corresponding cache entry of the LS. 730 There are three pieces of information which are used in determining 731 whether a record contains information which is more "up to date" than 732 the information contained in the cache entry of an LS which is 733 processing the record: 1) the Cache Key, 2) the Originator which is 734 described by an Originator ID (OID), and 3) the CSA Sequence number. 735 See Section B.2.0.2 for more information on these fields. 737 Given these three pieces of information, a CSAS record (be it part of 738 a CSA Record or be it stand-alone) is considered to be more "up to 739 date" than the information contained in the cache of an LS if all of 740 the following are true: 741 1) The Cache Key in the CSAS Record matches the stored Cache Key 742 in the LS's cache entry, 743 2) The OID in the CSAS Record matches the stored OID 744 in the LS's cache entry, 745 3) The CSA Sequence Number in the CSAS Record is greater than 746 CSA Sequence Number in the LS's cache entry. 748 Discussion and conclusions 750 While the above text is couched in terms of synchronizing the 751 knowledge of the state of a client within the cache of servers 752 contained in a SG, this solution generalizes easily to any number of 753 database synchronization problems (e.g., LECS synchronization). 755 SCSP defines a generic flooding protocol. There are a number of 756 related issues relative to cache maintenance and topology maintenance 757 which are more appropriately defined in the client/server protocol 758 specific documents; for example, it might be desirable to define a 759 generic cache entry time-out mechanism for a given protocol or to 760 advertise adjacency information between servers so that one could 761 obtain a topo-map of the servers in a SG. When mechanisms like these 762 are desirable, they will be defined in the client/server protocol 763 specific documents. 765 Appendix A: Terminology and Definitions 767 CA Message - Cache Alignment Message 768 These messages allow an LS to synchronize its entire cache with 769 that of the cache of one of its DCSs. 771 CAFSM - Cache Alignment Finite State Machine 772 The CAFSM monitors the state of the cache alignment between an LS 773 and a particular DCS. There exists one CAFSM per DCS as seen from 774 an LS. 776 CSA Record - Cache State Advertisement Record 777 A CSA is a record within a CSU message which identifies an update 778 to the status of a "particular" cache entry. 780 CSAS Record - Cache State Advertisement Summary Record 781 A CSAS contains a summary of the information in a CSA. A server 782 will send CSAS records describing its cache entries to another 783 server during the cache alignment process. CSAS records are also 784 included in a CSUS messages when an LS wants to request the entire 785 CSA from the DCS. The LS is requesting the CSA from the DCS 786 because the LS believes that the DCS has a more recent view of the 787 state of the cache entry in question. 789 CSU Message - Cache State Update message 790 This is a message sent from an LS to its DCSs when the LS becomes 791 aware of a change in state of a cache entry. 793 CSUS Message - Cache State Update Solicit Message 794 This message is sent by an LS to its DCS after the LS and DCS have 795 exchanged CA messages. The CSUS message contains one or more CSAS 796 records which represent solicitations for entire CSA records (as 797 opposed to just the summary information held in the CSAS). 799 DCS - Directly Connected Server 800 The DCS is a server which is directly connected to the LS; e.g., 801 there exists a VC between the LS and DCS. This term, along with the 802 terms LS and RS, is used to give a frame of reference when talking 803 about servers and their synchronization. Unless explicitly stated 804 to the contrary, there is no implied difference in functionality 805 between a DCS, LS, and RS. 807 HFSM - Hello Finite State Machine 808 An LS has a HFSM associated with each of its DCSs. The HFSM 809 monitors the state of the connectivity between the LS and a 810 particular DCS. 812 LS - Local Server 813 The LS is the server under scrutiny; i.e., all statements are made 814 from the perspective of the LS. This term, along with the terms 815 DCS and RS, is used to give a frame of reference when talking about 816 servers and their synchronization. Unless explicitly stated to the 817 contrary, there is no implied difference in functionality between a 818 DCS, LS, and RS. 820 LSID - Local Server ID 821 The LSID is a unique token that identifies an LS. This value might 822 be taken from the protocol address of the LS. 824 PID - Protocol ID 825 This field contains an identifier which identifies the 826 client/server protocol which is making use of SCSP for the given 827 message. The assignment of Protocol IDs for this field is given 828 over to IANA. 830 RS - Remote Server (RS) 831 From the perspective of an LS, an RS is a server, separate from the 832 LS, which is not directly connected to the LS (i.e., an RS is 833 always two or more hops away from an LS whereas a DCS is always one 834 hop away from an LS). Unless otherwise stated an RS refers to a 835 server in the SG. This term, along with the terms LS and DCS, is 836 used to give a frame of reference when talking about servers and 837 their synchronization. Unless explicitly stated to the contrary, 838 there is no implied difference in functionality between a DCS, LS, 839 and RS. 841 SG - Server Group 842 The SCSP synchronizes caches (or a portion of the caches) of a set 843 of server entities which are bound to a SG through some means 844 (e.g., all servers belonging to a Logical IP Subnet (LIS)[1]). 845 Thus an SG is just a grouping of servers around some commonality. 847 SGID - Server Group ID 848 This ID is a 16 bit identification field that uniquely identifies 849 the instance client/server protocol for which the servers of the SG 850 are being synchronized. This implies that multiple instances of 851 the same protocol may be in operation at the same time and have 852 their servers synchronized independently of each other. 854 Appendix B: SCSP Message Formats 856 This section of the appendix includes the message formats for SCSP. 857 SCSP protocols are LLC/SNAP encapsulated with an LLC=0xAA-AA-03 and 858 OUI=0x00-00-5e and PID=0x00-05. 860 SCSP has 3 parts to every packet: the fixed part, the mandatory part, 861 and the extensions part. The fixed part of the message exists in 862 every packet and is shown below. The mandatory part is specific to 863 the particular message type (i.e., CA, CSU Request/Reply, Hello, 864 CSUS) and, it includes (among other packet elements) a Mandatory 865 Common Part and zero or more records each of which contains 866 information pertinent to the state of a particular cache entry 867 (except in the case of a Hello message) whose information is being 868 synchronized within a SG. The extensions part contains the set of 869 extensions for the SCSP message. 871 In the following message formats, "unused" fields are set to zero on 872 when transmitting a message and these fields are ignored on receipt 873 of a message. 875 B.1 Fixed Part 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Version | Type Code | Packet Size | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Checksum | Start Of Extensions | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Version 885 This is the version of the SCSP protocol being used. The current 886 version is 1. 888 Type Code 889 This is the code for the message type (e.g., Hello (5), CSU 890 Request(2), CSU Reply(3), CSUS (4), CA (1)). 892 Packet Size 893 The total length of the SCSP packet, in octets (excluding link 894 layer and/or other protocol encapsulation). 896 Checksum 897 The standard IP checksum over the entire SCSP packet (starting with 898 the fixed header). 900 Start Of Extensions 901 This field is coded as zero when no extensions are present in the 902 message. If extensions are present then this field will be coded 903 with the offset from the top of the fixed header to the beginning 904 of the first extension. 906 B.2.0 Mandatory Part 908 The mandatory part of the SCSP packet contains the operation specific 909 information for a given message type (e.g., SCSP Cache State Update 910 Request/Reply, etc.), and it includes (among other packet elements) a 911 Mandatory Common Part (described in Section B.2.0.1) and zero or more 912 records each of which contains information pertinent to the state of 913 a particular cache entry (except in the case of a Hello message) 914 whose information is being synchronized within a SG. These records 915 may, depending on the message type, be either Cache State 916 Advertisement Summary (CSAS) Records (described in Section B.2.0.2) 917 or Cache State Advertisement (CSA) Records (described in Section 918 B.2.2.1). CSA Records contain a summary of a cache entry's 919 information (i.e., a CSAS Record) plus some additional client/server 920 protocol specific information. The mandatory common part format and 921 CSAS Record format is shown immediately below, prior to showing their 922 use in SCSP messages, in order to prevent replication within the 923 message descriptions. 925 B.2.0.1 Mandatory Common Part 927 Sections B.2.1 through B.2.5 have a substantial overlap in format. 928 This overlapping format is called the mandatory common part and its 929 format is shown below: 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Protocol ID | Server Group ID | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | unused | Flags | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Sender ID Len | Recvr ID Len | Number of Records | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Sender ID (variable length) | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Receiver ID (variable length) | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 Protocol ID 944 This field contains an identifier which identifies the 945 client/server protocol which is making use of SCSP for the given 946 message. The assignment of Protocol IDs for this field is given 947 over to IANA. IANA will accept any and all requests for value 948 assignment as long as the client/server protocol specific document 949 exists. Protocols with current documents have the the following 950 defined values: 951 1 - ATMARP 952 2 - NHRP 953 3 - MARS 954 4 - DHCP 955 5 - LNNI 957 Server Group ID 958 This ID is uniquely identifies the instance of a given 959 client/server protocol for which servers are being synchronized. 961 Flags 962 The Flags field is message specific, and its use will be described 963 in the specific message format sections below. 965 Sender ID Len 966 This field holds the length in octets of the Sender ID. 968 Recvr ID Len 969 This field holds the length in octets of the Receiver ID. 971 Number of Records 972 This field contains the number of additional records associated 973 with the given message. The exact format of these records is 974 specific to the message and will be described for each message type 975 in the sections below. 977 Sender ID 978 This is an identifier assigned to the server which is sending the 979 given message. One possible assignment might be the protocol 980 address of the sending server. 982 Receiver ID 983 This is an identifier assigned to the server which is to receive 984 the given message. One possible assignment might be the protocol 985 address of the server which is to receive the given message. 987 B.2.0.2 Cache State Advertisement Summary Record (CSAS record) 989 CSAS records contain a summary of information contained in a cache 990 entry of a given client/server database which is being synchronized 991 through the use of SCSP. The summary includes enough information for 992 SCSP to look into the client/server database for the appropriate 993 database cache entry and then compare the "newness" of the summary 994 against the "newness" of the cached entry. 996 Note that CSAS records do not contain a Server Group ID (SGID) nor do 997 they contain a Protocol ID. These IDs are necessary to identify 998 which protocol and which instance of that protocol for which the 999 summary is applicable. These IDs are present in the mandatory common 1000 part of each message. 1002 Note also that the values of the Hop Count and Record Length fields 1003 of a CSAS Record are dependent on whether the CSAS record exists as a 1004 "stand-alone" record or whether the CSAS record is "embedded" in CSA 1005 Record. This is further described below. 1007 0 1 2 3 1008 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 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Hop Count | Record Length | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Cache Key Len | Orig ID Len |N| unused | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | CSA Sequence Number | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Cache Key ... | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Originator ID ... | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 Hop Count 1022 This field represents the number of hops that the record may take 1023 before being dropped. Thus, at each server that the record 1024 traverses, the Hop Count is decremented. This field is set to 1 1025 when the CSAS record is a "stand-alone" record (i.e., it is not 1026 embedded within a CSA record) since summaries do not go beyond one 1027 hop during the cache alignment process. If a CSAS record is 1028 "embedded" within a CSA record then the Hop Count is set to an 1029 administratively defined value which is almost certainly 1030 proportional to the "diameter" of the SG being synchronized. 1032 Record Length 1033 If the CSAS record is a "stand-alone" record then this value is 1034 12+"Cache Key Leng"+"Orig ID Len" in bytes; otherwise, this value 1035 is set to 12+"Cache Key Leng"+"Orig ID Len"+ sizeof("Client/Server 1036 Protocol Specific Part for cache entry"). The size of the 1037 Client/Server Protocol Specific Part may be obtained from the 1038 client/server protocol specific document for the given Protocol ID. 1040 Cache Key Len 1041 Length of the Cache Key field in bytes. 1043 Orig ID Len. 1044 Length of the Originator ID field in bytes. 1046 N 1047 The "N" bit signifies that this CSAS Record is actually a Null 1048 record. This bit is only used in a CSAS Record contained in a CSU 1049 Request/Reply which is sent in response to a CSUS message. It is 1050 possible that an LS may receive a solicitation for a CSA record 1051 when the cache entry represented by the solicited CSA Record no 1052 longer exists in the LS's cache (see Section 2.3 for details). In 1053 this case, the LS copies the CSAS Record directly from the CSUS 1054 message into the CSU Request, and the LS sets the N bit signifying 1055 that the cache entry does not exist any longer. The DCS which 1056 solicited the CSA record which no longer exists will still respond 1057 with a CSU Reply. This bit is usually set to zero. 1059 CSA Sequence Number 1060 This field contains a sequence number that identifies the "newness" 1061 of a CSA record instance being summarized. A "larger" sequence 1062 number means a more recent advertisement. Thus, if the state of 1063 part (or all) of a cache entry needs to be updated then the CSA 1064 record advertising the new state MUST contain a CSA Sequence Number 1065 which is larger than the one corresponding to the previous 1066 advertisement. This number is assigned by the originator of the 1067 CSA record. The CSA Sequence Number may be assigned by the 1068 originating server or by the client which caused its server to 1069 advertise its existence. 1071 Cache Key 1072 This is a database lookup key that uniquely identifies a piece of 1073 data which the originator of a CSA Record wishes to synchronize 1074 with its peers for a given "Protocol ID/Server Group ID" pair. 1075 This key will generally be a small opaque byte string which SCSP 1076 will associate with a given piece of data in a cache. Thus, for 1077 example, an originator might assign a particular 4 byte string to 1078 the binding of an IP address with that of an ATM address. 1079 Generally speaking, the originating server of a CSA record is 1080 responsible for generating a Cache Key for every element of data 1081 that the the given server originates and which the server wishes to 1082 synchronize with its peers in the SG. 1084 Originator ID 1085 This field contains an ID administratively assigned to the server 1086 which is the originator of CSA Records. 1088 B.2.1 Cache Alignment (CA) 1090 The Cache Alignment (CA) message allows an LS to synchronize its 1091 entire cache with that of the cache of its DCSs within a server 1092 group. The CA message type code is 1. The CA message mandatory part 1093 format is as follows: 1095 0 1 2 3 1096 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 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | CA Sequence Number | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Mandatory Common Part | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | CSAS Record | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 ....... 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | CSAS Record | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 CA Sequence Number 1110 A value which provides a unique identifier to aid in the sequencing 1111 of the cache alignment process. A "larger" sequence number means a 1112 more recent CA message. The slave server always copies the 1113 sequence number from the master server's previous CA message into 1114 its current CA message which it is sending and the the slave 1115 acknowledges the master's CA message. Since the initial CA process 1116 is lock-step, if the slave does not receive the same sequence 1117 number which it previously received then the information in the 1118 slave's previous CA message is implicitly acknowledged. Note that 1119 there is a separate CA Sequence Number space associated with each 1120 CAFSM. 1122 Mandatory Common Part 1123 The mandatory common part is described in detail in Section 1124 B.2.0.1. There are two fields in the mandatory common part whose 1125 codings are specific to a given message type. These fields are the 1126 "Number of Records" field and the "Flags" field. 1128 Number of Records 1129 The Number of Records field of the mandatory common part for the 1130 CA message gives the number of CSAS Records appended to the CA 1131 message mandatory part. 1133 Flags 1134 The Flags field of the mandatory common part for the CA message 1135 has the following format: 1137 0 1 1138 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 |M|I|O| unused | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 M 1143 This bit is part of the negotiation process for the cache 1144 alignment. When this bit is set then the sender of the CA 1145 message is indicating that it wishes to lead the alignment 1146 process. This bit is the "Master/Slave bit". 1148 I 1149 When set, this bit indicates that the sender of the CA message 1150 believes that it is in a state where it is negotiating for the 1151 status of master or slave. This bit is the "Initialization 1152 bit". 1154 O 1155 This bit indicates that the sender of the CA message has more 1156 CSAS records to send. This implies that the cache alignment 1157 process must continue. This bit is the "mOre bit" despite its 1158 dubious name. 1160 All other fields of the mandatory common part are coded as 1161 described in Section B.2.0.1. 1163 CSAS record 1164 The CA message appends CSAS records to the end of its mandatory 1165 part. These CSAS records are NOT embedded in CSA records. See 1166 Section B.2.0.2 for details on CSAS records. 1168 B.2.2 Cache State Update Request (CSU Request) 1170 The Cache State Update Request (CSU Request) message is used to 1171 update the state of cache entries in servers which are directly 1172 connected to the server sending the message. A CSU Request message 1173 is sent from one server (the LS) to directly connected server (the 1174 DCS) when the LS observes changes in the state of one or more cache 1175 entries. An LS observes such a change in state by either receiving a 1176 CSU request which causes an update to the LS's database or by 1177 observing a change of state of a cached entry originated by the LS. 1178 The change in state of a cache entry is noted in a CSU message by 1179 appending a "Cache State Advertisement" (CSA) record to the end of 1180 the mandatory part of the CSU Request as shown below. 1182 The CSU Request message type code is 2. The CSU Request message 1183 mandatory part 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 | Mandatory Common Part | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | CSA Record | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 ....... 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | CSA Record | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Mandatory Common Part 1198 The mandatory common part is described in detail in Section 1199 B.2.0.1. There are two fields in the mandatory common part whose 1200 codings are specific to a given message type. These fields are the 1201 "Number of Records" field and the "Flags" field. 1203 Number of Records 1204 The Number of Records field of the mandatory common part for the 1205 CSU Request message gives the number of CSA Records appended to 1206 the CSU Request message mandatory part. 1208 Flags 1209 Currently, there are no flags defined for the Flags field of the 1210 mandatory common part for the CSU Request message. 1212 All other fields of the mandatory common part are coded as 1213 described in Section B.2.0.1. 1215 CSA Record 1216 See Section B.2.2.1. 1218 B.2.2.1 Cache State Advertisement Record (CSA record) 1220 CSA records contain the information necessary to relate the current 1221 state of a cache entry in an SG to the servers being synchronized. 1222 CSA records contain a CSAS Record header and a client/server protocol 1223 specific part. The CSAS Record includes enough information for SCSP 1224 to look into the client/server database for the appropriate database 1225 cache entry and then compare the "newness" of the summary against the 1226 "newness" of the cached entry. If the information contained in the 1227 CSA is more new than the cached entry of the receiving server then 1228 the cached entry is updated accordingly with the contents of the CSA 1229 Record. The client/server protocol specific part of the CSA Record 1230 is documented separately for each such protocol. Examples of the 1231 protocol specific parts for NHRP and ATMARP are shown in [8] and [9] 1232 respectively. 1234 The amount of information carried by a specific CSA record may exceed 1235 the size of a link layer PDU. Hence, such CSA records MUST be 1236 fragmented across a number of CSU Request messages. The method by 1237 which this is done, is client/server protocol specific and is 1238 documented in the appropriate protocol specific document. 1240 The content of a CSA record is as follows: 1242 0 1 2 3 1243 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 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | CSAS Record | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Client/Server Protocol Specific Part for cache entry ... | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 CSAS Record 1251 See Section B.2.0.2 for rules and format for filling out a CSAS 1252 Record when it is "embedded" in a CSA Record. 1254 Client/Server Protocol Specific Part for cache entry 1255 This field contains the fields which are specific to the protocol 1256 specific portion of SCSP processing. The particular set of fields 1257 are defined in separate documents for each protocol user of SCSP. 1258 The Protocol ID, which identifies which protocol is using SCSP in 1259 the given packet, is located in the mandatory part of the message. 1261 B.2.3 Cache State Update Reply (CSU Reply) 1263 The Cache State Update Reply (CSU Reply) message is sent from a DCS 1264 to an LS to acknowledge one or more CSA records which were received 1265 in a CSU Request. Reception of a CSA record in a CSU Request is 1266 acknowledged by including a CSAS record in the CSU Reply which 1267 corresponds to the CSA record being acknowledged. The CSU Reply 1268 message is the same in format as the CSU Request message except for 1269 the following: the type code is 3, only CSAS Records (rather than CSA 1270 records) are returned, and only those CSAS Records for which CSA 1271 Records are being acknowledged are returned. This implies that a 1272 given LS sending a CSU Request may not receive an acknowledgment in a 1273 single CSU Reply for all the CSA Records included in the CSU Request. 1275 B.2.4 Cache State Update Solicit Message (CSUS message) 1276 This message allows one server (LS) to solicit the entirety of CSA 1277 record data stored in the cache of a directly connected server (DCS). 1278 The DCS responds with CSU Request messages containing the appropriate 1279 CSA records. The CSUS message type code is 4. The CSUS message 1280 format is the same as that of the CSU Reply message. CSUS messages 1281 solicit CSU Requests from only one server (the one identified by the 1282 Receiver ID in the Mandatory Part of the message). 1284 B.2.5 Hello: 1286 The Hello message is used to check connectivity between the sending 1287 server (the LS) and one of its directly connected neighbor servers 1288 (the DCSs). The Hello message type code is 5. The Hello message 1289 mandatory part format is as follows: 1291 0 1 2 3 1292 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 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | HelloInterval | DeadFactor | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | unused | Family ID | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Mandatory Common Part | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Additional Receiver ID Record | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 ......... 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Additional Receiver ID Record | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 HelloInterval 1308 The hello interval advertises the time between sending of 1309 consecutive Hello Messages. If the LS does not receive a Hello 1310 message from the DCS (which contains the LSID as a Receiver ID) 1311 within the HelloInterval advertised by the DCS then the DCS's Hello 1312 is considered to be late. Also, the LS MUST send its own Hello 1313 message to a DCS within the HelloInterval which it advertised to 1314 the DCS in the LS's previous Hello message to that DCS (otherwise 1315 the DCS would consider the LS's Hello to be late). 1317 DeadFactor 1318 This is a multiplier to the HelloInterval. If an LS does not 1319 receive a Hello message which contains the LS's LSID as a Receiver 1320 ID within the interval HelloInterval*DeadFactor from a given DCS, 1321 which advertised the HelloInterval and DeadFactor in a previous 1322 Hello message, then the LS MUST consider the DCS to be stalled; at 1323 this point, one of two things MUST happen: 1) if the LS has 1324 received any Hello messages from the DCS during this time then the 1325 LS transitions the corresponding HFSM to the Unidirectional State; 1326 otherwise, 2) the LS transitions the corresponding HFSM to the 1327 Waiting State. 1329 Family ID 1330 This is an opaque bit string which is used to refer to an aggregate 1331 of Protocol ID/SGID pairs. Only a single HFSM is run for all 1332 Protocol ID/SGID pairs assigned to a Family ID. Thus, there is a 1333 one to many mapping between the single HFSM and the CAFSMs 1334 corresponding to each of the Protocol ID/SGID pairs. This might 1335 have the net effect of substantially reducing HFSM maintenance 1336 traffic. See the protocol specific SCSP documents for further 1337 details. 1339 Mandatory Common Part 1340 The mandatory common part is described in detail in Section 1341 B.2.0.1. There are two fields in the mandatory common part whose 1342 codings are specific to a given message type. These fields are the 1343 "Number of Records" field and the "Flags" field. 1345 Number of Records 1346 The Number of Records field of the mandatory common part for the 1347 Hello message contains the number of "Additional Receiver ID" 1348 records which are included in the Hello. Additional Receiver ID 1349 records contain a length field and a Receiver ID field. Note 1350 that the count in "Number of Records" does NOT include the 1351 Receiver ID which is included in the Mandatory Common Part. 1353 Flags 1354 Currently, there are no flags defined for the Flags field of the 1355 mandatory common part for the Hello message. 1357 All other fields of the mandatory common part are coded as 1358 described in Section B.2.0.1. 1360 Additional Receiver ID Record 1361 This record contains a length field followed by a Receiver ID. 1362 Since it is conceivable that the length of a given Receiver ID may 1363 vary even within an SG, each additional Receiver ID heard (beyond 1364 the first one) will have both its length in bytes and value encoded 1365 in an "Additional Receiver ID Record". Receiver IDs are IDs of a 1366 DCS from which the LS has heard a recent Hello (i.e., within 1367 DeadFactor*HelloInterval as advertised by the DCS in a previous 1368 Hello message). 1370 The format for this record is as follows: 1372 0 1 2 3 1373 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 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Rec ID Len | Receiver ID | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 If the LS has not heard from any DCS then the LS sets the Hello 1379 message fields as follows: Recvr ID Len is set to zero and no storage 1380 is allocated for the Receiver ID in the Common Mandatory Part, 1381 "Number of Records" is set to zero, and no storage is allocated for 1382 "Additional Receiver ID Records". 1384 If the LS has heard from exactly one DCS then the LS sets the Hello 1385 message fields as follows: the Receiver ID of the DCS which was heard 1386 and the length of that Receiver ID are encoded in the Common 1387 Mandatory Part, "Number of Records" is set to zero, and no storage is 1388 allocated for "Additional Receiver ID Records". 1390 If the LS has heard from two or more DCSs then the LS sets the Hello 1391 message fields as follows: the Receiver ID of the first DCS which was 1392 heard and the length of that Receiver ID are encoded in the Common 1393 Mandatory Part, "Number of Records" is set to the number of 1394 "Additional" DCSs heard, and for each additional DCS an "Additional 1395 Receiver ID Record" is formed and appended to the end of the Hello 1396 message. 1398 B.3 Extensions Part 1400 The Extensions Part, if present, carries one or more extensions in 1401 {Type, Length, Value} triplets. 1403 Extensions have the following format: 1405 0 1 2 3 1406 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 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Type | Length | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | Value... | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 Type 1414 The extension type code (see below). 1416 Length 1417 The length in octets of the value (not including the Type and 1418 Length fields; a null extension will have only an extension header 1419 and a length of zero). 1421 When extensions exist, the extensions part is terminated by the End 1422 of Extensions extension, having Type = 0 and Length = 0. 1424 Extensions may occur in any order but any particular extension type 1425 may occur only once in an SCSP packet. An LS MUST NOT change the 1426 order of extensions. 1428 B.3.0 The End Of Extensions 1430 Type = 0 1431 Length = 0 1433 When extensions exist, the extensions part is terminated by the End 1434 Of Extensions extension. 1436 B.3.1 SCSP Authentication Extension 1438 Type = 1 1439 Length = variable 1441 The SCSP Authentication Extension is carried in SCSP packets to 1442 convey authentication information between an LS and a DCS in the same 1443 SG. 1445 Authentication is done pairwise on an LS to DCS basis; i.e., the 1446 authentication extension is generated at each LS. If a received 1447 packet fails the authentication test then an "abnormal event" has 1448 occurred. Any "abnormal event" causes the HFSM associated with the 1449 server from which the packet was received to transition to the 1450 Waiting State. 1452 The presence or absence of the Authentication Extension is a local 1453 matter. 1455 0 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Authentication Type | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | | 1461 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1462 | | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 The Authentication Type field identifies the authentication method in 1466 use. Currently assigned values are: 1468 1 - Cleartext Password 1469 2 - Keyed MD5 1471 All other values are reserved. 1473 The Authentication Data field contains the type-specific 1474 authentication information. 1476 In the case of Cleartext Password Authentication, the Authentication 1477 Data consists of a variable length password. 1479 In the case of Keyed MD5 Authentication, the Authentication Data 1480 contains the 16 byte MD5 digest of the entire SCSP packet, including 1481 the encapsulated protocol's header, with the authentication key 1482 appended to the end of the packet. The authentication key is not 1483 transmitted with the packet. The MD5 digest covers only the fixed 1484 part and mandatory part. 1486 B.3.2 SCSP Vendor-Private Extension 1488 Type = 2 1489 Length = variable 1491 The SCSP Vendor-Private Extension is carried in SCSP packets to 1492 convey vendor-private information between an LS and a DCS in the same 1493 SG and is thus of limited use. If a finer granularity (e.g., CSA 1494 record level) is desired then then given client/server protocol 1495 specific SCSP document MUST define such a mechanism. Obviously, 1496 however, such a protocol specific mechanism might look exactly like 1497 this extension. The Vendor Private Extension MAY NOT appear more 1498 than once in an SCSP packet for a given Vendor ID value. 1500 0 1 2 3 1501 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 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Vendor ID | Data.... | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 Vendor ID 1507 802 Vendor ID as assigned by the IEEE [10]. 1509 Data 1510 The remaining octets after the Vendor ID in the payload are 1511 vendor-dependent data. 1513 If the receiver does not handle this extension, or does not match the 1514 Vendor ID in the extension then the extension may be completely 1515 ignored by the receiver. 1517 References 1519 [1] "Classical IP and ARP over ATM", Laubach, RFC 1577. 1521 [2] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello, 1522 Cole, draft-ietf-rolc-nhrp-11.txt. 1524 [3] "OSPF Version 2", Moy, RFC1583. 1526 [4] "P-NNI V1", Dykeman, Goguen, 1996. 1528 [5] "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", 1529 Armitage, RFC2022. 1531 [6] LAN Emulation over ATM Version 2 - LNNI specification, Keene, 1532 btd-lane-lnni-02.08. 1534 [7] Assigned Numbers, Reynolds, Postel, RFC 1700. 1536 [8] "A Distributed NHRP Service Using SCSP", Luciani, 1537 draft-ietf-ion-scsp-nhrp-00.txt. 1539 [9] "A Distributed ATMARP Service Using SCSP", Luciani, 1540 draft-ietf-ion-scsp-atmarp-00.txt. 1542 [10] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 1544 Acknowledgments 1546 This I-D is a distillation of issues raised during private 1547 discussions, on the IP-ATM mailing list, and during the Dallas IETF 1548 (12/95). Thanks to all who have contributed but particular thanks to 1549 following people (in no particular order): Barbara Fox of Harris and 1550 Jeffries; Raj Nair, and Matthew Doar of Ascom Nexion; Andy Malis of 1551 Cascade; Andre Fredette of Bay Networks; James Watt of Newbridge; and 1552 Carl Marcinik of Fore. 1554 Author's Address 1556 James V. Luciani 1557 Bay Networks, Inc. 1558 3 Federal Street, BL3-04 1559 Billerica, MA 01821 1560 phone: +1-508-916-4734 1561 email: luciani@baynetworks.com 1563 Grenville Armitage 1564 Bellcore, 445 South Street 1565 Morristown, NJ, 07960 1566 Email: gja@thumper.bellcore.com 1567 Ph. +1 201 829 2635 1569 Joel M. Halpern 1570 Newbridge Networks Corp. 1571 593 Herndon Parkway 1572 Herndon, VA 22070-5241 1573 Phone: +1-703-708-5954 1574 Email: jhalpern@Newbridge.COM