idnits 2.17.1 draft-armitage-ion-distmars-spec-00.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-25) 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 581: '...ub-cache update CSA Record types SHALL...' RFC 2119 keyword, line 583: '... (CSUS) messages SHALL only trigger th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 244 has weird spacing: '... 8 bits unus...' == Line 258 has weird spacing: '... 8 bits unus...' == Line 300 has weird spacing: '... 8 bits unus...' == Line 313 has weird spacing: '... 8 bits unus...' == Line 396 has weird spacing: '... 8 bits unus...' == (2 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TBD' on line 123 == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-00 == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-10 == Outdated reference: A later version (-06) exists of draft-armitage-ion-mars-scsp-02 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Grenville Armitage 2 Bellcore 3 January 22nd, 1997 5 A Distributed MARS Protocol 6 8 Status of this Memo 10 This document was submitted to the IETF Internetworking over NBMA 11 (ION) WG. Publication of this document does not imply acceptance by 12 the ION WG of any ideas expressed within. Comments should be 13 submitted to the ion@nexen.com mailing list. 15 Distribution of this memo is unlimited. 17 This memo is an internet draft. Internet Drafts are working documents 18 of the Internet Engineering Task Force (IETF), its Areas, and its 19 Working Groups. Note that other groups may also distribute working 20 documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 Please check the lid-abstracts.txt listing contained in the 29 internet-drafts shadow directories on ds.internic.net (US East 30 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 31 munnari.oz.au (Pacific Rim) to learn the current status of any 32 Internet Draft. 34 Abstract 36 The Server Cache Synchronisation Protocol (SCSP) has been proposed as 37 a general mechanism for synchronising the databases of IP/ATM 38 Servers, such as those used by NHRP and MARS. This document specifies 39 an application of SCSP to allow multiple MARS entities to provide 40 fault tolerance to MARS Clusters. 42 1. Introduction. 44 [Editors note: this probably has holes you could drive a bus through. 45 if you drive buses and have an interest in this topic, offers of co- 46 authorship will be well received.] 47 SCSP [1] being developed within the Internetworking over NBMA (ION) 48 working group as a general solution for synchronizing distributed 49 databases such as distributed Next Hop Servers [2] and MARSs [3]. 50 Analysis of the possible distributed MARS scenarios is available in 51 the form of an Internet Draft submitted to the ION working group [4]. 52 It is assumed that the reader understands the issues raised in [4] 53 regarding the Fault Tolerant model, and understands the services 54 provided by SCSP as described in [1]. {Whether the author does is 55 another matter entirely!} 57 In the current MARS model a Cluster consists of a number of MARS 58 Clients (IP/ATM interfaces in routers and/or hosts) utilizing the 59 services of a single MARS. This MARS is responsible for tracking the 60 IP group membership information across all Cluster members, and 61 providing on-demand associations between IP multicast group 62 identifiers (addresses) and specific sets of one or more ATM endpoint 63 addresses (for building ATM level multipoint forwarding paths). This 64 MARS is also responsible for allocating Cluster Member IDs (CMIs) to 65 Cluster members (inserted into outgoing data packets, to allow 66 reflected packet detection when Multicast Servers are placed in the 67 data path). 69 In [4] two different methods of using multiple MARS entities in a 70 single cluster are defined - the Fault Tolerant model and the Load 71 Sharing model. This document specifies the use of SCSP to provide the 72 Fault Tolerant model. [Actually, at this point it doesn't really do 73 either.] This model contains the following elements: 75 Active MARS 76 The single MARS serving the Cluster. It allocates 77 CMIs and tracks group membership changes by itself. 78 It is the sole entity that constructs replies to 79 MARS_REQUESTs. 81 Backup MARS 82 An additional MARS that tracks the information being 83 generated by the Active MARS. Cluster members may 84 re-register with a Backup MARS if the Active MARS 85 fails, and they'll assume the Backup has sufficient 86 up to date knowledge of the Cluster's state to take 87 the role of Active MARS. 89 Living Group 90 The set of Active MARS and current Backup MARS 91 entities. When a MARS entity dies it falls out of 92 the Living Group. When it restarts, it rejoins the 93 Living Group. Election of the Active MARS takes 94 place amongst the members of the Living Group. 96 MARS Group 97 The total set of MARS entities configured to be part 98 of the distributed MARS. This is the combination of 99 the Living Group and 'dead' MARS entities that may 100 be currently dying, dead, or restarting. The list is 101 constructed in the following order {Active MARS, 102 Backup MARS, ... Backup MARS, dead MARS,.... dead 103 MARS}. If there are no 'dead' MARS entities, the 104 MARS Group and Living Group are identical. 106 SCSP assumes that the state held by a given server is contained in a 107 local object known as a cache. Keeping this cached state synchronized 108 among each server in a Server Group (SG) is what SCSP does, with the 109 use of alignment and update messages. Client State Update (CSU) 110 messages contain actual cache update data within individual Client 111 State Advertisement (CSA) records. These may be transmitted by a 112 server when a local cache state change occurs, or when solicited by a 113 neighboring server using a Client State Update Solicitation (CSUS) 114 message. 116 SCSP also defines an alignment phase where members of a Server Group 117 discover if their caches are out of alignment be comparing Client 118 State Advertisement Summary (CSAS) records. CSAS records are carried 119 in Client Alignment (CA) messages between neighboring servers. 121 The rest of this document is structured as follows: 123 [TBD] 125 2. MARS Sub-caches 127 For the purpose of applying SCSP to the distributed MARS scenario, we 128 subdivide the SCSP "cache" into a number of sub-caches, each of which 129 are kept independently synchronized. Any given server in an SG builds 130 up its notion of a distributed sub-cache's contents from the sum of 131 sub-cache information flooded by other servers in the SG. 133 Each MARS sub-cache has a separate sequence number space, allowing 134 sub-caches to be updated/flooded independently. 136 The sub-caches are derived from the following components of the 137 overall MARS state for a given Cluster: 139 Cluster membership list. 141 Cluster Member IDs. 143 MCS (Multicast Server) membership list. 145 Absolute maximum and minimum group addresses for protocol being 146 supported. 148 Member map (hostmap) for each Layer 3 group. 150 MCS (Multicast Server) Servermap for each Layer 3 group. 152 Block-join map. 154 Redirect_map. 156 The Cluster membership list is the most fundamental object for a 157 MARS. It contains the ATM addresses of every cluster member, and 158 explicitly maps Cluster Member ATM addresses to Cluster Member IDs. 159 Both of these pieces of information will be combined into a single 160 CMI map sub-cache. 162 The MCS membership list is essential to enable construction of a 163 backup ServerControlVC by any one of the backup MARSs. 165 Each multicast group is represented by a membership map (hostmap) 166 sub-cache. Since a given multicast group may also have MCSs 167 registered to support it there is also a matching Servermap. Hostmaps 168 and Servermaps are treated as separate sub-caches. To simplify and 169 shorten the CSA Records, members of these maps are identified by 170 their Cluster Member IDs rather than enumerating their actual ATM 171 addresses. The key into a hostmap or servermap is the group's 172 multicast address. 174 Since hostmaps for a given group may be quite large, and most 175 MARS_JOIN/LEAVE events simply result in an incremental change to the 176 host map, two different types of CSA record will be defined. One will 177 represent the sub-cache in its entirety (for use when aligning 178 servers), and the second will have semantics to match the JOIN/LEAVE 179 event (allowing an incremental addition to, or deletion from, the 180 sub-cache associated with the specific multicast group). The same 181 will apply to the CSA records for Servermaps. SCSP has a mechanism 182 for segmenting large CSA Records across multiple CSU messages. 184 The block-join map represents all currently valid block MARS_JOINs 185 registered with the MARS. This allows the preceding, group-specific 186 hostmaps to be simplified. (The CSA Records representing the hostmap 187 for a given group only lists nodes that have issued a specific 188 single-group MARS_JOIN for that group.) Internally, the MARS builds 189 whatever database structure is required to ensure that replies to 190 MARS_REQUESTs, and general hole-punching activities, take the block- 191 join map's contents into account. 193 The Redirect_map is the list of MARS entities a given server is 194 currently sending in its MARS_REDIRECT_MAP messages. The MARS Clients 195 consider this list to be the available Backup MARS entities. Its use 196 is TBD. 198 3. Client State Advertisement Summary (CSAS) records. 200 Client State Advertisement Summary (CSAS) records are carried within 201 SCSP Cache Alignment (CA) messages. They are used to inform one 202 server of another server's {sub}cache state without sending the 203 contents of the cache itself. 205 CSAS records have an 4 byte fixed header defined by SCSP, followed by 206 protocol specific fields (the Server Group ID - SGID - is contained 207 in the header of the CA messages that carry CSAS records). 209 For MARS use we add a 16 bit CSAS record (sub-cache) type field. The 210 first 6 bytes of each CSAS record are thus: 212 csas$sequence 32 bits CSA Sequence Number. 213 csas$type 16 bits CSAS record sub-cache type. 215 The CSA Sequence number indicates how recently the specified sub- 216 cache (csas$type) has been modified. This is used to determine 217 whether a re-alignment is required. Each CSAS also contains an 218 Originator ID field, which identfies which server in the SG is the 219 "owner" (originator) of the sub-cache information to which the CSAS 220 refers. For a MARS server group, the Orignator ID is the NBMA address 221 of the originating MARS. 223 The remaining bytes of the CSAS record are determined by csas$type. 225 The MARS CSAS record types are: 227 CSAS_CMI_MAP 1 228 CSAS_MCS_LIST 2 229 CSAS_HOST_MAP 3 230 CSAS_MCS_MAP 4 231 CSAS_BLOCK_JOINS 5 232 CSAS_REDIRECT_MAP 6 234 The specific formats of each CSAS record are described in the 235 following sub-sections. 237 3.1 CSAS_CMI_MAP. 239 The complete CSAS Record looks like: 241 csas$sequence 32 bits CSA Sequence Number. 242 csas$type 16 bits Set to 1 (CSAS_CMI_MAP) 243 csas$orig_len 8 bits Length of csas$origin field. 244 csas$unused 8 bits unused. 245 csas$origin x octets Originator ID. 247 For this CSAS, the sequence number is incremented every time a new 248 cluster member registers, or an old one is considered to have died or 249 deregistered. 251 3.2 CSAS_MCS_LIST. 253 The complete CSAS Record looks like: 255 csas$sequence 32 bits CSA Sequence Number. 256 csas$type 16 bits Set to 2 (CSAS_MCS_LIST) 257 csas$orig_len 8 bits Length of csas$origin field. 258 csas$unused 8 bits unused. 259 csas$origin x octets Originator ID. 261 For this CSAS, the sequence number is incremented every time a new 262 MCS registers, or an old one is considered to have died or 263 deregistered. 265 3.3 CSAS_HOST_MAP. 267 The complete CSAS Record looks like: 269 csas$sequence 32 bits CSA Sequence Number. 270 csas$type 16 bits Set to 3 (CSAS_HOST_MAP) 271 csas$orig_len 8 bits Length of csas$origin field. 272 csas$group_len 8 bits Length of group address. 273 csas$origin x octets Originator ID. 274 csas$group y octets Hostmap entry's group address. 276 For this CSAS, the sequence number is incremented whenever a cluster 277 member joins or leaves the group specified by csas$group. 279 3.4 CSAS_MCS_MAP. 281 The complete CSAS Record looks like: 283 csas$sequence 32 bits CSA Sequence Number. 284 csas$type 16 bits Set to 4 (CSAS_MCS_MAP) 285 csas$orig_len 8 bits Length of csas$origin field. 286 csas$group_len 8 bits Length of group address. 287 csas$origin x octets Originator ID. 288 csas$group y octets Servermap entry's group address. 290 For this CSAS, the sequence number is incremented whenever an MCS 291 joins or leaves the group specified by csas$group. 293 3.5 CSAS_BLOCK_JOINS. 295 The complete CSAS Record looks like: 297 csas$sequence 32 bits CSA Sequence Number. 298 csas$type 16 bits Set to 5 (CSAS_BLOCK_JOINS) 299 csas$orig_len 8 bits Length of csas$origin field. 300 csas$unused 8 bits unused. 301 csas$origin x octets Originator ID. 303 For this CSAS, the sequence number is incremented whenever a block 304 MARS_JOIN, or matching block MARS_LEAVE, occurs. 306 3.6 CSAS_REDIRECT_MAP. 308 The complete CSAS Record looks like: 310 csas$sequence 32 bits CSA Sequence Number. 311 csas$type 16 bits Set to 6 (CSAS_REDIRECT_MAP) 312 csas$orig_len 8 bits Length of csas$origin field. 313 csas$unused 8 bits unused. 314 csas$origin x octets Originator ID. 316 For this CSAS, the sequence number is incremented whenever the local 317 server modifies the list of MARS entities in its MARS_REDIRECT_MAP 318 list. 320 4. Client State Advertisement (CSA) Records. 322 CSA records have an 12 byte fixed header defined by SCSP, followed by 323 protocol specific fields. For MARS use we add a 16 bit CSA record 324 (sub-cache) type field. The first 14 bytes of each CSAS record are 325 thus: 327 csa$fragment 16 bits F/Fragment Number. 328 csa$ttl 16 bits TTL. 329 csa$sequence 32 bits CSA Sequence Number. 330 csa$sgid 32 bits Server Group ID. 331 csa$type 16 bits CSA Record sub-cache type. 333 The CSA Sequence number indicates how recently the specified sub- 334 cache (csa$type) has been modified. This is used to determine whether 335 a re-alignment is required. The Server Group ID identifies an 336 instance of a Server Group. Since Server Groups will exist on a per- 337 protocol basis (IPv4, IPv6, etc) the csa$sgid field implicitly 338 identifies the formats of any 'group' address fields within the CSA 339 Records. 341 Each CSA also contains an Originator ID field, which identfies which 342 server in the SG is the "owner" (originator) of the sub-cache 343 information to which the CSA refers. In the case of MARS server 344 groups, the originator is identified by its ATM address (cf. the NHRP 345 case where the 'protocol address' is used). The format of the ATM 346 address is irrelevant - the originator field is simply an 347 uninterpreted octet string used for pattern matching. 349 The remaining bytes of the CSA record are determined by csa$type. 351 To match the CSAS records, the following set of CSA record types are 352 defined: 354 CSA_CMI_MAP 1 355 CSA_MCS_LIST 2 356 CSA_HOST_MAP 3 357 CSA_MCS_MAP 4 358 CSA_BLOCK_JOINS 5 359 CSA_REDIRECT_MAP 6 361 In addition, to allow indication of incremental updates to some of 362 the sub-caches, matching 364 CSA_CMI_MAP_JOIN 128 365 CSA_CMI_MAP_LEAVE 129 366 CSA_MCS_LIST_JOIN 130 367 CSA_MCS_LIST_LEAVE 131 368 CSA_HOST_MAP_JOIN 132 369 CSA_HOST_MAP_LEAVE 133 370 CSA_MCS_MAP_JOIN 134 371 CSA_MCS_MAP_LEAVE 135 373 (csa$type values in the range 1 to 127 correspond to entire sub- 374 caches, whilst the range 128 to 512 are allocated to incremental 375 sub-cache updates.) 377 The amount of information carried by a specific CSA_HOST_MAP or 378 CSA_CMI_MAP may exceed the size of a link layer PDU. SCSP allows a 379 large CSA Record to be fragmented across a number of CSU Request 380 messages. 382 4.1 CSA_CMI_MAP. 384 This CSA Record carries the entire membership of the current cluster, 385 along with the Cluster Member IDs (CMIs) assigned by the MARS they 386 registered with. These CMIs are then used as a short-form 387 representation of the actual cluster members to compress the size of 388 subsequent CSA_HOST_MAP messages. 390 csa$fragment 16 bits F/Fragment Number. 391 csa$ttl 16 bits TTL 392 csa$sequence 32 bits CSA Sequence Number. 393 csa$sgid 32 bits Server Group ID. 394 csa$type 16 bits Set to 1 (CSA_CMI_MAP). 395 csa$orig_len 8 bits Length of csa$origin. 396 csa$unused 8 bits unused. 397 csa$cnum 16 bits Number of entries in this CSA (N). 398 csa$thtl 8 bits Type and length of ATM addresses. 399 csa$tstl 8 bits Type and length of ATM sub-addresses. 400 csa$origin x octets Originator's NBMA address. 401 csa$atmaddr.1 q octets ATM address of member 1. 402 csa$subaddr.1 r octets ATM sub-address of member 1. 403 csa$cmi.1 16 bits Cluster Member ID for entry 1. 404 [..etc..] 405 csa$atmaddr.N q octets ATM address of member N. 406 csa$subaddr.N r octets ATM sub-address of member N. 407 csa$cmi.N 16 bits Cluster Member ID for entry N. 409 4.2 CSA_MCS_LIST. 411 This CSA Record carries the entire list of currently registered 412 Multicast Servers (MCSs). Each MCS is also assigned an internal ID by 413 the MARS they registered with - this is used to compress the size of 414 subsequent CSA_MCS_MAP messages. 416 csa$fragment 16 bits F/Fragment Number. 417 csa$ttl 16 bits TTL 418 csa$sequence 32 bits CSA Sequence Number. 419 csa$sgid 32 bits Server Group ID. 420 csa$type 16 bits Set to 2 (CSA_MCS_LIST). 421 csa$orig_len 8 bits Length of csa$origin. 422 csa$unused 8 bits unused. 423 csa$cnum 16 bits Number of entries in this CSA (N). 424 csa$thtl 8 bits Type and length of ATM addresses. 425 csa$tstl 8 bits Type and length of ATM sub-addresses. 426 csa$origin x octets Originator's NBMA address. 427 csa$atmaddr.1 q octets ATM address of MCS 1. 428 csa$subaddr.1 r octets ATM sub-address of MCS 1. 430 csa$cmi.1 16 bits Internal MCS ID for entry 1. 431 [..etc..] 432 csa$atmaddr.N q octets ATM address of member N. 433 csa$subaddr.N r octets ATM sub-address of member N. 434 csa$cmi.N 16 bits Internal MCS ID for entry N. 436 4.3 CSA_HOST_MAP 438 This CSA Record carries the list of cluster members who have joined a 439 specified group using a single-group MARS_JOIN operation. The Cluster 440 Member IDs are used to represent each group member with each CSA 441 Record fragment. A recipient MARS uses this CSA in conjunction with 442 the current Cluster membership list to derive the actual ATM 443 addresses of group members. 445 csa$fragment 16 bits F/Fragment Number. 446 csa$ttl 16 bits TTL 447 csa$sequence 32 bits CSA Sequence Number. 448 csa$sgid 32 bits Server Group ID. 449 csa$type 16 bits Set to 3 (CSA_HOST_MAP). 450 csa$orig_len 8 bits Length of csa$origin. 451 csa$group_len 8 bits Length of csa$group. 452 csa$cnum 16 bits Number of entries in this fragment (N). 453 csa$origin x octets Originator's NBMA address. 454 csa$group y octets Multicast group's protocol address. 455 csa$cmi.1 16 bits Cluster Member ID for entry 1. 456 csa$cmi.2 16 bits Cluster Member ID for entry 2. 457 [..etc..] 458 csa$cmi.N 16 bits Cluster Member ID for entry N. 460 4.4 CSA_MCS_MAP 462 This CSA Record carries the list of MCSs who have joined to support a 463 specified group. The internal MCS IDs from prior CSA_MCS_LIST CSA 464 Records are used to represent each MCS. A recipient MARS uses this 465 CSA in conjunction with the current MCS membership list to derive the 466 actual ATM addresses of group members. 468 csa$fragment 16 bits F/Fragment Number. 469 csa$ttl 16 bits TTL 470 csa$sequence 32 bits CSA Sequence Number. 471 csa$sgid 32 bits Server Group ID. 472 csa$type 16 bits Set to 4 (CSA_MCS_MAP). 473 csa$orig_len 8 bits Length of csa$origin. 474 csa$group_len 8 bits Length of csa$group. 476 csa$cnum 16 bits Number of entries in this fragment (N). 477 csa$origin x octets Originator's NBMA address. 478 csa$group y octets Multicast group's protocol address. 479 csa$cmi.1 16 bits Internal MCS ID for entry 1. 480 csa$cmi.2 16 bits Internal MCS ID for entry 2. 481 [..etc..] 482 csa$cmi.N 16 bits Internal MCS ID for entry N. 484 4.5 CSA_BLOCK_JOINS 486 This CSA Record carries the list of Cluster Members who have joined 487 blocks of the layer 3 group address space. The Cluster Member IDs 488 from prior CSA_CMI_MAP CSA Records are used to represent each cluster 489 member and associate it with a specific pair. 491 csa$fragment 16 bits F/Fragment Number. 492 csa$ttl 16 bits TTL 493 csa$sequence 32 bits CSA Sequence Number. 494 csa$sgid 32 bits Server Group ID. 495 csa$type 16 bits Set to 5 (CSA_BLOCK_JOINS). 496 csa$orig_len 8 bits Length of csa$origin. 497 csa$group_len 8 bits Lengths of csa$min and csa$max fields. 498 csa$cnum 16 bits Number of entries in this fragment (N). 499 csa$origin x octets Originator's NBMA address. 500 csa$min.1 y octets group address of block 1. 501 csa$max.1 y octets group address of block 1. 502 csa$cmi.1 16 bits Cluster Member ID for block 1. 503 [..etc..] 504 csa$min.N y octets group address of block N. 505 csa$max.N y octets group address of block N. 506 csa$cmi.N 16 bits Cluster Member ID for block N. 508 4.6 CSA_REDIRECT_MAP 510 This CSA Record carries the list the source server is using to 511 generate MARS_REDIRECT_MAP messages. 513 csa$fragment 16 bits F/Fragment Number. 514 csa$ttl 16 bits TTL 515 csa$sequence 32 bits CSA Sequence Number. 516 csa$sgid 32 bits Server Group ID. 517 csa$type 16 bits Set to 6 (CSA_REDIRECT_MAP). 518 csa$orig_len 8 bits Length of csa$origin. 519 csa$unused 8 bits unused. 520 csa$cnum 16 bits Number of entries in this fragment (N). 522 csa$thtl 8 bits Type and length of ATM addresses. 523 csa$tstl 8 bits Type and length of ATM sub-addresses. 524 csa$origin x octets Originator's NBMA address. 525 csa$atmaddr.1 q octets ATM address of member 1. 526 csa$subaddr.1 r octets ATM sub-address of member 1. 527 [..etc..] 528 csa$atmaddr.N q octets ATM address of member N. 529 csa$subaddr.N r octets ATM sub-address of member N. 531 4.7 Incremental update CSA Records. 533 The incremental update CSA Records types use the same format as 534 alignment CSA Records, except that only a single entry (of whatever 535 information) is passed. 537 Two examples: 539 CSA_CMI_MAP_LEAVE is coded as a CSA_CMI_MAP but with csa$type = 540 129, csa$cnum = 1, and only a single ATM address and CMI pair 541 provided. 543 CSA_HOST_MAP_JOIN is coded as a CSA_HOST_MAP but with csa$type = 544 132, csa$cnum = 1, and only a single CMI is provided (indicating 545 the specific host that has now become a group member). 547 The CSA Sequence number space for incremental update CSAs is the same 548 space used by alignment CSAs for the identfied sub-cache. 550 Alignment updates (containing a full version of an identified sub- 551 cache) are always accepted by a server. 553 Incremental update CSAs are are accepted as updates to the local 554 server's copy of the specified sub-cache, from the specified 555 Originator ID, only if they arrive with a larger (newer) CSA Sequence 556 number than the existing local entry. 558 Incremental update CSAs are discarded if they arrive with a smaller 559 (older) CSA Sequence number than the local server already has for the 560 specified sub-cache, from the specified Originator ID. 562 [The rest of this explanation is TBD.] 564 5. Use of CSA Records. 566 The most important sub-caches for a MARS to exchange are the 567 CSA_CMI_MAP and CSA_MCS_LIST. Without alignment of these sub-caches, 568 members of the Server Group cannot interpret the other CSA Record 569 types, which identify nodes using ID values supplied in the 570 CSA_CMI_MAP and CSA_MCS_LIST records. 572 MARS_JOIN/LEAVE events are propagated by issuing CSA_HOST_MAP_JOIN 573 and CSA_HOST_MAP_LEAVE CSA Records in CSU messages. 575 There are no CSAS Record types equivalent to the incremental sub- 576 cache update CSA Record types. The semantics of the CSAS Record in 577 the CA message is to indicate the state of an entire sub-cache. It 578 would make no sense to try and discover (or convey) an 'incremental 579 state' of a sub-cache. 581 As a consequence, incremental sub-cache update CSA Record types SHALL 582 only be sent in un-solicited CSU Request messages. Client State 583 Update Solicit (CSUS) messages SHALL only trigger the delivery of CSA 584 Records containing entire sub-caches as atomic units. 586 Security Consideration 588 Security consideration are not addressed in this document. 590 Acknowledgments 592 To Liptons, for making the tea that keeps me going. 594 Author's Address 596 Grenville Armitage 597 Bellcore, 445 South Street 598 Morristown, NJ, 07960 599 USA 601 Email: gja@bellcore.com 602 Ph. +1 201 829 2635 604 References 605 [1] J. Luciani, G. Armitage, J. Halpern, "Server Cache 606 Synchronization Protocol (SCSP) - NBMA", INTERNET DRAFT, draft-ietf- 607 ion-scsp-00.txt, November 1996. 609 [2] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", 610 INTERNET DRAFT, draft-ietf-rolc-nhrp-10.txt, October 1996. 612 [3] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM 613 Networks.", Bellcore, RFC 2022, November 1996. 615 [4] G. Armitage, "Redundant MARS architectures and SCSP.", INTERNET 616 DRAFT, draft-armitage-ion-mars-scsp-02.txt, November 1996.