idnits 2.17.1 draft-ietf-ion-bcast-05.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-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (October 14, 1997) is 9683 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 362, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1577 (ref. '1') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1519 (ref. '6') (Obsoleted by RFC 4632) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Timothy J. Smith 3 IBM Corporation 4 Grenville Armitage 5 Lucent Technologies 6 October 14, 1997 8 IP Broadcast over ATM Networks 9 11 Status of this Memo 13 This document was submitted to the IETF Internetworking Over NBMA 14 Working Group (ion). Publication of this document does not imply 15 acceptance by the Internetworking Over NBMA Working Group of any 16 ideas expressed within. Comments should be submitted to the 17 ion@nexen.com mailing list. 19 Distribution of this memo is unlimited. 21 This memo is an internet draft. Internet Drafts are working documents 22 of the Internet Engineering Task Force (IETF), its Areas, and its 23 Working Groups. Note that other groups may also distribute working 24 documents as Internet Drafts. 26 To learn the current status of any Internet-Draft, please check the 27 "lid-abstracts.txt" listing contained in the Internet-Drafts shadow 28 directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119. 36 Abstract 38 This memo describes how the IP multicast service being developed by 39 the IP over ATM working group may be used to support IP broadcast 40 transmission. The solution revolves around treating the broadcast 41 problem as a special case of multicast, where every host in the 42 subnet or cluster is a member of the group. 44 An understanding of the services provided by RFC 2022 is assumed. 46 1. Introduction. 48 The IETF's first step in solving the problems of running IP over 49 Asynchronous Transfer Mode (ATM) technology is described in RFC 1577 50 [1]. It provides for unicast communication between hosts and routers 51 within Logical IP Subnets (LISs), and proposes a centralized ATM ARP 52 Server which provides IP to ATM address resolution services to LIS 53 members. 55 Two classes of IP service were omitted - multicast and broadcast 56 transmissions. Multicasting allows a single transmit operation to 57 cause a packet to be received by multiple remote destinations. 58 Broadcasting typically allows a single transmit operation to cause a 59 packet to be received by all IP hosts that are members of a 60 particular 'subnet'. 62 To address the need for multicast support (represented by 63 transmission to IP addresses in the Class D space), RFC 2022 64 ("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2] was 65 created. This draft creates an analog of the RFC 1577 ARP Server - a 66 new entity known as the MARS (Multicast Address Resolution Server). 67 The MARS operates as a centralized registry and distribution 68 mechanism for mappings between IP multicast addresses and groups of 69 ATM unicast addresses. Host behavior is also defined for establishing 70 and managing point to multipoint VCs, based on the information 71 returned by the MARS, when hosts wish to transmit packets to a 72 multicast group. 74 This memo aims to show how RFC 2022 may be used to emulate IP 75 broadcast within Logical IP Subnets. While the broadcast technique 76 does not align itself well with the underlying point-to-point nature 77 of ATM, clearly, some applications will still wish to use IP 78 broadcasts. Client-server applications where the client searches for 79 a server by sending out a broadcast is one scenario. Routing 80 protocols, most notably RIP, are other examples. 82 2. Review of Unicast and Multicast. 84 Both the unicast and multicast cases take advantage of the point-to- 85 point and point-to-multipoint capabilities defined in the ATM Forum 86 UNI 3.1 document [4]. A unicast IP address has a single ATM level 87 destination. Unicast transmissions occur over point to point Virtual 88 Channels (VCs) between the source and destination. The ARP Server 89 holds mappings between IP destination addresses and their associated 90 ATM destination address. Hosts issue an ARP_REQUEST to the ARP Server 91 when they wish to ascertain a particular mapping. The ARP Server 92 replies with either an ARP_REPLY containing the ATM address of the 93 destination, or an ARP_NAK when the ARP Server is unable to resolve 94 the address. If the request is successful the host establishes a VC 95 to the destination interface. This VC is then used to forward the 96 first (and subsequent) packets to that particular IP destination. RFC 97 1577 describes in further detail how hosts are administratively 98 grouped in to Logical IP Subnets (LISs), and how the ARP Server 99 establishes the initial mappings for members of the LIS it serves. 101 The basic host behavior for multicasting is similar - the sender must 102 establish and manage a point to multipoint VC whose leaf nodes are 103 the group's actual members. Under UNI 3.1 these VCs can only be 104 established and altered by the source (root) interface. 106 The MARS is an evolution of the ARP Server model, and performs two 107 key functions. The first function is the maintenance of a list of 108 ATM addresses corresponding to the members for each group. This list 109 is created by a host registration process which involves two messages 110 - a MARS_JOIN which declares that a host wishes to join the specified 111 group(s), and a MARS_LEAVE which indicates that a host wishes to 112 leave the specified group(s). 114 MARS_JOIN and MARS_LEAVE messages are also redistributed to all 115 members of the group so that active senders may dynamically adjust 116 their point to multipoint VCs accordingly. 118 The other major function is the retrieval of group membership from 119 MARS (analogous to the ARP Server providing unicast address 120 mappings). When faced with the need to transmit an IP packet with a 121 Class D destination address, a host issues a MARS_REQUEST to the 122 MARS. If the group has members the MARS returns a MARS_MULTI 123 (possibly in multiple segments) carrying a set of ATM addresses. The 124 host then establishes an initial point to multipoint VC using these 125 ATM addresses as the leaf nodes. If the MARS had no mapping it would 126 return a MARS_NAK. 128 (RFC 2022 also discusses how the MARS can arrange for Class D groups 129 to be supported by either multicast servers, or meshes of point to 130 multipoint VCs from host to host. However, from the host's 131 perspective this is transparent, and is not central to this 132 discussion of IP broadcast support.) 134 This memo describes how a host may utilize the registration and group 135 management functions in an existing MARS based IP/ATM network to 136 emulate IP broadcasts. 138 3. Broadcast as a special case of Multicast. 140 Many of the problems that occur when implementing a broadcast 141 solution also occur in when implementing a multicast solution. In 142 fact, broadcast may be considered a special case of multicast. That 143 is, broadcast is a multicast group whose members include all members 144 in the LIS. 146 There are two broadcast groups which this memo addresses: 148 1) 255.255.255.255 - "All ones" broadcast 150 2) x.z - CIDR-prefix (subnet) directed broadcast 152 Broadcast (1) is sometimes referred to as a limited broadcast to this 153 physical network. Broadcast (2) can be thought of as the the 154 broadcast for subnets or networks in the old paradigm. As described 155 in [6] and [7], the notion of subnets and networks is being replaced 156 with a more efficient utilization of the routing address space known 157 as Classless Inter-Domain Routing. The CIDR-prefix (x) is the 158 combination of IP address and subnet mask that denotes the subnet 159 number. The host portion of the address (z) is all ones. One should 160 note that while these broadcasts have different scopes at the IP or 161 network layer, they have precisely the same scope at the link layer 162 -- namely that all members of the LIS will receive a copy. 164 These addresses may be used in two environments: 166 o Broadcasting to all members of a given LIS where 167 a priori knowledge of a host's IP address and 168 subnet mask are known (e.g. the CIDR-prefix directed 169 broadcast). 171 o Broadcasting to all members of a physical network 172 without knowledge of a host's IP address and 173 subnet mask (e.g. the all ones broadcast). 175 On a broadcast medium like Ethernet, these two environments result in 176 the same physical destination. That is, all stations on that network 177 will receive the broadcast even if they are on different logical 178 subnets, or are non-IP stations. With ATM, this may not be the case. 179 Because ATM is non-broadcast, a registration process must take place. 180 And if there are stations that register to some broadcast groups, but 181 not others, then the different broadcast groups will have different 182 memberships. The notion of broadcast becomes inconsistent. 184 One case that requires the use of the all ones broadcast is that of 185 the diskless boot, or bootp client, where the host boots up, and does 186 not know its own IP address or subnet mask. Clearly, the host does 187 not know which subnet it belongs to. So, to send a broadcast to its 188 bootp server, the diskless workstation must use the group which 189 contains no subnet information, i.e. the 255.255.255.255 broadcast 190 group. Carrying the example a little further, the bootp server, 191 after receiving the broadcast, can not send either a directed frame 192 nor a subnet directed broadcast to respond to the diskless 193 workstation. Instead, the bootp server must also use the 194 255.255.255.255 group to communicate with the client. 196 While the all ones broadcast is required at the IP layer, it also has 197 relevance at the link layer when deciding which broadcast group to 198 register with in MARS. In other words, a bootp client wishing to 199 register for a link layer broadcast, can only register for 200 255.255.255.255 in the MARS address space because the client's subnet 201 is unknown at the time. Given that some applications must use the 202 all ones address in MARS for their broadcast group, and that we wish 203 to minimize the number of broadcast groups used by LIS members, the 204 all ones group in MARS MUST be used by all members of the LIS when 205 registering to receive broadcast transmissions. The VCC used for 206 transmitting any broadcast packet will be based on the members 207 registered in the MARS under the 255.255.255.255 address position. 208 This VCC will be referred to as the "broadcast channel" through the 209 remainder of this memo. 211 4. The MARS role in broadcast. 213 Many solutions have been proposed, some of which are listed in 214 Appendix A. This memo addresses a MARS solution which appears to do 215 the best job of solving the broadcast problem. 217 There are a number of characteristics of the MARS architecture that 218 should be kept intact. They include: 220 o MARS contains no knowledge of subnet prefixes and subnet masks. 221 Each group address registered with MARS is managed independently. 223 o A MARS may only serve one LIS. This insures that the 224 broadcast group 255.255.255.255 is joined by hosts from one 225 LIS, keeping its scope bound to conventional interpretation. 227 o The Multicast Server (MCS) described in [2] may be used to service 228 the broadcast groups defined in this memo without modification. 229 The MCS will reduce the number of channels used by the network. 231 The MARS needs no additional code or special algorithms to handle the 232 resolution of IP broadcast addresses. It is simply a general database 233 that holds {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings, and 234 imposes no constraints on the type and length of the 'Protocol 235 address'. Whether the hosts view it as Class D or 'broadcast' (or 236 even IP) is purely a host side issue. 238 It is likely that end points will want to use the IP broadcast 239 emulation described here in order to support boot time location of 240 the end point's IP address. This leads to the observation that the 241 MARS should NOT expect to see both the IP source and ATM source 242 address fields of the MARS_JOIN filled in. This is reasonable, since 243 only the ATM source address is used when registering the end point as 244 a group member. 246 The MARS architecture is sufficient to insure the integrity of the 247 broadcast group list without any modification. 249 5. Host Requirements for Broadcast. 251 The following list of bullets describes additional characteristics of 252 a MARS-compliant host. These characteristics are required to take 253 advantage of the broadcast function. 255 o A host must register as a MARS client. 257 o A host, soon after registration MUST issue a MARS_JOIN to the 258 all ones broadcast address (i.e. 255.255.255.255) with the 259 mar$flags.layer3grp reset. 261 o When transmitting packets, the host should map all IP layer 262 broadcasts to the VCC (broadcast channel) created and maintained 263 based on the all ones entry in MARS. 265 o A host MUST monitor the MARS_JOIN/MARS_LEAVE messages 266 for 255.255.255.255 to keep the broadcast channel current. 268 o A broadcast channel should be torn down after a period of 269 inactivity. The corresponding timeout period MAY be specified 270 with a minimum value of one minute, and a RECOMMENDED 271 default value of 20 minutes. 273 One should note that while every member participating in the 274 broadcast MUST be a member of the all ones group, not all members 275 will choose to transmit broadcast information. Some members will 276 only elect to receive broadcast information passively. Therefore, in 277 a LIS with n stations, there may be less than n channels terminated 278 at each station for broadcast information. Further reductions may be 279 gained by adding a Multicast Server (MCS) to the broadcast 280 environment which could reduce the number of VCs to two (one 281 incoming, one outgoing), or one for a station that only wishes to 282 listen. 284 It is well understood that broadcasting in this environment may tax 285 the resources of the network and of the hosts that use it. 286 Therefore, an implementer MAY choose to provide a mechanism for 287 retracting the host's entry in the broadcast group after it has been 288 established or prior to joining the group. The MARS_LEAVE is used to 289 request withdrawal from the group if the host wishes to disable 290 broadcast reception after it has joined the group. The default 291 behavior SHALL be to join the all ones broadcast group in MARS. 293 6. Implications of IP broadcast on ATM level resources. 295 RFC 2022 discusses some of the implications of large multicast groups 296 on the allocation of ATM level resources, both within the network and 297 within end station ATM interfaces. 299 The default mechanism is for IP multicasting to be achieved using 300 meshes of point to multipoint VCs, direct from source host to group 301 members. Under certain circumstances system administrators may, in a 302 manner completely transparent to end hosts, redirect multicast 303 traffic through ATM level Multicast Servers (MCSs). This may be 304 performed on an individual group basis. 306 It is sufficient to note here that the IP broadcast 'multicast group' 307 will constitute the largest consumer of VCs within your ATM network 308 when it is active. For this reason it will probably be the first 309 multicast group to have one or more ATM MCSs assigned to support it. 310 However, there is nothing unique about an MCS assigned to support IP 311 broadcast traffic, so this will not be dealt with further in this 312 memo. RFC 2022 contains further discussion on the possible 313 application of multiple MCSs to provide fault-tolerant architectures. 315 7. Further discussion. 317 A point of discussion on the ip-atm forum revolved around "auto 318 configuration" and "diskless boot". This memo describes a broadcast 319 solution that requires the use of the MARS. Therefore, at a minimum, 320 the ATM address of the MARS must be manually configured into a 321 diskless workstation. Suggestions such as universal channel numbers, 322 and universal ATM addresses have been proposed, however, no agreement 323 has been reached. 325 Another topic for discussion is multiprotocol support. MARS is 326 designed for protocol independence. This memo specifically addresses 327 the IP broadcast case, identifying which addresses are most effective 328 in the IP address space. However, the principles apply to any layer 329 3 protocol. Further work should be performed to identify suitable 330 addresses for other layer 3 protocols. 332 Finally, there has been support voiced for a link layer broadcast 333 that would be independent of the layer 3 protocol. Such a solution 334 may provide a simpler set of rules through which broadcast 335 applications may be used. In addition, some solutions also provide 336 for more efficient use of VCCs. 338 Security Considerations 340 This memo addresses a specific use of the MARS architecture and 341 components to provide the broadcast function. As such, the security 342 implications are no greater or less than the implications of using 343 any of the other multicast groups available in the multicast address 344 range. Should enhancements to security be required, they would need 345 to be added as an extension to the base architecture in RFC 2022. 347 Acknowledgments 349 The apparent simplicity of this memo owes a lot to the services 350 provided in [2], which itself is the product of much discussion on 351 the IETF's IP-ATM working group mailing list. Grenville Armitage 352 worked on this document while at Bellcore. 354 References 356 [1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, 357 Hewlett-Packard Laboratories, December 1993. 359 [2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM 360 Networks", RFC 2022, November 1995. 362 [3] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 363 Stanford University, August 1989. 365 [4] ATM Forum, "ATM User-Network Interface Specification Version 366 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993. 368 [5] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., 369 Malis, A., "ATM Signaling Support for IP over ATM", RFC 1755, 370 February 1995. 372 [6] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter- 373 Domain Routing (CIDR): an Address Assignment and Aggregation 374 Strategy", RFC 1519, September 1993. 376 [7] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 377 June 1995. 379 Author's Address 381 Timothy J. Smith 382 Network Routing Systems, 383 International Business Machines Corporation. 384 N21/664 385 P.O.Box 12195 386 Research Triangle Park, NC 27709 388 Phone: (919) 254-4723 389 EMail: tjsmith@vnet.ibm.com 391 Grenville Armitage 392 Bell Labs, Lucent Technologies. 393 101 Crawfords Corner Rd, 394 Holmdel, NJ, 07733 395 Email: gja@lucent.com 396 Appendix A. Broadcast alternatives 398 Throughout the development of this memo, there have been 399 a number of alternatives explored and discarded for one 400 reason or another. This appendix documents these alternatives 401 and the reason that they were not chosen. 403 A.1 ARP Server Broadcast Solutions. 405 The ARP Server is a good candidate to support broadcasting. There 406 is an ARP Server for every LIS. The ARP Server contains the entire 407 LIS membership. These are fundamental ingredients for the broadcast 408 function. 410 A.1.1 Base Solution without modifications to ARP Server. 412 One may choose as an existing starting point to use only what is 413 available in RFC 1577. That is, a host can easily calculate the 414 range of members in its LIS based on its own IP address and 415 subnet mask. The host can then issue an ARP Request for every 416 member of the LIS. With this information, the host can then 417 set up point-to-point connections with all members, or can set 418 up a point-to-multipoint connection to all members. There you have 419 it, the poor man's broadcast. 421 While this solution is very straight forward, it suffers from a number 422 of problems. 424 o The load on the ARP Server is very large. If all stations on 425 a LIS choose to implement broadcasting, the initial surge of 426 ARP Requests will be huge. Some sort of slow start sequence 427 would be needed. 429 o The amount of resource required makes this a non-scalable 430 solution. The authors believe that broadcasting will require 431 an MCS to reduce the number of channel resources 432 required to support each broadcast 'group'. Using the ARP 433 Server in this manner does not allow an MCS 434 to be transparently introduced. (Basic RFC1577 interfaces 435 also do not implement the extended LLC/SNAP encapsulation 436 required to safely use more than one MCS). 438 o The diskless boot solution can not function in this environment 439 because it may be unable to determine which subnet to which 440 it belongs. 442 A.1.2 Enhanced ARP Server solution. 444 This solution is similar to the base solution except that it 445 takes some of the (MARS) multicast solution and embeds it in the 446 ARP Server. The first enhancement is to add the MARS_MULTI 447 command 448 to the set of opcodes that the ARP Server supports. This would 449 allow a host to issue a single request, and to get back the 450 list of members in one or more MARS_REPLY packets. Rather 451 than have a registration mechanism, the ARP Server could simply 452 use the list of members that have already been registered. When 453 a request comes in for the subnet broadcast address, 454 the ARP Server would aggregate the list, and 455 send the results to the requester. 457 This suffers from two drawbacks. 459 1) Scalability with regard to number of VCs is still an issue. 460 One would eventually need to add in some sort of multicast 461 server solution to the ARP Server. 463 2) The diskless boot scenario is still broken. There is no 464 way for a station to perform a MARS_MULTI without first 465 knowing its IP address and subnet mask. 467 The diskless boot problem could be solved by adding to the 468 ARP Server a registration process where anyone could register 469 to the 255.255.255.255 address. These changes would make 470 the ARP Server look more and more like MARS. 472 A.2 MARS Solutions. 474 If we wish to keep the ARP Server constant as described in 475 RFC 1577, the alternative is to use the Multicast Address 476 Resolution Server (MARS) described in [2]. 478 MARS has three nice features for broadcasting. 480 1) It has a generalized registration approach which allows 481 for any address to have a group of entities registered. 482 So, if the subnet address is not known, a host can 483 register for an address that is known (e.g. 255.255.255.255). 485 2) The command set allows for lists of members to be passed 486 in a single MARS_MULTI packet. This reduces traffic. 488 3) MARS contains an architecture for dealing with the 489 scalability issues. That is, Multicast Servers (MCSs) 490 may be used to set up the point-to-multipoint channels 491 and reduce the number of channels that a host needs to 492 set up to one. Hosts wishing to broadcast will instead 493 send the packet to the MCS who will then forward it to 494 all members of the LIS. 496 A.2.1. CIDR-prefix (Subnet) Broadcast solution. 498 One of the earliest solutions was to simply state that broadcast 499 support would be implemented by using a single multicast group 500 in the class D address space -- 501 namely, the CIDR-prefix (subnet) broadcast address group. All 502 members of a LIS would 503 be required to register to this address, and use it as required. 504 A host wishing to use either the 255.255.255.255 broadcast, or the 505 network broadcast addresses would internally map the VC to the 506 subnet broadcast VC. The all ones and network broadcast addresses 507 would exist on MARS, but would be unused. 509 The problem with this approach goes back to the diskless workstation 510 problem. Because the workstation may not know which subnet it 511 belongs to, it doesn't know which group to register with. 513 A.2.2. All one's first, subnet broadcast second 515 This solution acknowledges that the diskless boot problem requires 516 a generic address (one that does not contain CIDR-prefix 517 (subnet) information) to 518 register with and to use until subnet knowledge is known. In essence, 519 all stations first register to the 255.255.255.255 group, then as 520 they know their subnet information, they could optionally de-register 521 from the all one's group and register to the CIDR-prefix (subnet) 522 broadcast group. 524 This solution would appear to solve a couple of problems: 526 1) The bootp client can function if the server remains 527 registered to the all one's group continuously. 529 2) There will be less traffic using the all ones group 530 because the preferred transactions will be on the 531 subnet broadcast channel. 533 Unfortunately the first bullet contains a flaw. The 534 server must continually be registered to two groups -- the all ones 535 group and the subnet broadcast group. If this server has multiple 536 processes that are running different IP applications, it may be 537 difficult for the link layer to know which broadcast VC to use. 538 If it always uses the all ones, then it will be missing members 539 that have removed themselves from the all ones and have registered 540 to the subnet broadcast. If it always uses the subnet broadcast 541 group, the diskless boot scenario gets broken. While making the 542 decision at the link layer may require additional control flows 543 be built into the path, it may also require the rewriting of 544 application software. 546 In some implementations, a simple constant is used to indicate 547 to the link layer that this packet is to be transmitted to the 548 broadcast "MAC" address. The assumption is that the physical 549 network broadcast and the logical protocol broadcast are one 550 and the same. As pointed out earlier, this is not the case 551 with ATM. Therefore applications would need to specifically 552 identify the subnet broadcast group address to take advantage 553 of the smaller group. 555 These problems could be solved in a number of ways, but it was 556 thought that they added unnecessarily to the complexity of the 557 broadcast solution. 559 Appendix B. Should MARS Be Limited to a Single LIS? 561 RFC 2022 explicitly states that a network administrator MUST 562 ensure that each LIS is served by a separate MARS, creating 563 a one-to-one mapping between cluster and a unicast LIS. 564 But, it also mentions that relaxation of this restriction MAY 565 occur after future research warrants it. This appendix discusses 566 some to the potential implications to broadcast should this 567 restriction be removed. 569 The most obvious change would be that the notion of a cluster 570 would span more than one LIS. Therefore, the broadcast group of 571 255.255.255.255 would contain members from more than one LIS. 573 It also should be emphasized that the one LIS limitation 574 is not a restriction of the MARS architecture. Rather, 575 it is only enforced if an administrator chooses to do so.