idnits 2.17.1 draft-ietf-ipatm-ipmc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) 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. ** 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 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 22 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** 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 289: '...ll MARS messages MUST be LLC/SNAP enca...' RFC 2119 keyword, line 334: '...response traffic MUST occur on a point...' RFC 2119 keyword, line 342: '...s case the IP packet MUST be discarded...' RFC 2119 keyword, line 355: '.... ATM.n}. A MARS MUST minimise the num...' RFC 2119 keyword, line 358: '... message length MUST be the MTU of th...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 427 has weird spacing: '...qoctets sourc...' == Line 428 has weird spacing: '...roctets sourc...' == Line 429 has weird spacing: '...soctets sourc...' == Line 430 has weird spacing: '...xoctets targe...' == Line 431 has weird spacing: '...yoctets targe...' == (9 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: 'LIS' on line 995 == Unused Reference: '6' is defined on line 1398, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1483 (ref. '2') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1577 (ref. '3') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '5') -- Unexpected draft version: The latest known version of draft-ietf-ipatm-sig is -01, but you're referring to -02. Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Grenville Armitage 3 Bellcore 4 February 4th, 1995 6 Support for Multicast over UNI 3.1 based ATM Networks. 7 9 Status of this Memo 11 This document was submitted to the IETF IP over ATM WG. Publication 12 of this document does not imply acceptance by the IP over ATM WG of 13 any ideas expressed within. Comments should be submitted to the ip- 14 atm@matmos.hpl.hp.com mailing list. 16 Distribution of this memo is unlimited. 18 This memo is an internet draft. Internet Drafts are working documents 19 of the Internet Engineering Task Force (IETF), its Areas, and its 20 Working Groups. Note that other groups may also distribute working 21 documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a "working 27 draft" or "work in progress". Please check the lid-abstracts.txt 28 listing contained in the internet-drafts shadow directories on 29 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or 30 munnari.oz.au to learn the current status of any Internet Draft. 32 Abstract 34 This memo describes a Multicast Address Resolution Server (MARS) 35 architecture that allows ATM based IP hosts to support RFC 1112 style 36 Level 2 IP multicast using the ATM Forum's UNI 3.1 point to 37 multipoint connection service. It also describes how this 38 architecture can be generalized to support other protocols wishing to 39 multicast over UNI 3.1 based ATM service. 41 [Editorial note: The differences between this version and 03.txt 42 are substantial in the area of multicast server support. This 43 impacts on Chapter 8, and anything referring to MARS_MSERV. Two 44 control VCs have been identified and named, two sequence numbers 45 are now used, and three major appendices have been added 46 discussing issues that cannot at this time be standardized. The 47 MARS_JOIN/LEAVE message format has been extended by 32 bits, and 48 modified to support multiple address groups. Scattered 49 editorial/clarificatory changes have been made to the rest of the 50 document. Editorial notes will be removed.] 52 1. Introduction. 54 Multicast support allows a source host or protocol entity to send a 55 packet to multiple destinations simultaneously using a single, local 56 'transmit' operation. This facility is utilized by network layer 57 protocols such IP. Most models, like the one described in RFC 1112 58 [1] for IP multicasting, assume sources may send their packets to an 59 abstract 'multicast group addresses'. Link layer support for such an 60 abstraction is assumed to exist, and is provided by technologies such 61 as Ethernet. 63 ATM is being utilized as a new link layer technology to support a 64 variety of protocols, including IP. With RFC 1483 [2] the IETF 65 defined a multiprotocol mechanism for encapsulating and transmitting 66 packets using AAL5 over ATM Virtual Channels (VCs). However, the ATM 67 Forum's currently published signalling specification (UNI 3.0 [4], 68 with additions for UNI 3.1 released in late 1994) does not provide 69 the multicast address abstraction. Unicast connections are supported 70 by point to point, bidirectional VCs. Multicasting is supported 71 through point to multipoint VCs. The key limitation is that the 72 sender must have prior knowledge of each intended recipient, and 73 explicitly establish a VC with itself as the root node and the 74 recipients as the leaf nodes. 76 The main goal of this document is to define an address registration 77 and distribution mechanism that allows UNI 3.1 based networks to 78 support the multicast service of protocols such as IP. The second 79 goal is to define specific endpoint behaviour and management of point 80 to multipoint VCs. As the IETF is currently in the forefront of 81 using wide area multicasting this document's descriptions will focus 82 on IP version 4 (IPv4). A final chapter will note the more general 83 application of the architecture. 85 The Multicast Address Resolution Server (MARS), a distant relative of 86 the ATM ARP Server introduced in RFC 1577 [3], acts as a registry of 87 multicast group membership. MARS messages, based on the ATM ARP 88 format, support the distribution of multicast group membership 89 information between MARS and hosts or endpoints. Endpoint address 90 resolution entities query the MARS when a multicast group address 91 needs to be resolved. The actual mechanism for multicasting data 92 packets may be through meshes of point to multipoint VCs, or the use 93 of Multicast Servers. To provide for asynchronous notification of 94 group membership changes the MARS manages two point to multipoint VCs 95 - one out to all endpoints desiring multicast support, and the other 96 to all multicast servers registered as providing support to any 97 multicast groups. The choice of mesh or multicast server is 98 configurable on a group by group basis. 100 The numerical size of link layer multicast groups will be constrained 101 by practical concerns such as limited VC support within endpoint ATM 102 interfaces. Each MARS manages a 'cluster' of ATM-attached endpoints. 103 A cluster is defined as a set of endpoints willing to be grouped 104 together as link layer members of multicast groups. It is assumed 105 that specially configured routers are used to pass multicast traffic 106 between clusters. This document explicitly avoids specifying the 107 nature of inter-cluster multicast routing protocols. 109 The mapping of clusters to other constrained sets of endpoints (such 110 as Logical IP Subnets) is left to network administrators. A simple 111 approach in overlaid IP environments would be for each LIS to be 112 served by a separate MARS, with the cluster being built from the LIS 113 members. IP multicast routers would interconnect each LIS as they do 114 with conventional subnets. However, there is no requirement that a 115 cluster be limited to a single LIS. 117 Section 2 provides an overview of IP multicast and what RFC 1112 118 required from Ethernet. Section 3 outlines the set of generic 119 functions that should be available to clients of a local host's UNI 120 3.1 signalling service. Section 4 specifies the encapsulation to be 121 used for MARS messages and multicast packet traffic. The basic 122 behaviour for the sending side of an interface is described in 123 section 5, with section 6 covering the mechanism whereby a host joins 124 and leaves multicast groups. Sections 7 covers the way in which hosts 125 respond to dynamic group membership changes. Configuring the use of 126 Multicast Servers is covered in section 8. Support for multicast 127 routers is described in section 9, and section 10 explains the 128 features included to improve the reliability of the membership 129 management mechanisms. Section 11 discusses the application of this 130 document beyond IP. Section 12 is a summary of the documents key 131 points. 133 The appendices provide discussion on issues that arise out the 134 implementation of this memo. Appendix A discusses MARS and endpoint 135 algorithms for parsing MARS messages. Appendix B describes the 136 particular problems introduced by the current IGMP paradigms, and 137 possible interim work-arounds. Finally, Appendix C covers the various 138 designs that are possible for multicast server support within 139 clusters. 141 This document assumes an understanding of concepts explained in 142 greater detail in RFC 1112, RFC 1577, UNI 3.1, and . 145 2. Review of RFC 1112 and IP Multicast over Ethernet. 147 Under IP version 4 (IPv4) ddresses in the range of 224.0.0.0 and 148 239.255.255.255 are termed 'Class D' or 'multicast group' addresses. 149 In RFC 1112 the behaviour of the transmit and receive sides are quite 150 independent, making the concept of being a 'member' of an IP 151 multicast group imprecise at the link layer interface. 153 The interface must support the transmission of IP packets to an IP 154 multicast group address, whether or not the node considers itself a 155 'member' of that group. Consequently, group membership is effectively 156 irrelevant to the transmit side of the link layer interfaces. No 157 address resolution is required to transmit packets - an algorithmic 158 mapping from IP multicast address to Ethernet multicast address is 159 performed locally before the packet is sent out the local interface 160 in the same 'send and forget' manner as a unicast IP packet. 162 Joining and Leaving an IP multicast group is more explicit on the 163 receive side - with the primitives JoinLocalGroup and LeaveLocalGroup 164 affecting what groups the local link layer interface should accept 165 packets from. When the IP layer wants to receive packets from a 166 group, it issues JoinLocalGroup. When it no longer wants to receive 167 packets, it issues LeaveLocalGroup. A key point to note is that 168 changing state is a local issue, it has no affect on other hosts 169 attached to the Ethernet. 171 IGMP is defined in RFC 1112 to support IP multicast routers attached 172 to a given subnet. Hosts issue IGMP Report messages when they perform 173 a JoinLocalGroup, or in response to an IP multicast router sending an 174 IGMP Query. By periodically transmitting queries IP multicast routers 175 are able to identify what IP multicast groups have non-zero 176 membership on a given subnet. 178 A specific IP multicast address, 224.0.0.1, is allocated for the 179 transmission of IGMP Query messages. All IP multicast hosts must 180 issue JoinLocalGroup for 224.0.0.1 during their initialisation. Each 181 host keeps a list of IP multicast groups it has been JoinLocalGroup'd 182 to. When a router issues an IGMP Query on 224.0.0.1 each host begins 183 to send IGMP Reports for each group it is a member of. IGMP Reports 184 are sent to the group address, not 224.0.0.1, "so that other members 185 of the same group on the same network can overhear the Report" and 186 not bother sending one of their own. IP multicast routers conclude 187 that a group has no members on the subnet when IGMP Queries no longer 188 elict associated replies. 190 3. Multicast support under UNI 3.1. 192 This document will describe its operation in terms of 'generic' 193 functions that should be available to clients of a UNI 3.1 signalling 194 entity in a given ATM endpoint. The ATM model broadly describes 'AAL 195 Users' as any entity that establishes and manages VCs and underlying 196 AAL service to exchange data. An IP over ATM interface is a form of 197 'AAL User' (either directly, when VC multiplexing is used, or 198 indirectly, when LLC/SNAP encpasulation is used). 200 The most fundamental limitations of UNI 3.1's multicast support are: 202 Only point to multipoint, unidirectional VCs may be established. 204 Only the root node of a given VC may add or remove leaf nodes. 206 Within these constraints, multicast group members can communicate by 207 the use of multicast meshes, or multicast servers. With a mesh each 208 transmitting host is the Root of a point to multipoint VC that has 209 every other host in the group as a Leaf. The Multicast Server model 210 has every group member send their packets directly to a 'server' 211 entity somewhere on the ATM cloud, which then retransmits copies to 212 all other members. 214 This document defines the MARS-Endpoint signalling required to 215 support both mechanisms. Issues relating to the architecture, 216 operation, and management of multicast servers are discussed in 217 Appendix C. 219 The following generic signalling functions are presumed to be 220 available to local AAL Users: 222 L_CALL_RQ - Establish a unicast VC to a specific endpoint. 223 L_MULTI_RQ - Establish multicast VC to a specific endpoint. 224 L_MULTI_ADD - Add new leaf node to previously established VC. 225 L_MULTI_DROP - Remove specific leaf node from established VC. 226 L_RELEASE - Release unicast VC, or all Leaves of a multicast VC. 228 The signalling exchanges and local information passed between AAL 229 User and UNI 3.1 signalling entity with these functions is currently 230 beyond the scope of this document. 232 The following indications are assumed to be available to AAL Users, 233 generated by by the local UNI 3.1 signalling entity: 235 L_ACK - Succesful completion of a request to signalling 236 entity. 237 L_REMOTE_CALL - A new VC has been established to the AAL User. 239 ERR_L_RQFAILED - A remote ATM endpoint rejected an L_CALL_RQ, 240 L_MULTI_RQ, or L_MULTI_ADD. 241 ERR_L_RELEASE - A remote ATM endpoint has elected to terminate a 242 pre-existing VC. 244 The signalling exchanges and local information passed between AAL 245 User and UNI 3.1 signalling entity with these functions is currently 246 beyond the scope of this document. 248 UNI 3.1 defines two ATM address formats - E.164 and ISO NSAP. In UNI 249 3.1 an 'ATM Number' is the primary identification of an ATM endpoint, 250 and it may use either format. Under some circumstances an ATM 251 endpoint must be identified by both an E.164 address (identifying the 252 attachment point of a private network to a public network), and an 253 ISO NSAP address ('ATM Subaddress') identifying the final endpoint 254 within the private network. For the rest of this document the term 255 'ATM Address' will be used to mean either a single 'ATM Number' or an 256 'ATM Number' combined with an 'ATM Subaddress'. 258 4. Overview of the Multicast Address Resolution Server. 260 The MARS may reside within any ATM endpoint that is directly 261 addressable by the endpoints it is serving. Endpoints wishing to join 262 a multicast cluster must be configured with the ATM address of the 263 node on which the cluster's MARS resides. This is the cluster's 264 Primary MARS. If a cluster is to be served by a backup MARS, 265 endpoints are configured with the ATM address of a Secondary MARS. 266 Section 10 will discuss the relationship between the Primary MARS and 267 Secondary MARS during failure conditions. Although a Secondary MARS 268 is optional, endpoint implementations must be capable of utilizing 269 them as described in section 10. References to 'the MARS' in 270 following sections will be assumed to mean the acting MARS for the 271 cluster. 273 Architecturally the MARS is similar to the RFC 1577 ARP Server, 274 although there is little overlap between the information they manage. 275 Whilst the ARP Server keeps a table of {IP,ATM} address pairs for all 276 IP endpoints in the LIS, the MARS keeps extended tables of {multicast 277 address, ATM.1, ATM.2, ..... ATM.n} mappings. It can either be 278 configured with certain mappings, or dynamically 'learn' mappings. 280 The MARS distributes group membership information to cluster members 281 over a point to multipoint VC known as the ClusterControlVC. When 282 supporting multicast servers within a cluster, the MARS also 283 establishes a separate point to multipoint VC known as the 284 ServerControlVC. All cluster members are leaf nodes of 285 ClusterControlVC. All registered multicast servers are leaf nodes of 286 ServerControlVC (Section 8 will discuss the use of ServerControlVC). 288 The MARS message format is an extension of the ATM ARP message 289 format. By default all MARS messages MUST be LLC/SNAP encapsulated 290 in accordance with RFC 1483, using the same encapsulation as ATM ARP: 292 LLC = 0xAA-AA-03 293 OUI = 0x00-00-00 294 PID = 0x08-06 296 The default for data traffic carried on point to multipoint VCs is 297 LLC/SNAP encapsulation with a header appropriate to the protocol 298 being carried. For IP traffic this is defined in RFC 1483 as: 300 LLC = 0xAA-AA-03 301 OUI = 0x00-00-00 302 PID = 0x08-00 304 The choice of common encapsulation and message format means that MARS 305 and ARP Server functionality may be implemented within a common 306 entity if a network designer so chooses. 308 5. Transmitting to Multicast groups. 310 [Editorial note: This section has discarded the MARS_MSERV 311 function of version ipmc-03.txt. MARS_MSERV is now used in an 312 entirely different fashion. Endpoint VC management is now 313 entirely independent of whether the group is mesh or mc server 314 supported.] 316 The following description will be in terms of an IP/ATM interface 317 that is capable of transmitting packets to a Class D address at any 318 time, without prior warning. 320 When a packet arrives for transmission, and there is no outgoing VC 321 already marked as serving the packet's multicast destination address, 322 the MARS is queried for the set of ATM endpoints currently making up 323 the multicast group. 325 The query is executed by issuing a MARS_REQUEST. The MARS_REQUEST 326 message is formatted as an ATM ARP_REQUEST with type code of 11 327 (decimal). The reply from the MARS may take one of two forms: 329 MARS_MULTI - Sequence of MARS_MULTI messages return the set of 330 endpoints in the group. 332 MARS_NAK - No mapping found, group is empty. 334 The request/response traffic MUST occur on a point to point VC 335 established by the host to the MARS. Where the MARS and ARP Server 336 are co-resident, this VC may be shared between ATM ARP traffic and 337 MARS traffic. 339 5.1 Retrieving Group Membership from the MARS. 341 If the MARS had no mapping for the desired Class D address a MARS_NAK 342 will be returned. In this case the IP packet MUST be discarded 343 silently. If a match is found in the MARS's tables it proceeds to 344 return addresses ATM.1 through ATM.n in a sequence of one or more 345 MARS_MULTIs. A simple mechanism is used to detect and recover from 346 loss of MARS_MULTI messages. 348 Each MARS_MULTI carries a new boolean field x, and a 15 bit integer 349 field y - expressed as MARS_MULTI(x,y). Field y acts as a sequence 350 number, starting at 1 and incrementing for each MARS_MULTI sent. 351 Field x acts as an 'end of reply' marker. When x == 1 the MARS 352 response is considered complete. 354 In addition, each MARS_MULTI may carry multiple ATM addresses from 355 the set {ATM.1, ATM.2, .... ATM.n}. A MARS MUST minimise the number 356 of MARS_MULTIs transmitted by placing as many group member's 357 addresses in a single MARS_MULTI as possible. The limit on MARS_MULTI 358 message length MUST be the MTU of the underlying VC. 360 Assume n ATM addresses must be returned, each MARS_MULTI is limited 361 to only p ATM addresses, and p << n. This would require a sequence of 362 k MARS_MULTI messages (where k = (n/p)+1, using integer arithmetic), 363 transmitted as follows: 365 MARS_MULTI(0,1) carries back {ATM.1 ... ATM.p} 366 MARS_MULTI(0,2) carries back {ATM.(p+1) ... ATM.(2p)} 367 [.......] 368 MARS_MULTI(1,k) carries back { ... ATM.n} 370 If k == 1 then only MARS_MULTI(1,1) is sent. 372 Typical failure mode will be losing one or more of MARS_MULTI(0,1) 373 through MARS_MULTI(0,k-1). This is detected when y jumps by more than 374 one between consecutive MARS_MULTI's. An alternative failure mode is 375 losing MARS_MULTI(1,k). A timer MUST be implemented to flag the 376 failure of the last MARS_MULTI to arrive. A default value of 10 377 seconds is suggested. 379 If a 'sequence jump' is detected, the host MUST wait for the 380 MARS_MULTI(1,k), discard all results, and repeat the MARS_REQUEST. 382 If a timeout occurs, the host MUST discard all results, and repeat 383 the MARS_REQUEST. 385 Corruption of cell contents will lead to loss of a MARS_MULTI through 386 AAL5 CPCS_PDU reassembly failure, which will be detected through the 387 mechanisms described above. 389 If the MARS is managing a cluster of endpoints spread across 390 different but directly accessible ATM networks it will not be able to 391 return all the group members in a single MARS_MULTI. The MARS_MULTI 392 message format allows for either E.164, ISO NSAP, or (E.164 + NSAP) 393 to be returned as ATM addresses. However, each MARS_MULTI message may 394 only return ATM addresses of the same type. The returned addresses 395 MUST be grouped according to type (E.164, ISO NSAP, or both) and 396 returned in a sequence of separate MARS_MULTI parts. 398 5.2 MARS_REQUEST, MARS_MULTI, MARS_MSERV, and MARS_NAK formats. 400 MARS_REQUEST is based on an ATM ARP_REQUEST, but with an 'operation 401 type value' of 11 (decimal). The multicast address being resolved is 402 placed into the the target protocol address field (ar$tpa). The 403 hardware type (ar$hrd) is set to 19 (decimal), and in IP environments 404 the protocol type is 2048 (decimal). Section 6.6 of RFC 1577 should 405 be consulted for specific details and coding of the ar$shtl, ar$sstl, 406 ar$thtl, and ar$tstl fields. 408 MARS_NAK is the MARS_REQUEST returned with operation type value of 16 409 (decimal). 411 The MARS_MULTI message is identified by an 'operation type value' of 412 12 (decimal). The message format is: 414 Data: 415 ar$hrd 16 bits Hardware type ( 19 decimal, 0x13 hex) 416 ar$pro 16 bits Protocol type 417 ar$shtl 8 bits Type & length of source ATM number (q) 418 ar$sstl 8 bits Type & length of source ATM subaddress (r) 419 ar$op 16 bits Operation code (MARS_MULTI) 420 ar$spln 8 bits Length of source protocol address (s) 421 ar$thtl 8 bits Type & length of target ATM number (x) 422 ar$tstl 8 bits Type & length of target ATM subaddress (y) 423 ar$tpln 8 bits Length of target multicast group address (z) 424 ar$tnum 16 bits Number of target ATM addresses returned (N). 425 ar$seqxy 16 bits Boolean flag x and sequence number y. 426 ar$msn 32 bits MARS Sequence Number. 427 ar$sha qoctets source ATM number 428 ar$ssa roctets source ATM subaddress 429 ar$spa soctets source protocol address 430 ar$tha.1 xoctets target ATM number 1 431 ar$tsa.1 yoctets target ATM subaddress 1 432 ar$tpa zoctets target multicast group address 433 ar$tha.2 xoctets target ATM number 2 434 ar$tsa.2 yoctets target ATM subaddress 2 435 [.......] 436 ar$tha.N xoctets target ATM number N 437 ar$tsa.N yoctets target ATM subaddress N 439 ar$seqxy is coded with flag x in the leading bit, and sequence number 440 y coded as an unsigned integer in the remaining 15 bits. 442 0 1 443 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |x| y | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 ar$tnum is an unsigned integer indicating how many pairs of 449 {ar$tha,ar$tsa} (i.e. how many group member's ATM addresses) are 450 present in the message. ar$msn is an unsigned 32 bit number filled in 451 by the MARS before transmitting each MARS_MULTI. Its use is described 452 further in section 10. Section 6.6 of RFC 1577 should be consulted 453 for specific details and coding of all other fields. 455 As an example, assume we have a multicast cluster using 4 byte 456 protocol addresses, 20 byte ATM numbers, and 0 byte ATM subaddresses. 457 For n group members in a single MARS_MULTI we require a (44 + 20n) 458 byte message. If we assume the default MTU of 9180 bytes, we can 459 return a maximum of 456 group member's addresses in a single 460 MARS_MULTI. 462 5.3 Establishing the Multicast VC. 464 Following the completion of the MARS_MULTI reply the endpoint may 465 establish a new point to multipoint VC, or reuse an existing one. 467 If establishing a new VC, an L_MULTI_RQ is issued for ATM.n, followed 468 by an L_MULTI_ADD for every member of the set {ATM.1, ....ATM.(n-1)} 469 (assuming the set is non-null). The packet is then transmitted over 470 the newly created VC just as it would be for a unicast VC. 472 After transmitting the packet, the local interface holds the VC open 473 and marks it as the active path out of the host for any subsequent IP 474 packets being sent to that Class D address. 476 When establishing a new multicast VC is is possible that one or more 477 returned endpoints may reject an L_MULTI_RQ or L_MULTI_ADD. If this 478 occurs then the endpoint's ATM address is dropped from the set 479 {ATM.1, ATM.2, .... ATM.n} returned by the MARS, and the creation of 480 the multipoint VC continues. 482 Multicast VCs have the potential to be expensive in their use of 483 resources. Therefore each VC MUST have a configurable inactivity 484 timer associated with it. If the timer expires, an L_RELEASE is 485 issued for that VC, and the Class D address is no longer considered 486 to have an active path out of the local host. The timer SHOULD be no 487 less than 1 minute, and a default of 20 minutes is RECOMMENDED. 488 Choice of specific timer periods is beyond the scope of this 489 document. 491 VC consumption may also be reduced by endpoints noting when a new 492 group's set of {ATM.1, ....ATM.n} matches that of a pre-existing VC 493 out to another group. With careful local management, and assuming the 494 QoS of the existing VC is sufficient for both groups, a new pt to mpt 495 VC may not be necessary. Algorithms for performing this type of 496 optimization are not discussed here, and are not required for 497 conformance with this memo. 499 Section 7 describes the endpoint's response to group membership 500 changes while the VC is open. Section 10 describes the mechanism for 501 ensuring hosts remain up to date with changes that occur while the VC 502 is open. 504 6. Joining and Leaving Multicast Groups. 506 A cluster member is a 'group member' (in the sense that it receives 507 packets directed at the group) when its ATM address appears in the 508 MARS's table entry for the group's multicast address. A key 509 requirement within each cluster is the distribution of group 510 membership information between the MARS and cluster members. 512 Two new messages are defined: MARS_JOIN and MARS_LEAVE. These are 513 sent to the MARS by endpoints joining or leaving a multicast group. 514 The MARS propagates these messages back out to the cluster over its 515 ClusterControlVC, to ensure the knowledge is distributed in a timely 516 fashion. ClusterControlVC is an outgoing, point to multipoint VC with 517 each cluster member as a leaf node. 519 RFC1112 expects that IP multicast routers are capable of behaving 520 'promiscuously'. This functionality may be emulated by allowing 521 routers to request that the MARS returns them as 'wild card' members 522 of all Class D addresses. However, a problem inherent in the current 523 ATM model is that completely promiscuous behaviour may be wasteful of 524 reassembly resources on the router's ATM interface. This document 525 describes a generalisation to the notion of 'wild card' entries, 526 enabling routers to limit themselves to 'blocks' of the Class D 527 address space. The application of this facility is described in 528 greater detail in Section 9. 530 A block can be as small as 1 (a single group) or as large as the 531 entire Class D address space (default IPv4 'promiscuous' behaviour). 532 A block is defined as all addresses between, and inclusive of, a 533 address pair. 535 The key extensions required to manage the MARS table entries are: 537 Two new message types: 539 MARS_JOIN carries one or more pairs (specifying one 540 or more blocks of groups being joined) and a unicast ATM 541 address (of the node joining). 543 MARS_LEAVE carries one or more pairs (specifying one 544 or more blocks of groups being left) and a unicast ATM address 545 (of the node leaving). 547 When a MARS_JOIN is received by the MARS it adds the specified ATM 548 address to the table entry for the specified multicast group 549 address(es). 551 When a MARS_LEAVE is received by the MARS it removes the specified 552 ATM address from the ARP entry for the specified multicast group 553 address(es). 555 MARS_JOIN and MARS_LEAVE messages arriving from individual hosts 556 are processed locally by the MARS and retransmitted on 557 ClusterControlVC (possibly after modification, as detailed in 558 Section 8). 560 All endpoints MUST ignore MARS_JOIN or MARS_LEAVE messages that 561 simply confirm information already held. The MARS retransmits 562 redundant messages, but otherwise takes no action. Section 7 563 describes how endpoints utilize retransmitted MARS_JOIN and 564 MARS_LEAVE messages. 566 Cluster members MUST only include a single pair in each 567 JOIN/LEAVE message they issue. They MUST be able to process 568 multiple pairs in JOIN/LEAVE messages received on 569 ClusterControlVC from the MARS (the interpretation being that the 570 join/leave operation applies to all addresses in range from 571 to inclusive, for every pair). 573 In IPv4 environments JoinLocalGroup now results in two messages being 574 transmitted: 576 MARS_JOIN, sent over a VC to the ARP Server. It identifies the 577 single IP group being joined, and the host's unicast ATM address. 579 An IGMP Report, except for 224.0.0.1 (in accordance with RFC1112). 581 In IPv4 environments LeaveLocalGroup now results in a MARS_LEAVE 582 being sent over a VC to the MARS, identifying the IP group being 583 left, and the host's unicast ATM address. 585 Endpoints with special requirements (e.g. multicast routers) may 586 directly issue MARS_JOINs and MARS_LEAVEs specifying blocks of 587 multicast group addresses. No IGMP Report is issued for such 588 operations in IP environments. 590 An endpoint must register with a MARS in order to become a member of 591 a cluster and be added as a leaf to ClusterControlVC. Registration 592 is covered in section 6.2. 594 6.1 Format of the MARS_JOIN and MARS_LEAVE Messages. 596 The MARS_JOIN message is indicated by an operation type value of 14 597 (decimal). MARS_LEAVE has the same format and operation type value of 598 15 (decimal). The message format is: 600 Data: 601 ar$hrd 16 bits Hardware type (19 decimal) 602 ar$pro 16 bits Protocol type 603 ar$shtl 8 bits Type & length of source ATM number (q) 604 ar$sstl 8 bits Type & length of source ATM subaddress (r) 605 ar$op 16 bits Operation code (MARS_JOIN or MARS_LEAVE) 606 ar$spln 8 bits Length of source protocol address (s) 607 ar$tpln 8 bits Length of multicast group address (z) 608 ar$pnum 16 bits Number of multicast group address pairs (N) 609 ar$resv 16 bits Reserved. 610 ar$msn 32 bits MARS Sequence Number. 611 ar$sha qoctets source ATM number (E.164 or ATM Forum NSAPA). 612 ar$ssa roctets source ATM subaddress (ATM Forum NSAPA). 613 ar$spa soctets source protocol address 614 ar$min.1 zoctets Minimum multicast group address - pair.1 615 ar$max.1 zoctets Maximum multicast group mask - pair.1 616 [.......] 617 ar$min.N zoctets Minimum multicast group address - pair.N 618 ar$max.N zoctets Maximum multicast group mask - pair.N 620 Refer to RFC 1577, section 6.6 for the coding of the ar$shtl and 621 ar$sstl fields. For conventional IPv4 environments ar$spln and 622 ar$tpln are both set to 4. Note that the message format differs from 623 ATMARP_REPLY in the fields after ar$op. ar$msn is an unsigned 32 bit 624 number filled in by the MARS before re-transmitting a MARS_JOIN or 625 MARS_LEAVE. The originator SHOULD set it to zero, although it will be 626 ignored by the MARS. Its use is described further in section 10. 628 A join/leave message carries a set {, , ...., 629 }, with at least one pair. ar$pnum indicates how 630 many pairs are included in the message. To simplify MARS and endhost 631 interpretation, the following restrictions are imposed: 633 Assume max(N) is the field from the Nth pair. 634 Assume min(N) is the field from the Nth pair. 635 Assume a join/leave message arrives with K pairs. 636 The following must hold: 637 max(N) < min(N+1) for 1 <= N < K 638 max(N) >= min(N) for 1 <= N <= K 640 In plain english, the set must specify an ascending sequence of 641 address blocks. The definition of "greater" or "less than" may be 642 protocol specific. In IP environments the addresses are treated as 643 simple unsigned binary values. 645 6.1.1 Important IPv4 default values. 647 The JoinLocalGroup and LeaveLocalGroup operations are only valid for 648 a single group. For any arbitrary group address X the associated 649 MARS_JOIN or MARS_LEAVE MUST specify a single pair . 651 A router choosing to behave strictly in accordance with RFC1112 MUST 652 specify the entire Class D space. The associated MARS_JOIN or 653 MARS_LEAVE MUST specify a single pair <224.0.0.0, 239.255.255.255>. 655 The use of alternative values is discussed in Section 9. 657 6.2 Registering with the MARS. 659 Two separate signalling paths exist between cluster members and their 660 associated MARS. The first is a transient point to point VC that 661 cluster members establish to the MARS when they need to issue 662 MARS_REQUESTs, MARS_JOINs, or MARS_LEAVEs. This VC is used by the 663 MARS to return MARS_MULTI messages. It has an associated idle timer, 664 and is dismantled if not used for a configurable period of time. The 665 minimum suggested value for this time is 1 minute, and the 666 RECOMMENDED default is 20 minutes. 668 The second signalling path is ClusterControlVC. Every endpoint 669 registered as a cluster member is added as a leaf node to this VC, 670 which exists for the lifetime of the MARS. It is used to re- 671 distribute MARS_JOIN and MARS_LEAVE messages received by the MARS 672 from individual cluster members. Registration with the MARS as a 673 cluster member occurs when an endpoint issues a MARS_JOIN for a 674 protocol specific multicast group address. Once this occurs the 675 endpoint is added as a leaf node to ClusterControlVC. 677 In IPv4 environments the 'all nodes' Class D address of 224.0.0.1 is 678 used to register with the MARS. RFC 1112 requires that all hosts 679 (including routers) that wish to participate in Level 2 IP 680 multicasting must explicitly issue a JoinLocalGroup for group 681 224.0.0.1 when they initialise (Level 1 is not supported by this 682 memo). The JoinLocalGroup to 224.0.0.1 will result in an MARS_JOIN 683 being transmitted from the host to the MARS. 685 If an IPv4 endpoint issues a LeaveLocalGroup for 224.0.0.1 it will 686 also be considered to have ceased membership of all other groups for 687 which it may have joined. The MARS MUST flush that endpoint's ATM 688 address from any Class D address entries it appears in. Finally, the 689 endpoint is released as a Leaf node from ClusterControlVC. 691 If the MARS receives an ERR_L_RELEASE on ClusterControlVC indicating 692 that a cluster member has died, that member's ATM address MUST be 693 removed from all groups for which it may have joined. 695 Registration of endpoints for other protocols is currently beyond the 696 scope of this document. 698 7. Endpoint management of point to multipoint VCs. 700 Once a cluster member has established a new VC to the members 701 returned in a MARS_MULTI response it must: 703 Monitor traffic on ClusterControlVC for updates to the group's 704 membership. 706 Revalidate a group's membership if a leaf node releases itself 707 from the VC. 709 7.1 Monitoring updates on ClusterControlVC. 711 When a cluster member joins or leaves a particular multicast group it 712 is not sufficient to simply update the mapping table in the cluster's 713 MARS. Endpoints that are already transmitting to the multicast 714 group's members must be informed of the change so they may add or 715 remove a leaf node as appropriate. Cluster members track MARS_JOIN 716 and MARS_LEAVE messages retransmitted by the MARS to determine when 717 another endpoint joins or leaves a group or block of groups. 719 If a MARS_JOIN is seen that refers to (or encompasses) a group for 720 which the transmit side already has a VC open, the new member's ATM 721 address is extracted and an L_MULTI_ADD issued locally. This ensures 722 that hosts already sending to a given group will immediately add the 723 new member to their list of recipients. It also ensures that routers 724 joining a 'block' of groups are added by all endpoints currently 725 sending to groups within the block. 727 If a MARS_LEAVE is seen that refers to (or encompasses) a group for 728 which the transmit side already has a VC open, the old member's ATM 729 address is extracted and an L_MULTI_DROP issued locally. This ensures 730 that hosts already sending to a given group will immediately drop the 731 old member from their list of recipients. 733 In an IPv4 environment any endpoint leaving 224.0.0.1 is assumed to 734 be ceasing support for IP multicast operation. If a MARS_LEAVE is 735 seen that refers to group 224.0.0.1 then the ATM address of the 736 endpoint specified in the message MUST be removed from every 737 multipoint VC on which it is listed as a leaf node. 739 The transmit side of the interface MUST NOT shut down an active VC to 740 a group for which the receive side has just executed a 741 LeaveLocalGroup. This behaviour is consistent with the model of 742 hosts transmitting to groups regardless of their own membership 743 status. 745 If a MARS_JOIN or MARS_LEAVE arrives with ar$pnum == 0 it carries no 746 pairs, and is only used for validation as described in 747 section 10. 749 7.2 Revalidating when leaf nodes drop themselves. 751 During the life of a multipoint VC an ERR_L_RELEASE may be received 752 indicating that a leaf node has terminated its participation at the 753 ATM level. The ATM endpoint associated with the ERR_L_RELEASE MUST be 754 removed from the locally held set {ATM.1, ATM.2, .... ATM.n} 755 associated with the VC. 757 After a random period of time between 1 and 10 seconds the endpoint 758 MUST revalidate the associated group's membership by re-issuing a 759 MARS_REQEUEST. The returned set of members {NewATM.1, NewATM.2, .... 760 NewATM.n} is compared with the set already held locally. 761 L_MULTI_DROPs are issued on the group's VC for each node that appears 762 in the original set of members but not in the revalidated set of 763 members. L_MULTI_ADDs are issued on the group's VC for each node that 764 appears in the revalidated set of members but not in the original set 765 of members. 767 8. Configuring for Multicast Servers or Multicast Meshes. 769 Endpoint's assume that all groups are supported by meshes of point to 770 multipoint VCs. Under certain circumstances the consumption of VCs 771 and AAL resources around the cluster can make meshes unattractive, 772 despite their performance advantages. The MARS protocol provides a 773 mechanism for introducing multicast servers on a per-multicast group 774 basis, and in a manner that is completely transparent to cluster 775 members. 777 The multicast server has two key roles: 779 Providing one (or a limited number of) leaf nodes for outgoing VCs 780 from cluster members. 782 Constructing a single point to multipoint VC, with each group 783 memember as a leaf. This reduces the AAL consumption to one per 784 group, rather than one per sender per group. 786 The MARS must keep two sets of mappings for each multicast group 787 address supported by multicast servers. The original {multicast 788 address, ATM.1, ATM.2, ... ATM.n} mapping (the 'host map', although 789 it includes routers) is augmented by a parallel {multicast address, 790 server.1, server.2, .... server.K} mapping (the 'server map'). It is 791 assumed that no ATM addresses appear in both the server and host maps 792 for the same multicast group. Typically K will be 1, but it will be 793 larger when multiple multicast servers are configured to share the 794 data load of a given group. 796 When the MARS receives a MARS_REQUEST for a multicast address that 797 has both host and server maps it generates a response based on the 798 identity of the request's source. If the requestor is a member of the 799 server map for the requested group then the MARS returns the contents 800 of the host map in a sequence of one or more MARS_MULTIs. Otherwise 801 the MARS returns the contents of the server map in a sequence of one 802 or more MARS_MULTIs. Servers use the host map to establish a basic 803 distribution VC for the group. Cluster members will establish 804 outgoing multipoint VCs to members of the group's server map, without 805 being aware that their packets will not be going directly the 806 multicast group's members. 808 The MARS also maintains a point to multipoint VC out to any multicast 809 servers it is aware of, called ServerControlVC. This serves an 810 analogous role to ClusterControlVC, allowing the MARS to update the 811 servers with group membership changes as they occur. 813 A set of four MARS messages cover the current requirements: 815 MARS_MSERV Register as multicast server for one or more 816 groups. 817 MARS_UNSERV Deregister as multicast server for one or more 818 groups. 819 MARS_SJOIN A JOIN message on ServerControlVC. 820 MARS_SLEAVE A LEAVE message on ServerControlVC. 822 MARS_SJOIN/SLEAVE are identical in format to MARS_JOIN/LEAVE, but 823 have different operation codes so that a node acting as both a 824 cluster member and multicast server may distinguish between updates 825 arriving on ServerControlVC and ClusterControlVC. 827 8.1 Registering and deregistering multicast servers. 829 MARS_MSERV and MARS_UNSERV are identical to the MARS_JOIN message. 830 MARS_MSERV uses the set {, , ...., } to 831 specify one or more sets of multicast groups that a multicast server 832 is willing to support. MARS_UNSERV indicates the set of groups that 833 the multicast server is no longer willing to support. The operation 834 code for MARS_MSERV is 11 (decimal), and MARS_UNSERV is 17 (decimal). 836 When a node registers with MARS_MSERV the MARS adds the new ATM 837 address to the server maps for each specified group, possibly 838 constructing a new server map if this is the first multicast server 839 for the group. If the multicast server is not already a leaf node of 840 ServerControlVC it is added. 842 When a node deregisters with MARS_UNSERV the MARS removes its ATM 843 address from the server maps for each specified group, deleting the 844 server map if this was the only server for the group. 846 Both of these messages are sent to the MARS over a point to point VC, 847 and echoed on ServerControlVC by the MARS (section 10 covers the use 848 of this behaviour). The operation code is then changed to MARS_JOIN 849 or MARS_LEAVE respectively, and a copy of the original message is 850 transmitted on ClusterControlVC. 852 The MARS retransmits but otherwise ignores redundant MARS_MSERV and 853 MARS_UNSERV messages. 855 It is assumed that at least one server will have registered to 856 support a group before the first cluster member joins it. If a 857 MARS_MSERV arrives for a group that has a non-null host map but no 858 server map the default response of the MARS will be to drop the 859 MARS_MSERV without any further action. The originating multicast 860 server will eventually flag an error when repeated attempts to 861 register fail. 863 The opposite situation is where the last or only multicast server for 864 a group deregisters itself while the group still has members. The 865 default solution is for multicast servers to sever all VCs to which 866 they are attached as leaf nodes when they deregister, forcing any 867 active senders to the group to revalidate (as described in section 868 7). Since the MARS will have deleted the server map, the 869 revalidation will result in the host map being return, and the group 870 reverts to being a mesh. This shall be the default mechanism until 871 future work develops a more elegant approach. 873 Appendix C discusses possible extensions to allow dynamic transitions 874 between mesh and multicast server support while a group is active. 875 However, these are not required for conformance with this memo. 877 8.2 Handling group membership changes. 879 The existence of multicast servers supporting some groups but not 880 others requires the MARS to intervene in the distribution of single 881 and block join/leave updates to cluster members. The MARS_SJOIN and 882 MARS_SLEAVE messages are identical to MARS_JOIN, with operation codes 883 18 and 19 (decimal) respectively. They exist to allow a node 884 combining cluster member and multicast server to distinguish between 885 information arriving on ClusterControlVC and ServerControlVC. 887 When a cluster member issues MARS_JOIN or MARS_LEAVE for a single 888 group, the MARS checks to see if the group has an associated server 889 map. 891 If the specified group does not have a server map the MARS_JOIN or 892 MARS_LEAVE is retransmitted on ClusterControlVC. 894 If it does have a server map two transmissions occur: 896 A copy is made with type MARS_SJOIN or MARS_SLEAVE as appropriate 897 and transmitted on ServerControlVC. This allows the server(s) 898 supporting the group to note the new member and add it as a leaf 899 node. 901 The original message's ar$pnum field is set to 0, and it is 902 transmitted back using the VC it arrived on (rather than 903 ClusterControlVC). 905 (Section 10 requires cluster members have a mechanism to confirm the 906 reception of their message by the MARS. For mesh supported groups, 907 using ClusterControlVC serves dual purpose of providing this 908 confirmation and distributing group update information. When using 909 multicast servers there is no reason for having all cluster members 910 process and discard null join/leave messages on ClusterControlVC). 912 Receipt of a block join/leave (e.g. from a router coming on-line) 913 requires a more complex response. Cluster members must be directly 914 informed of which mesh supported groups the block covers. Multicast 915 servers must also be informed in case they support one of the groups 916 covered by the block being joined. 918 The solution is for the MARS to 'punch holes' in the block of 919 addresses supplied in the join/leave message, creating a set of 920 pairs that excludes those addresses/groups supported by the 921 multicast servers. This hole-punched set is then sent out on 922 ClusterControlVC, ensuring the router is immediately noted by senders 923 to any mesh supported groups in the block. The original 924 MARS_JOIN/LEAVE is then converted to a MARS_SJOIN/SLEAVE and 925 transmitted on ServerControlVC. Appendix A discusses some algorithms 926 for 'hole punching'. 928 If punching holes in the originally specified block leaves a null 929 set, the ar$pnum field is set to zero before sending the modified 930 MARS_JOIN/LEAVE on ClusterControlVC. 932 8.3 Multicast server architectures. 934 Specification of multicast server architectures, and the 935 synchronisation of multiple multicast servers supporting single 936 multicast groups, is beyond the scope of this document and is 937 expected to be the subject of further work. Appendix C discusses some 938 possible approaches. 940 9. Utilizing blocks for for multicast routers. 942 Multicast routers are required for the propagation of multicast 943 traffic beyond the constraints of a single cluster. There is a sense 944 in which they are multicast servers acting at the next higher layer, 945 with clusters rather than individual endpoints as their abstract 946 sources and destinations. 948 Multicast routers typically participate in higher layer multicast 949 routing algorithms and policies that are beyond the scope of this 950 memo (e.g. DVMRP [5] in the IPv4 environment). 952 It is assumed that the multicast routers will be implemented over the 953 same sort of IP/ATM interface that a multicast host would use. They 954 will use the basic services described in the preceeding sections to 955 join and leave multicast groups as necessary, and will register with 956 the MARS as a cluster member. 958 The rest of this section will assume a simple IPv4 scenario where the 959 scope of a cluster has been limited to a particular LIS that is part 960 of an overlaid IP network. Not all members of the LIS are necessarily 961 registered cluster members. 963 9.1 Sending to a Group. 965 If the multicast router needs to transmit a packet to a group within 966 the cluster it opens a VC in the same manner as a normal host would. 967 Once a VC is open, the router watches for MARS_JOIN and MARS_LEAVE 968 messages and responds to them as a normal host would. 970 The multicast router's transmit side MUST implement inactivity timers 971 to shut down idle outgoing VCs, as for normal hosts. 973 As with normal host, the multicast router does not need to be a 974 member of a group it is sending to. 976 9.2 Promiscuously Joining Groups. 978 Once registered and initialised, the simplest model of IPv4 multicast 979 router operation is for it to issue a MARS_JOIN encompassing the 980 entire Class D address space. In effect it becomes 'promiscuous', as 981 it will be a leaf node to all present and future multipoint VCs 982 established to IPv4 groups on the cluster. 984 How a router chooses which groups to propagate outside the cluster is 985 beyond the scope of this memo. 987 Consistent with RFC 1112, IP multicast routers may retain the use of 988 IGMP Query and IGMP Report messages to ascertain group membership. 990 9.3 Forward Multicast Traffic Across the cluster. 992 Under some circumstances the cluster may simply be another hop 993 between IP subnets that have participants in a multicast group. 995 [LAN.1] ----- IPmcR.1 -- [LIS] -- IPmcR.2 ----- [LAN.2] 997 LAN.1 and LAN.2 are subnets (such as Ethernet) with attached hosts 998 that are members of group X. 1000 IPmcR.1 and IPmcR.2 are multicast routers with interfaces to the LIS. 1002 A traditional solution would be to treat the LIS as a unicast subnet, 1003 and use tunneling routers. However, this would not allow hosts on the 1004 LIS to participate in the cross-LIS traffic. 1006 Assume IPmcR.1 is receiving packets promiscuously on its LAN.1 1007 interface. Assume further it is configured to propagate multicast 1008 traffic to all attached interfaces. In this case that means the LIS. 1010 When a packet for group X arrives on its LAN.1 interface, IPmcR.1 1011 simply sends the packet to group X on the LIS interface as a normal 1012 host would (Issuing MARS_REQUEST for group X, creating the VC, 1013 sending the packet). 1015 Assuming IPmcR.2 initialised itself with the MARS as a member of the 1016 entire Class D space, it will have been returned as a member of X 1017 even if no other nodes on the LIS were members. All packets for group 1018 X received on IPmcR.2's LIS interface may be retransmitted on LAN.2. 1020 If IPmcR.1 is similarly initialised the reverse process will apply 1021 for multicast traffic from LAN.2 to LAN.1, for any multicast group. 1022 The benefit of this scenario is that cluster members within the LIS 1023 may also join and leave group X at anytime. 1025 9.4 Restricted 'promiscous' Operation. 1027 Both unicast and multicast IP routers have a common problem - 1028 limitations on the number of AAL contexts available at their ATM 1029 interfaces. Being 'promiscuous' in the RFC 1112 sense means that for 1030 every M hosts sending to N groups, a multicast router's ATM interface 1031 will have M*N incoming reassembly engines tied up. 1033 It is not hard to envisage situations where a number of multicast 1034 groups are active within the LIS but are not required to be 1035 propagated beyond the LIS itself. An example might be a distributed 1036 simulation system specifically designed to use the high speed IP/ATM 1037 environment. There may be no practical way its traffic could be 1038 utilised on 'the other side' of the multicast router, yet under the 1039 conventional scheme the router would have to be a leaf to each 1040 participating host anyway. 1042 As this problem occurs at the link layer, it is worth noting that 1043 'scoping' mechanisms at the IP multicast routing level do not provide 1044 a solution. 1046 In this situation the network administrator might configure their 1047 multicast routers to exclude sections of the Class D address space 1048 when issuing MARS_JOIN(s). Multicast groups that will never be 1049 propagated beyond the cluster will not have the router listed as a 1050 member by the MARS, and the router will never have to receive and 1051 ignore traffic from those groups. 1053 Another scenario involves the product M*N exceeding the capacity of a 1054 single router's interface (especially if the same interface must also 1055 support a unicast IP router service). 1057 A network administrator may choose to add a second node, to function 1058 as a parallel IP multicast router. Each router would be configured to 1059 be 'promiscuous' over separate parts of the Class D address space, 1060 thus exposing themselves to only part of the VC load. This sharing 1061 would be completely transparent to IP hosts within the LIS. 1063 Restricted promiscuous mode does not break RFC 1112's use of IGMP 1064 Report messages. If the router is configured to serve a given block 1065 of Class D addresses, it will receive the IGMP Report. If the router 1066 is not configured to support a given block, then the existence of an 1067 IGMP Report for a group in that block is irrelevant to the router. 1068 All routers are able to track membership changes through the 1069 MARS_JOIN and MARS_LEAVE traffic anyway. 1071 Mechanisms for establishing these modes of operation are beyond the 1072 scope of this memo. 1074 10. Robustness of interaction with the MARS. 1076 Transient problems may result in the loss of messages between the 1077 MARS, cluster members, and multicast servers. More serious problems 1078 may result in the failure of the MARS itself. There are two problem 1079 scenarios that are addressed. The first is the inability of a cluster 1080 member to send messages to the MARS itself, either through cell loss 1081 on the VC to the MARS, or the cluster member's inability to establish 1082 a VC to the MARS. 1084 The second is with the MARS_JOIN/SJOIN/LEAVE/SLEAVE messages re- 1085 transmitted from the MARS. If a cluster member or multicast server 1086 currently sending to a group misses an join update, the newly joined 1087 member misses out on some traffic to the group. If a cluster member 1088 or multicast server currently sending to a group misses a leave 1089 update, the cluster member that left will continue to receive packets 1090 unecessarily. 1092 10.1 Ensuring the MARS hears you. 1094 A simple algorithm solves the first problem. Cluster members 1095 retransmit MARS_JOIN and MARS_LEAVE messages at regular intervals 1096 until they receive a copy back again, either on ClusterControlVC or 1097 the VC on which they are sending the messages. At this point the 1098 local endpoint can be certain that at least the MARS received it. 1100 Multicast servers retransmit MARS_MSERV and MARS_UNSERV messages at 1101 regular intervals until they receive a copy back on ServerControlVC. 1103 The interval should be no shorter than 5 seconds, and a default value 1104 of 10 seconds is recommended. After 5 retransmissions the attempt 1105 should be flagged locally as a failure. This should be considered as 1106 a MARS failure, and handled as described in section 10.2. 1108 A 'copy' is defined as seeing a message of the same operation code 1109 containing the local host's identity in the source address fields. 1110 The pair set is not checked, and does not have to be the 1111 same (this is required so that cluster members may verify a MARS_JOIN 1112 they've sent even if the MARS's hole-punching creates a totally 1113 different set of pairs). 1115 10.2 Temporary failure of the MARS. 1117 Two failure modes indicate problems with the MARS itself: 1119 If an ERR_L_RELEASE occurs for the cluster member's attachment to 1120 ClusterControlVC it may be assumed some problem exists with the 1121 MARS. 1123 If the cluster member receives ERR_L_RQFAILED when it attempts to 1124 establish a point to point VC to the MARS in order to send MARS 1125 messages. 1127 The cluster member should wait a random period of time between 1 and 1128 10 seconds before attempting to re-register with the MARS. If the 1129 registration MARS_JOIN is successful (in accordance with section 1130 10.1) then: 1132 The cluster member MUST then proceed to rejoin every group that 1133 its local higher layer protocol(s) have joined. It is recommended 1134 that a random delay between 1 and 10 seconds be inserted before 1135 the transmission of each MARS_JOIN. 1137 Finally, using the mechanism described in section 7, the cluster 1138 member MUST begin revalidating every multicast group it was 1139 sending to. 1141 The rejoin and revalidation procedure must not disrupt the cluster 1142 member's use of multipoint VCs that were already open at the time 1143 of the MARS failure. 1145 If the re-registration with the Primary MARS fails, and there is no 1146 configured Secondary MARS, the cluster member MUST wait for at least 1147 1 minute before repeating the re-registration procedure. It is 1148 RECOMMENDED that the cluster member signals an error condition in 1149 some locally significant fashion. 1151 If the re-registration with the Primary MARS fails, and a Secondary 1152 MARS has been configured, the Secondary and Primary MARS addresses 1153 are swapped and the cluster member immediately repeats the re- 1154 registration procedure. If this is succesful the cluster member will 1155 resume normal operation using the Secondary MARS. It is RECOMMENDED 1156 that the cluster member signals a warning of this condition in some 1157 locally significant fashion. 1159 If the attempt at re-registration with the Secondary MARS fails, the 1160 cluster member MUST wait for at least 1 minute before reverting back 1161 to the Primary MARS and starting the whole re-registration process 1162 over again. In the worst case scenario this will result in cluster 1163 members looping between registration attempts with the Primary MARS 1164 and Secondary MARS until network administrators manually intervene. 1166 Multicast servers shall behave in a similar manner to cluster members 1167 on this issue. 1169 10.3 The MARS Sequence Number. 1171 There is an unsigned 32 bit sequence number identified as ar$msn in 1172 most MARS messages. The following extensions govern its use: 1174 The MARS keeps two independent counters, Cluster Sequence Number 1175 (CSN) and Server Sequence Number (SSN). They are incremented every 1176 time a message is sent out ClusterControlVC or ServerControlVC 1177 respectively. 1179 [Editorial note - in ipmc-03.txt the counter was incremented 1180 only when a change occurred in the mapping tables. this is a 1181 simplification.] 1183 The current CSN is copied into the ar$msn field of MARS messages 1184 being sent to cluster members (either out ClusterControlVC or on 1185 an individual VC). 1187 The current SSN is copied into the ar$msn field of MARS messages 1188 being sent to multicast servers (either out ServerControlVC or on 1189 an individual VC). 1191 Cluster members and multicast servers track the increments of CSN 1192 or SSN to determine if they have missed any update messages. 1194 Calculations on the sequence numbers MUST be performed as unsigned 32 1195 bit arithmetic, to ensure no glitches when the counters roll over. 1197 Every cluster member keeps its own 32 bit Host Sequence Number (HSN) 1198 to track the MARS's sequence number. Whenever a MARS_MULTI, 1199 MARS_JOIN, or MARS_LEAVE is received the following check is then 1200 performed on the ar$msn field of the new message: 1202 Seq.diff = ar$msn - HSN 1203 ar$msn -> HSN 1204 {...process MARS message as appropriate...} 1206 if ((Seq.diff != 1) && (Seq.diff != 0)) 1207 then {...revalidate group membership information...} 1209 The basic result is that the cluster member attempts to keep locked 1210 in step with membership changes noted by the MARS. If it ever detects 1211 that a membership change occurred (in any group) without it noticing, 1212 it re-validates the membership of all groups it currently has 1213 multicast VCs open to. Revalidation involves treating each VC as 1214 though an ERR_L_RELEASE was received from a leaf node, and executing 1215 the procedure described in section 7. 1217 The ar$msn field of consecutive MARS_MULTIs sent in response to a 1218 MARS_REQUEST must be constant. If the ar$msn field changes then all 1219 the messages MUST be discarded at the completion of the response, and 1220 the MARS_REQUEST re-issued. 1222 One implication of this mechanism is that the MARS should serialize 1223 its processing of 'simultaneous' MARS_REQUEST, MARS_JOIN and 1224 MARS_LEAVE messages. Join and Leave operations should be queued 1225 within the MARS along with MARS_REQUESTS, and not processed until all 1226 the reply packets of a preceeding MARS_REQUEST have been transmitted. 1228 The MARS is free to choose a value of CSN and SSN. When a new cluster 1229 member starts up it should initialise HSN to zero. When the cluster 1230 member sends the MARS_JOIN to register, the HSN will be correctly set 1231 when it receives a copy of its MARS_JOIN from the MARS. If Seq.diff > 1232 1 when the MARS_JOIN returns no action will be taken anyway, as the 1233 host will not have any multicast related VCs established at this 1234 stage. 1236 If a sequence number jump occurs when establishing a new group's VC 1237 the cluster member should not revalidate the membership of the group 1238 it just established. The membership returned in the MARS_MULTIs that 1239 carried the new ar$msn field should be considered already validated. 1241 A MARS should be carefully designed to minimise the possibility of 1242 CSN or SSN jumping unecessarily. Under normal operation only hosts 1243 that are affected by transient link problems will miss ar$msn updates 1244 and be forced to revalidate. If the MARS itself glitches it will be 1245 innundated with requests for a period as every cluster member 1246 attempts to revalidate. 1248 Multicast servers should utilize the ar$msn fields in exactly the 1249 same manner as cluster members. This will enable them to track the 1250 SSN, and recover from missing any MARS_SJOIN/SLEAVE traffic. 1252 10.4 Why a Gobal sequence number? 1254 The CSN and SSN are global within the context of a given protocol 1255 (e.g. IP). They count ClusterControlVC and ServerControlVC activity 1256 without reference to the multicast group(s) involved. This may be 1257 perceived as a limitation, because there is no way for cluster 1258 members or multicast servers to isolate exactly which multicast group 1259 they may have missed an update for. An alternative was to try and 1260 provide a per-group sequence number. 1262 Unfortunately per-group sequence numbers are not practical. The 1263 current mechanism allows sequence information to be piggy-backed onto 1264 MARS messages already in transit for other reasons. The ability to 1265 specify blocks of multicast addresses with a single MARS_JOIN or 1266 MARS_LEAVE means that a single message can refer to membership change 1267 for multiple groups simultaneously. A single ar$msn field cannot 1268 provide meaningful information about each group's sequence. Multiple 1269 ar$msn fields would have been unwieldy. 1271 Any MARS or cluster member that supports different protocols MUST 1272 keep separate mapping tables and sequence numbers for each protocol. 1274 10.5 Synchronizing the Primary and Secondary MARS. 1276 If a Secondary MARS exists for a given cluster then some mechanism is 1277 needed to ensure reasonable consistency between its mapping tables 1278 and those of the Primary MARS, especially as cluster members will 1279 only ever register with one MARS. The inter-server protocol also 1280 needs to cope with post-failure situations where some cluster members 1281 end up registered with the Primary and others with the Secondary. 1283 The definition of an inter-server protocol is beyond the current 1284 scope of this document, and is expected to be the subject of further 1285 work in the area. 1287 11. Using the MARS in non-IP environments. 1289 An deliberate attempt has been made to describe the MARS and 1290 associated mechanisms in a manner independent of a specific higher 1291 layer protocol being run over the ATM cloud. The immediate 1292 application of this document will be in an IPv4 environment, and this 1293 is reflected by the focus of key examples. However, the coding of 1294 each MARS message means that any higher layer protocol identifiable 1295 by a two byte Ethernet Type code can be supported by a MARS. 1297 The 16 bit 'Protocol type' at the start of each MARS message, taken 1298 from the set of Ethernet Type codes. Every MARS MUST implement 1299 entirely separate logical mapping tables and support. Every cluster 1300 member must interpret messages from the MARS in the context of the 1301 protocol type that the MARS message refers to. 1303 The LLC/SNAP encapsulation specified in section 4 should not be 1304 considered a hinderance in non-IP environments. Experimenters 1305 deploying IPX or AppleTalk over ATM are encouraged to use the 1306 architecture described in this document to support possible multicast 1307 needs. 1309 12. Key Decisions and open issues. 1311 The key decisions this memo proposes: 1313 A Multicast Address Resolution Server (MARS) is proposed to co- 1314 ordinate and distribute mappings of ATM endpoint addresses to 1315 arbitrary higher layer 'multicast group addresses'. The specific 1316 case of IP version 4 multicast is used as the example. 1318 Individual multicast groups may be supported by multicast meshes 1319 between group members, or by multicast servers. The concept of 1320 'clusters' is introduced to define the scope of a MARS's 1321 responsibility, and the set of ATM endpoints willing to 1322 participate in link level multicasting. 1324 MARS message formats and encapsulation allow co-resident MARS and 1325 ATM ARP Server implementations. 1327 New message types: MARS_JOIN, MARS_LEAVE, MARS_REQUEST. Allow 1328 endpoints to join, leave, and request the current membership list 1329 of multicast groups. 1331 New message type: MARS_MULTI. Allows multiple ATM addresses to be 1332 returned by the MARS in response to a MARS_REQUEST. 1334 New message types: MARS_MSERV, MARS_UNSERV. Allow multicast 1335 servers to register and deregister themselves with the MARS. 1337 New message types: MARS_SJOIN, MARS_SLEAVE. Allow MARS to pass on 1338 group membership changes to multicast servers. 1340 'wild card' MARS mapping table entries possible, where a single 1341 ATM address is simultaneously associated with blocks of multicast 1342 group addresses. 1344 Some issues have not been addressed, although they may be in future 1345 revisions. 1347 MARS has no mechanism for realising cluster members have silently 1348 died. 1350 The future development of ATM Group Addresses and Leaf Initiated 1351 Join to ATM Forum's UNI specification has not been addressed. The 1352 problems identified in this memo with respect to VC scarcity and 1353 impact on AAL contexts will not be fixed by such developments in 1354 the signalling protocol. 1356 Security Consideration 1358 Security consideration are not addressed in this memo. 1360 Acknowledgments 1362 The discussions within the IP over ATM Working Group have helped 1363 clarify the ideas expressed in this document. John Moy of Cascade 1364 Communications Corp. initially suggested the idea of wild-card 1365 entries in the ARP Server. Drew Perkins of Fore Systems provided 1366 rigorous and useful critique of early proposed mechanisms for 1367 distributing and validating group membership information. Susan 1368 Symington (and co-workers at MITRE Corp., Don Chirieleison, Rich 1369 Verjinski, and Bill Barns) clearly articulated the need for multicast 1370 server support, proposed a solution, and challenged earlier block 1371 join/leave mechanisms. 1373 Author's Address 1375 Grenville Armitage 1376 MRE 2P340, 445 South Street 1377 Morristown, NJ, 07960-6438 1378 USA 1380 Email: gja@thumper.bellcore.com 1382 References 1383 [1] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 1384 Standford University, August 1989. 1386 [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption 1387 Layer 5", RFC 1483, USC/Information Science Institute, July 1993. 1389 [3] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett- 1390 Packard Laboratories, December 1993 1392 [4] ATM Forum, "ATM User-Network Interface Specification Version 1393 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993 1395 [5] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast 1396 Routing Protocol", RFC 1075, November 1988. 1398 [6] M. Perez, F. Liaw, D. Grossman, A. Mankin, E. Hoffman, A. Malis, 1399 "ATM Signaling Support for IP over ATM", Internet Draft, IP over ATM 1400 Working Group, draft-ietf-ipatm-sig-02.txt, November, 1994. 1402 Appendix A. Parsing MARS messages. 1404 Implementations are entirely free to comply with the body of this 1405 memo in any way they see fit. This appendix is purely for 1406 clarification. 1408 A smart MARS implementation will pre-construct a set of 1409 pairs (P) that reflects the entire Class D space, excluding any 1410 addresses currently supported by multicast servers. The field 1411 of the first pair MUST be 224.0.0.0, and the field of the last 1412 pair MUST be 239.255.255.255. The first and last pair may be the 1413 same. This set is updated whenever a multicast server registers or 1414 deregisters. 1416 When the MARS must perform 'hole punching' it might consider the 1417 following algorithm: 1419 Assume the MARS_JOIN/LEAVE received by the MARS from the cluster 1420 member specied the block . 1422 Assume Pmin(N) and Pmax(N) are the and fields from the 1423 Nth pair in the MARS's current set P. 1425 Assume set P has K pairs. Pmin(1) MUST equal 224.0.0.0, and 1426 Pmax(M) MUST equal 239.255.255.255. (If K == 1 then no hole 1427 punching is required). 1429 Execute pseudo-code: 1431 create copy of set P, call it set C. 1433 index1 = 1; 1434 while (Pmax(index1) <= Emin) 1435 index1++; 1437 index2 = K; 1438 while (Pmin(index2) >= Emax) 1439 index2--; 1441 if (Pmin(index1) < Emin) 1442 Cmin(index1) = Emin; 1444 if (Pmax(index2) > Emax) 1445 Cmax(index2) = Emax; 1447 Set C is the required 'hole punched' set of address blocks. 1449 The resulting set C retains all the MARS's pre-constructed 'holes' 1450 covering the multicast servers, but will have been pruned to cover 1451 the section of the Class D space specified by the originating host's 1452 values. 1454 The host end should keep a table, H, of open VCs in ascending order 1455 of Class D address. 1457 Assume H(x).addr is the Class address associated with VC.x. 1458 Assume H(x).addr < H(x+1).addr. 1460 The pseudo code for updating VCs based on an incoming JOIN/LEAVE 1461 might be: 1463 x = 1; 1464 N = 1; 1466 while (x < no.of VCs open) 1467 { 1468 while (H(x).addr > max(N)) 1469 { 1470 N++; 1471 if (N > no. of pairs in JOIN/LEAVE) 1472 return(0); 1473 } 1475 if ((H(x).addr <= max(N) && 1476 ((H(x).addr >= min(N)) 1477 perform_VC_update(); 1478 x++; 1479 } 1481 Appendix B. Coping with IPv4 idiosyncracies. 1483 Implementing any part of this appendix is not required for 1484 conformance with this memo. It is provided solely to document issues 1485 that have been identified. 1487 The intent of section 5.3 is for cluster members to only have 1488 outgoing point to multipoint VCs when they are actually sending data 1489 to a particular multicast groups. However, in most IPv4 environments 1490 the multicast routers attached to a cluster will periodically issue 1491 IGMP Queries to ascertain if particular groups have members. The 1492 current IGMP specification attempts to avoid having every group 1493 member respond by insisting that each group member wait a random 1494 period, and responding if no other member has responded before them. 1495 The IGMP reply is sent to the multicast address of the group being 1496 queried. 1498 Unfortunately, as it stands the IGMP algorithm will be a nuisance for 1499 cluster members that are essentially passive receivers within a given 1500 multicast group. It is just as likely that a passive member, with no 1501 outgoing VC already established to the group, will decide to send an 1502 IGMP reply - causing a VC to be established were there was no need 1503 for one. This is not a fatal problem for small clusters, but will 1504 seriously impact on the ability of a cluster to scale. 1506 Various solutions exist, providing short and long term solutions to 1507 the problem. One long term solution would be to modify the IGMP 1508 algorithm, for example: 1510 If the group member has VC open to the group proceed as per RFC 1511 1112 (picking a random reply delay between 0 and 10 seconds). 1513 If the group member does not have VC already open to the group, 1514 pick random reply delay between 10 and 20 seconds instead, and 1515 then proceed as per RFC 1112. 1517 If even one group member is sending to the group at the time the IGMP 1518 Query is issued then all the passive receivers will find the IGMP 1519 Reply has been transmitted before their delay expires, so no new VC 1520 is required. If all group members are passive at the time of the IGMP 1521 Query then a response will eventually arrive, but 10 seconds later 1522 than under conventional circumstances. 1524 The preceeding solution requires re-writing existing IGMP code, and 1525 implies the ability of the IGMP entity to ascertain the status of VCs 1526 on the underlying ATM interface. This is not likely to be available 1527 in the short term. 1529 One short term solution is to provide something like the preceeding 1530 functionality with a 'hack' at the IP/ATM driver level within cluster 1531 members. Arrange for the IP/ATM driver to snoop inside IP packets 1532 looking for IGMP traffic. If an IGMP packet is accepted for 1533 transmission, the IP/ATM driver can buffer it locally if there is no 1534 VC already active to that group. A 10 second timer is started, and if 1535 an IGMP Reply for that group is received from elsewhere on the 1536 cluster the timer is reset. If the timer expires, the IP/ATM driver 1537 then establishes a VC to the group as it would for a normal IP 1538 multicast packet. 1540 Some network implementors may find it advantageous to configure a 1541 multicast server to support the group 224.0.0.1, rather than rely on 1542 a mesh. Given that IP multicast routers regularly send IGMP queries 1543 to this address, a mesh will mean that each router will permanently 1544 consume an AAL context within each cluster member. In clusters served 1545 by multiple routers the VC load within switches in the underlying ATM 1546 network will become a scaling problem. 1548 Finally, if a multicast server is used to support 224.0.0.1, another 1549 ATM driver level hack becomes a possible solution to IGMP Reply 1550 traffic. The ATM driver may choose to grab all outgoing IGMP packets 1551 and send them out on the VC established for sending to 224.0.0.1, 1552 regardless of the Class D address the IGMP message was actually for. 1553 Given that all hosts and routers must be members of 224.0.0.1, the 1554 intended recipients will still receive the IGMP Replies. The negative 1555 impact is that all cluster members will receive the IGMP Replies. 1557 Appendix C. Issues relating to multicast servers. 1559 Implementing any part of this appendix is not required for 1560 conformance with this memo. It is provided to give some structure to 1561 further research and development on multicast server support within 1562 clusters. 1564 Various items are not addressed by this memo. They include: 1566 Automatic migration of cluster members from a mesh to a multicast 1567 server while a group is active. 1569 An elegant mechanism for migration of cluster members from 1570 multicast servers back to a mesh while the group is active. 1572 Additional intelligence in the MARS to perform load sharing 1573 between multicast servers if more than one registers for the same 1574 group. 1576 If one or more multicast servers attempt to register for a group that 1577 already has members, it would be nice to have current senders to the 1578 group migrate their outgoing VCs from the actual cluster members to 1579 the newly registered multicast server(s). One approach might be to 1580 have the MARS issue a sequence of fabricated MARS_JOINs for the 1581 multicast servers, followed by MARS_LEAVEs for each member of the 1582 group's current host map. What load this would place on the MARS, and 1583 its scalability, have not been considered. 1585 An elegant mechanism for the reverse migration might well be based 1586 around the reverse process. Issue MARS_JOINs for all entries in the 1587 host map, then issue MARS_LEAVEs for all remaining entries in the 1588 server map. 1590 In case of groups served by multiple multicast servers, the current 1591 expectation is that each server retrieves the entire group's 1592 membership with MARS_REQUESTs. This memo expects there to be an 1593 external mechanism for multiple multicast servers to synchronize the 1594 load sharing amongst themselves. Whether the MARS should to be 1595 extended to play a part is a subject for further work. 1597 An issue not immediately related to the MARS architecture is whether 1598 a multicast server retransmits using a point to multipoint VC out to 1599 group members, or a set of one VC per group member. The first 1600 approach makes better use of the underlying ATM fabric, but data 1601 sources that are also members of the group will receive copies of 1602 their own traffic back. The alternative avoids this problem, but at 1603 the expense of consuming more VCs and bandwidth on the path out of 1604 the multicast server itself. 1606 Situations where either issue is a problem should simply revert to 1607 using a multicast mesh between participating endpoints, where the 1608 source never sees copies of its own packets, and the multicasting 1609 happens within the ATM switch fabrics.