idnits 2.17.1 draft-ietf-ion-scsp-mars-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-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 841 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 57: '...MARS Model there MAY be multiple MARS ...' RFC 2119 keyword, line 58: '... Server within the LIS MUST be able to...' RFC 2119 keyword, line 60: '...n the LIS, there MUST be a method by w...' RFC 2119 keyword, line 69: '...s, and thus SCSP MAY be applied to the...' RFC 2119 keyword, line 120: '... MUST flush the client/group members...' (39 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1998) is 9445 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-01 ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1577 (ref. '4') (Obsoleted by RFC 2225) == Outdated reference: A later version (-06) exists of draft-armitage-ion-mars-scsp-03 -- Possible downref: Normative reference to a draft: ref. '5' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internetworking Over NBMA James V. Luciani 2 INTERNET-DRAFT (Bay Networks) 3 Anthony M. Gallo 4 (IBM) 5 Expires June 1998 7 A Distributed MARS Service Using SCSP 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Abstract 29 This document describes a method for distributing a MARS service 30 within a LIS[1]. This method uses the Server Cache Synchronization 31 Protocol (SCSP)[2] to synchronize the MARS Server databases within a 32 LIS. When SCSP is used to synchronize the caches of MARS Servers in 33 a LIS, the LIS defines the boundary of an SCSP Server Group (SG). 35 1. Introduction 37 The MARS is an extended analog of the ATMARP Server introduced in 38 [4]. It provides the necessary connection and addressing services 39 required by layer 3 multicast services over ATM. There are three 40 basic elements to the MARS model. First, the MARS Server which 41 manages and distributes layer 3 group membership information to the 42 LIS. Second, MARS Clients which register with and query a single MARS 43 Server for layer 3 multicast information. Third, MCS Clients which 44 register with a single MARS Server and provide layer 3 multicast 45 forwarding services for a LIS. 47 Both MARS Clients and MCS Clients explicitly register with the MARS 48 Server before exchanging layer 3 multicast information. During the 49 registration process MARS Clients are place on the Cluster Control VC 50 (CCVC) and MCS Clients are placed on the Server Control VC (SCVC). 51 Both the CCVC and SCVC are then used to propagate layer 3 multicast 52 updates to the clients which make up a LIS. During the registration 53 process MARS Clients are also assigned a unique Cluster Member ID 54 (CMI) which is used to identify reflected packets in the presence of 55 MCS Clients. 57 In the Distributed MARS Model there MAY be multiple MARS Servers in a 58 given LIS, and since any MARS Server within the LIS MUST be able to 59 provide layer 3 multicast information about any multicast group 60 within the LIS, there MUST be a method by which to synchronize 61 multicast information across all MARS Servers within the LIS. In [5] 62 several distributed MARS models are discussed along with various 63 trade offs of each. The document provides a description of the 64 problems that need to be addressed from the MARS protocol's point of 65 view in a distributed system. 67 The Server Cache Synchronization Protocol (SCSP) solves the 68 generalized server synchronization/cache-replication problem for 69 distributed databases, and thus SCSP MAY be applied to the MARS 70 Server database synchronization problem within a LIS. When SCSP is 71 used to synchronize the caches of MARS Servers in a LIS, the LIS 72 defines the boundary of and SCSP Server Group (SG). 74 SCSP is defined in two parts: the protocol independent part and the 75 client/server protocol specific part. The protocol independent part 76 is specified in [2] whereas this document will specify the 77 client/server protocol specific part where the MARS Server is the 78 client/server protocol. 80 2. Overview 82 All MARS Servers belonging to a LIS are said to belong to a Server 83 Group (SG). A SG is identified by, not surprisingly, its SGID which 84 is contained in a field in all SCSP packets. All SCSP packets contain 85 a Protocol ID (PID) field as well. This PID field is set to 0x0003 to 86 signify that SCSP is synchronizing MARS Server databases as opposed 87 to synchronizing some other protocol's databases. (see Section 88 B.2.0.1 of [2] for more details). In general, PIDs for SCSP will be 89 assigned by IANA upon request given that a client/server protocol 90 specific specification has been written. In the case of MARS Servers, 91 the client/server protocol specific specification was written at the 92 same time time as SCSP, and thus a PID=0x0003 was assigned in [2]. 94 SCSP places no topological requirements upon a MARS Server SG. 95 Obviously, however, the resultant graph of MARS Servers must span the 96 set of MARS Servers being synchronized. For more information about 97 the client/server protocol independent part of SCSP, the reader is 98 encouraged to see [2]. 100 When a SG is using SCSP for synchronization, a MARS Client or MCS 101 Client will register with only one MARS Server although it is allowed 102 to choose any MARS Server in the SG for this registration. At 103 registration time the MARS Client or MCS Client will be added to that 104 MARS Servers respective CCVC or SCVC. Also, MARS Clients will be 105 issued a unique CMI for the entire LIS. This document assumes at a 106 minimum each MARS Server in the SG will be configured with a unique 107 range of CMIs to assign to clients registering with that MARS Server. 108 Use of some external means for allocating CMIs to MARS Servers in a 109 SG is possible but beyond the scope of this document. 111 When a MARS Client or MCS Client successfully registers with a MARS 112 Server in the SG that MARS Server will propagate the registration 113 information to its peer MARS Servers. The same propagation will occur 114 for any subsequent group membership information learned from the 115 clients. The peer MARS Server will then update its group membership 116 database and propagate the information out its own CCVC or SCVC if 117 needed. 119 In the case of a MARS Server failure all peer MARS Servers in the SG 120 MUST flush the client/group membership information learned from the 121 failed MARS Server. The clients belonging to the failed MARS Servers 122 CCVC and SCVC will migrate to the next available MARS Server as 123 specified in Section 5.3 of [1]. When a client detects a failure of 124 its MARS, it steps to the next backup MARS Server and attempts to 125 register with the server. If the registration is successful the 126 client will re-join all of its previous group membership information. 127 If the registration fails, the process repeats until a functional 128 MARS Server is found. 130 Determining the operational state of a MARS Servers in a SG requires 131 that each MARS Server send out an "alive" or "heartbeat" message 132 similar to the MARS Redirect message sent out on the CCVC or SCVC for 133 MARS Clients. However, this message will only be sent to MARS Servers 134 in the SG and is from here on defined as the MARS Server Redirect 135 Entry. 137 In order to detect that a MARS Server failure has occurred each 138 server MUST update it's MARS Server Redirect Entry state at least 139 every 2 minutes, it is RECOMMENDED that it is updated every 1 minute. 140 Failure to receive two consecutive MARS Server Redirect Entry updates 141 from a given MARS Server in the SG will cause all membership 142 information learned from this server to be flushed. The MARS Server 143 Redirect Entry state is also used to create the MARS_REDIRECT_MAP 144 messages sent out on CCVC for each MARS Server in the SG. The 145 ordering of each server learned will be based on the MARS Servers 146 SCSP Sender ID. The ordering of the MARS_REDIRECT_MAP will first 147 contain the list of MARS Servers learned via MARS Server Redirect 148 Entry updates in ascending order based on the SCSP Sender ID, 149 followed by any externally configured or learned backup MARS Servers. 151 In the case of a MARS Client or MCS Client failure where the client 152 is unexpectedly removed from the CCVC or SCVC the MARS Server MUST 153 notify its peer SG members via a proxy deregister for that client. 154 Upon receiving a proxy deregister request from a peer SG member all 155 membership information for the deregistering client MUST be removed. 156 Any Clients sending multicast data to the failed client should also 157 receive an unexpected removal of this client which will intern cause 158 the sending client to revalidate the multicast groups current 159 membership as outlined in Section 5.1.5.1 of [1]. 161 3. Format of the CSA Record MARS Specific Part 163 CSA Records in SCSP contain a "Client/Server Protocol Specific Part" 164 which contains the non-protocol independent information for a given 165 server's cache entry. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Hardware Type | Protocol Type | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | SNAP | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | SNAP | Unused | Version | State | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Flags | Cluster Member ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L| 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Source Protocol Address (variable length) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Source ATM Address (variable length) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Source ATM SubAddress (variable length) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Minimum Multicast Group Address (variable length) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Maximum Multicast Group Address (variable length) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Hardware Type 192 Defines the type of "link layer" addresses being carried. This 193 value is the ATM Forum 'address family number' specified in [3] as 194 15 decimal (0x000F). This is the mar$afn field defined in [1]. 196 Protocol Type 197 This field is the protocol type number for the protocol using MARS 198 from [3]. (IPv4 is 0x0800). This is the mar$pro.type field from 199 [1]. 201 Protocol SNAP 202 This field is the optional protocol SNAP extension to protocol 203 type. This is the mar$pro.snap field from [1]. 205 Version Number 206 0 MARS Specific part of the CSA record. 207 0x01 Reserved for NHRP. 208 0x02 - 0xEF Reserved for future use by the IETF. 209 0xF0 - 0xFE Allocated for use by the ATM Forum. 210 0xFF Experimental/Local use. 211 Version Number for this document MUST be set to 0x00. 213 State 214 1 MARS Server Redirect Entry. 215 2 MCS Serve/Register request. 216 3 MARS Client Join/Register request. 217 4 MARS Client Leave/Deregister request. 218 5 MCS Unserve/Deregister request. 220 All other State values should cause the CSA to be discarded. 222 Flags 223 The flags field is used to contain several flags and is similar to 224 the mar$flags field from [1]. 225 mar$flags 226 Bit 15 - mar$flags.layer3grp 227 Bit 13 - mar$flags.register 228 Bit 0-7 - mar$flags.sequence 230 All remaining bits are reserved and MUST be zero. The 231 mars$flags.sequence field is of local significance only to the 232 Local Server (LS). 234 Cluster Member CMI 235 This field contains the CMI which uniquely identifies each endpoint 236 within a LIS. This is the mar$cmi field from [1]. 238 Src Addr Len 239 This field contains the length of the Source Protocol Address 240 field. For IPv4, the value is 4 if an address is specified. A null 241 (non-existent) address MUST be coded as zero length, and no space 242 allocated for it in the message body. This is the mar$spln field 243 from [1]. 245 Group Addr Len 246 This field contains the length of the Group Protocol Address field. 247 For IPv4, the value is 4 if an address is specified. A null (non- 248 existent) address MUST be coded as zero length, and no space 249 allocated for it in the message body. This is the mar$tpln field 250 from [1]. 252 ATM Addr T/L 253 This field contains the type and length of the Source ATM Address 254 field. The type and length encoding is described in Section 5.1.2 255 of [1]. 257 ATM SubAddr T/L 258 This field contains the type and length of the Source ATM 259 SubAddress field. The type and length encoding is described in 260 Section 5.1.2 of [1]. 262 Source Protocol Address 263 This is the internetwork address for the source of an address 264 binding in a MARS server cache entry. If null, no storage will be 265 allocated. This is the mar$spa field from [1]. 267 Source ATM Address 268 This is the Source's ATM address of an address binding in a MARS 269 server cache entry. The address, if specified, is E.164 or ATM 270 Forum NSAPA. This is the mar$sha field from [1]. 272 Source ATM SubAddress 273 This is the Source's ATM subaddress of an address binding in a MARS 274 server cache entry. The subaddress, if specified, is an ATM Forum 275 NSAPA. If null, no storage will be allocated. This is the mar$ssa 276 field from [1]. 278 Minimum Multicast Group Address 279 This is the internetwork address of the lower bound on the range of 280 multicast group addresses for the address binding in a MARS server 281 cache entry. If null, no storage will be allocated. This is the 282 mar$min.N field from [1]. 284 Maximum Multicast Group Address 285 This is the internetwork address of the upper bound on the range of 286 multicast group addresses for the address binding in a MARS server 287 cache entry. If null, no storage will be allocated. This is the 288 mar$max.N field from [1]. 290 4. Values for SCSP Protocol Independent Part 292 The following sections give values for fields of the SCSP Protocol 293 Independent Part of the various SCSP messages. 295 4.1 Values for the SCSP "Mandatory Common Part" 297 Protocol ID = 0x0003 298 Sender ID Len = 0x04 299 Recvr ID Len = 0x04 301 See Section B.2.0.1 of [2] for a detailed description of these 302 fields. 304 4.2 Values for the SCSP "CSAS Record" 306 Cache Key Len = 0x04 307 Orig ID Len = 0x04 309 See Section B.2.0.2 of [2] for a detailed description of these 310 fields. 312 5. Detailed State Descriptions 314 5.1 MARS Server Redirect Entry. 316 The MARS Server Redirect Entry is used to determine the operational 317 state of a MARS Server in the SG. Each server MUST update it's MARS 318 Server Redirect Entry state at least every 2 minutes, it is 319 RECOMMENDED that it is updated every 1 minute. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Hardware Type | Protocol Type | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | SNAP | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | SNAP | Unused | Version | State | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Flags | Cluster Member ID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L| 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Source ATM Address (variable length) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Source ATM SubAddress (variable length) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Hardware Type 340 This value is the ATM Forum 'address family number' specified in 341 [3] as 15 decimal (0x000F). 343 Protocol Type 344 This field is the protocol type number for the protocol using MARS 345 from [3]. (IPv4 is 0x0800). 347 Protocol SNAP 348 This field is the optional protocol SNAP extension to protocol 349 type. This is the mar$pro.snap field from [1]. 351 Version Number 352 Version Number for this document MUST be set to 0x00. 354 State 355 State value is coded as 1 decimal for a MARS Server Redirect Entry. 357 The Flags, Cluster Member ID, Src Addr Len, and Group Addr Len fields are 358 unused and set to zero. 360 The ATM Addr T/L, ATM SubAddr T/L, Source ATM Address, and Source ATM 361 SubAddress fields define the ATM address for the source of the 362 MARS Server Redirect Entry in the SG. The coding for these fields are 363 the same as described in Section 3 of this document. 365 Failure to receive two consecutive MARS Server Redirect Entry updates 366 from a given MARS Server in the SG will cause all membership information 367 learned from this server to be flushed. When a valid MARS Server Redirect 368 Entry update is received the source of this update will be placed into 369 the table of backup MARS Servers sent in the MARS_REDIRECT_MAP message. The 370 ordering of servers in the MARS_REDIRECT_MAP will first contain the list of 371 MARS Servers learned via MARS Server Redirect Entry updates in ascending 372 order based on the SCSP Sender ID, followed by any externally configured or 373 learned backup MARS Servers. The format of the MARS_REDIRECT_MAP can 374 be found in Section 5.4.3 of [1]. 376 5.2 MCS Serve/Register request. 378 The MCS Serve/Register request is used to propagate the registering 379 or servicing of specific groups by an MCS Client within the SG 380 domain. It is similar to an MARS_MSERV request defined in Section 381 6.2.2 and 6.2.3 of [1]. When a MARS Server in the SG successfully 382 adds a new MCS Client to it's SCVC or adds MCS support for a specific 383 group it MUST send a MCS Serve/Register request to the SG. An MCS 384 Client can only register with one MARS Server in the SG. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Hardware Type | Protocol Type | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | SNAP | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | SNAP | Unused | Version | State | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Flags | Cluster Member ID | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L| 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Source Protocol Address (variable length) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Source ATM Address (variable length) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Source ATM SubAddress (variable length) | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Minimum Multicast Group Address (variable length) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Maximum Multicast Group Address (variable length) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Hardware Type 411 This value is the ATM Forum 'address family number' specified in 412 [3] as 15 decimal (0x000F). 414 Protocol Type 415 This field is the protocol type number for the protocol using MARS 416 from [3]. (IPv4 is 0x0800). 418 Protocol SNAP 419 This field is the optional protocol SNAP extension to protocol 420 type. This is the mar$pro.snap field from [1]. 422 Version Number 423 Version Number for this document MUST be set to 0x00. 425 State 426 State value is coded as 2 decimal for a MCS Serve/Register request. 428 Flags 429 The flags field is used to contain several flags: 431 mar$flags 432 Bit 15 - mar$flags.layer3grp 433 Bit 13 - mar$flags.register 434 Bit 0-7 - mar$flags.sequence 436 The mar$flags.register bit MUST be set the same as in the 437 originating MARS_MSERV request. The mar$flags.layer3grp bit MUST be 438 zero and the mar$flags.sequence bits are of local significance only 439 to the LS. 441 Cluster Member CMI 442 This field contains the CMI assigned by the MARS Server which 443 processed the MARS_MSERV request and uniquely identifies the MCS 444 Client in the MARS server cache. 446 Src Addr Len 447 This field contains the length of the Source Protocol Address 448 field. For IPv4, the value is 4 if an address is specified. A null 449 (non-existent) address MUST be coded as zero length, and no space 450 allocated for it in the message body. 452 Group Addr Len 453 This field contains the length of the Group Protocol Address field. 454 If the register bit in the flags field is set to 1 in the request 455 this field MUST be zero. If the register bit is zero in the flags 456 field the value of this field for IPv4 is 4. 458 ATM Addr T/L 459 This field contains the type and length of the Source ATM Address 460 field for the MCS Client that originated the MARS_MSERV request. 461 The type and length encoding is described in Section 3. 463 ATM SubAddr T/L 464 This field contains the type and length of the Source ATM 465 SubAddress field for the MCS Client that originated the MARS_MSERV 466 request. The type and length encoding is described in Section 3. 468 Source Protocol Address 469 This is the internetwork address for the source of an address 470 binding in a MARS server cache entry. If Src Addr Len is set to 471 zero no storage will be allocated. 473 Source ATM Address 474 This is the MCS Client's ATM address of an address binding in a 475 MARS server cache entry. The address is E.164 or ATM Forum NSAPA. 477 Source ATM SubAddress 478 This is the MCS Client's ATM subaddress of an address binding in a 479 MARS server cache entry. The subaddress, if specified, is an ATM 480 Forum NSAPA. If null, no storage will be allocated. 482 Minimum Multicast Group Address 483 This is the internetwork address of the lower bound on the range of 484 multicast group addresses for the address binding in a MARS server 485 cache entry. If Group Addr Len is set to zero no storage will be 486 allocated. 488 Maximum Multicast Group Address 489 This is the internetwork address of the upper bound on the range of 490 multicast group addresses for the address binding in a MARS server 491 cache entry. If Group Addr Len is set to zero no storage will be 492 allocated. 494 An MCS Client can only register with one MARS Server in the SG and is 495 only placed on the SCVC for the MARS Server for which it is 496 registered with. 498 When a MCS Client Serve/Register request specifying a group address 499 is received by a MARS Server it MUST create a cache entry associated 500 with this client. In addition to adding the cache entry it MUST send 501 out a MARS_MIGRATE message on it's CCVC. This is needed so that 502 clients using a mesh topology can migrate to a server based topology. 503 Details regarding the MARS_MIGRATE message can be found in Section 504 5.1.6 of [1]. 506 5.3 MARS Client Join/Register request. 508 The MARS Client Join/Register request is used to propagate the 509 registering or joining of specific group ranges by MARS Clients 510 within the SG domain. It is similar to the MARS_JOIN request defined 511 in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the SG 512 successfully registers a new MARS Client or a registered client joins 513 a specific group address range the MARS Server MUST send a MARS 514 Client Join/Register request to the SG. A MARS Client can only 515 register with one MARS Server in the SG and is placed only on that 516 servers CCVC. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Hardware Type | Protocol Type | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | SNAP | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | SNAP | Unused | Version | State | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Flags | Cluster Member ID | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L| 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Source Protocol Address (variable length) | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Source ATM Address (variable length) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Source ATM SubAddress (variable length) | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Minimum Multicast Group Address (variable length) | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Maximum Multicast Group Address (variable length) | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Hardware Type 543 This value is the ATM Forum 'address family number' specified in 544 [3] as 15 decimal (0x000F). 546 Protocol Type 547 This field is the protocol type number for the protocol using MARS 548 from [3]. (IPv4 is 0x0800). 550 Protocol SNAP 551 This field is the optional protocol SNAP extension to protocol 552 type. This is the mar$pro.snap field from [1]. 554 Version Number 555 Version Number for this document MUST be set to 0x00. 557 State 558 State value is coded as 3 decimal for a MARS Client Join/Register request. 560 Flags 561 The flags field is used to contain several flags: 563 mar$flags 564 Bit 15 - mar$flags.layer3grp 565 Bit 13 - mar$flags.register 566 Bit 0-7 - mar$flags.sequence 568 The mars$flags.layer3grp and mar$flags.register bits MUST be set 569 the same as in the originating MARS_JOIN request. The 570 mar$flags.sequence bits are of local significance only to the LS. 572 Cluster Member CMI 573 This field contains the CMI assigned by the MARS Server which 574 processed the MARS_JOIN request and uniquely identifies the MARS 575 Client in the MARS server cache. 577 Src Addr Len 578 This field contains the length of the Source Protocol Address 579 field. For IPv4, the value is 4 if an address is specified. A null 580 (non-existent) address MUST be coded as zero length, and no space 581 allocated for it in the message body. 583 Group Addr Len 584 This field contains the length of the Group Protocol Address field. 585 If the register bit in the flags field is set to 1 in the request 586 this field MUST be zero. If the register bit is zero in the flags 587 field the value of this field for IPv4 is 4. 589 ATM Addr T/L 590 This field contains the type and length of the Source ATM Address 591 field for the MARS Client that originated the MARS_JOIN request. 592 The type and length encoding is described in Section 3. 594 ATM SubAddr T/L 595 This field contains the type and length of the Source ATM 596 SubAddress field for the MARS Client that originated the MARS_JOIN 597 request. The type and length encoding is described in Section 3. 599 Source Protocol Address 600 This is the internetwork address for the source of an address 601 binding in a MARS server cache entry. If Src Addr Len is set to 602 zero no storage will be allocated. 604 Source ATM Address 605 This is the MARS Client's ATM address of an address binding in a 606 MARS server cache entry. The address is E.164 or ATM Forum NSAPA. 608 Source ATM SubAddress 609 This is the MARS Client's ATM subaddress of an address binding in a 610 MARS server cache entry. The subaddress, if specified, is an ATM 611 Forum NSAPA. If null, no storage will be allocated. 613 Minimum Multicast Group Address 614 This is the internetwork address of the lower bound on the range of 615 multicast group addresses for the address binding in a MARS server 616 cache entry. If Group Addr Len is set to zero no storage will be 617 allocated. 619 Maximum Multicast Group Address 620 This is the internetwork address of the upper bound on the range of 621 multicast group addresses for the address binding in a MARS server 622 cache entry. If Group Addr Len is set to zero no storage will be 623 allocated. 625 An MARS Client can only register with one MARS Server in the SG and 626 is only placed on the CCVC for the MARS Server for which it is 627 registered with. If the mar$flags.layer3grp is set to 1 than the 628 Minimum and Maximum Multicast Group Addresses MUST be equal for IPv4. 630 When a MARS Client Join/Register request is sent with the 631 mar$flags.register bit set to 1 all of the servers in the SG will 632 create a cache entry for this client using the information in the 633 request. 635 When a registered MARS Client issues a MARS_JOIN for a specific group 636 address range a MARS Client Join/Register request MUST be sent to the 637 servers in the SG. The actions taken by each server in the SG depend 638 on previous group membership actions and MCS supported groups. 640 Each MARS Server MUST preform the necessary redistribution and hole 641 punching algorithms before propagating this request to the CCVC and 642 SCVC on each server. The redistribution and hole punching algorithms 643 used for propagating join requests to the CCVC are the same as 644 defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating 645 MARS_JOIN request is a duplicate of a previously joined range or 646 contains no group address range than a MARS Client Join/Register MUST 647 NOT be sent to the SG. 649 The redistribution and hole punching algorithms used for propagating 650 join reqests as MARS_SJOIN request on a SCVC is the same as Section 651 6.2.4 except for the following. Only the MARS Servers which contain 652 the registered MCS Clients for the target group ranges should 653 propagate this information to their SCVCs. 655 5.4 MARS Client Leave/Deregister request. 657 The MARS Client Leave/Deregister request is used to propagate the 658 deregistering or leaving of specific group ranges by registered MARS 659 Clients within the SG domain. It is similar to the MARS_LEAVE request 660 defined in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the 661 SG successfully deregisters a registered MARS Client or a registered 662 client leaves a specific group address range for which it had joined 663 the MARS Server MUST send a MARS Client Leave/Deregister request to 664 the SG. If a registered MARS Client is unexpectedly removed from the 665 CCVC the MARS Server MUST act as a proxy and send a MARS Client 666 Leave/Deregister request to the SG. 668 The format and meanings of the fields in a MARS Client 669 Leave/Deregister request are the same as in Section 5.3 except the 670 State is coded as 4 decimal for a MARS Client Leave/Deregister 671 request. 673 When a MARS Client Leave/Deregister request is sent with the 674 mar$flags.register bit set to 1 all of the servers in the SG 675 receiving this update MUST purge all cache entries for this client. 677 When a registered MARS Client issues a MARS_LEAVE for a specific 678 group address range a MARS Client LEAVE/Deregister request MUST be 679 sent to the servers in the SG. The actions taken by each server in 680 the SG depend on previous group membership actions and MCS supported 681 groups. 683 Each MARS Server MUST preform the necessary redistribution and hole 684 punching algorithms before propagating this request to the CCVC and 685 SCVC on each server. The redistribution and hole punching algorithms 686 used for propagating leave requests to the CCVC are the same as 687 defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating 688 MARS_LEAVE request does not correspond to a previously joined range 689 or contains no group address range than a MARS Client 690 Leave/Deregister MUST NOT be sent to the SG. 692 The redistribution and hole punching algorithms used for propagating 693 leave requests as MARS_SLEAVE requests on a SCVC is the same as 694 Section 6.2.4 except for the following. Only the MARS Servers which 695 contain the registered MCS Clients for the target group ranges should 696 propagate this information to their SCVCs. 698 5.5 MCS Unserve/Deregister request. 700 The MCS Unserve/Deregister request is used to propagate the 701 deregistering or unservicing of specific groups by a registered MCS 702 Client within the SG domain. It is similar to an MARS_MUNSERV request 703 defined in Section 6.2.2 and 6.2.3 of [1]. When a MARS Server in the 704 SG successfully deregisters a registered MCS Client or registered MCS 705 Client stops serving a specific group address range for which it had 706 serviced the MARS Server MUST send a MCS Unserve/Deregister request 707 to the SG. If a registered MCS Client is unexpectedly removed from 708 the SCVC the MARS Server owning the SCVC MUST act as a proxy and send 709 a MCS Unserve/Deregister request to the SG. 711 The format and meanings of the fields in a MCS Unserve/Deregister 712 request are the same as in Section 5.2 except the State is coded as 5 713 decimal for a MCS Unserve/Deregister request. 715 When a MCS Client Unserve/Deregister request is sent with the 716 mar$flags.register bit set to 1 all of the servers in the SG 717 receiving this update MUST purge all cache entries for this client. 719 When a registered MCS Client issues a MARS_MUNSERV for a specific 720 group address range being served a MCS Client Unserve/Deregister 721 request MUST be sent to the servers in the SG. The members of the SG 722 that receive this update must then clear the cache entry associated 723 with this MCS Client. 725 In addition to clearing one or more cache entries associated with 726 receiving a MCS Client Unserve/Deregister request each MARS Server 727 in the SG MUST send out a MARS_LEAVE message on it's CCVC in order 728 for clients to change back to a mesh topology. 730 6. Security Consideration 732 Security is not addressed in this document but is addressed in the 733 SCSP Protocol Independent part [2]. 735 References 737 [1] "Support for Multicast over UNI 3.0/3.1 based ATM Networks", Armitage, 738 RFC2022. 740 [2] "Server Cache Synchronization Protocol", Luciani, Armitage, Halpern, 741 draft-ietf-ion-scsp-01.txt. 743 [3] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 745 [4] "Classic IP and ARP over ATM", Mark Laubach, RFC 1577. 747 [5] "Redundant MARS architectures and SCSP, Armitage, 748 draft-armitage-ion-mars-scsp-03.txt. 750 Acknowledgments 752 The authors would like to thank Grenville Armitage for his previous 753 distributed MARS work and also the members of the ION working group 754 of the IETF, whose review and discussion of this document has been 755 invaluable. 757 Author's Address 759 James V. Luciani 760 Bay Networks, Inc. 761 3 Federal Street, BL3-04 762 Billerica, MA 01821 763 phone: +1-508-916-4734 764 email: luciani@baynetworks.com 766 Anthony M. Gallo 767 IBM, Networking Hardware Division 768 Dept. M6LA/B664 769 P.O. Box 12195 770 Research Triangle Park, NC 27709 771 phone: +1-919-254-9889 772 email: gallo@raliegh.ibm.com