doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc2226.txt b/doc/rfc/rfc2226.txt
new file mode 100644
index 0000000..335d972
--- /dev/null
+++ b/doc/rfc/rfc2226.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                           T. Smith
+Request for Comments: 2226                               IBM Corporation
+Category: Standards Track                                    G. Armitage
+                                                     Lucent Technologies
+                                                            October 1997
+
+
+                     IP Broadcast over ATM Networks
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+Abstract
+
+   This memo describes how the IP multicast service being developed by
+   the IP over ATM working group may be used to support IP broadcast
+   transmission. The solution revolves around treating the broadcast
+   problem as a special case of multicast, where every host in the
+   subnet or cluster is a member of the group.
+
+   An understanding of the services provided by RFC 2022 is assumed.
+
+1.  Introduction.
+
+
+   The IETF's first step in solving the problems of running IP over
+   Asynchronous Transfer Mode (ATM) technology is described in RFC 1577
+   [1].  It provides for unicast communication between hosts and routers
+   within Logical IP Subnets (LISs), and proposes a centralized ATM ARP
+   Server which provides IP to ATM address resolution services to LIS
+   members.
+
+   Two classes of IP service were omitted - multicast and broadcast
+   transmissions. Multicasting allows a single transmit operation to
+   cause a packet to be received by multiple remote destinations.
+
+
+
+
+
+
+Smith & Armitage            Standards Track                     [Page 1]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+   Broadcasting typically allows a single transmit operation to cause a
+   packet to be received by all IP hosts that are members of a
+   particular 'subnet'.
+
+   To address the need for multicast support (represented by
+   transmission to IP addresses in the Class D space), RFC 2022
+   ("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2] was
+   created.  This memo creates an analog of the RFC 1577 ARP Server - a
+   new entity known as the MARS (Multicast Address Resolution Server).
+   The MARS operates as a centralized registry and distribution
+   mechanism for mappings between IP multicast addresses and groups of
+   ATM unicast addresses. Host behavior is also defined for establishing
+   and managing point to multipoint VCs, based on the information
+   returned by the MARS, when hosts wish to transmit packets to a
+   multicast group.
+
+   This memo aims to show how RFC 2022 may be used to emulate IP
+   broadcast within Logical IP Subnets. While the broadcast technique
+   does not align itself well with the underlying point-to-point nature
+   of ATM, clearly, some applications will still wish to use IP
+   broadcasts.  Client-server applications where the client searches for
+   a server by sending out a broadcast is one scenario.  Routing
+   protocols, most notably RIP, are other examples.
+
+2.  Review of Unicast and Multicast.
+
+   Both the unicast and multicast cases take advantage of the point-to-
+   point and point-to-multipoint capabilities defined in the ATM Forum
+   UNI 3.1 document [4].  A unicast IP address has a single ATM level
+   destination.  Unicast transmissions occur over point to point Virtual
+   Channels (VCs) between the source and destination. The ARP Server
+   holds mappings between IP destination addresses and their associated
+   ATM destination address. Hosts issue an ARP_REQUEST to the ARP Server
+   when they wish to ascertain a particular mapping.  The ARP Server
+   replies with either an ARP_REPLY containing the ATM address of the
+   destination, or an ARP_NAK when the ARP Server is unable to resolve
+   the address. If the request is successful the host establishes a VC
+   to the destination interface. This VC is then used to forward the
+   first (and subsequent) packets to that particular IP destination. RFC
+   1577 describes in further detail how hosts are administratively
+   grouped in to Logical IP Subnets (LISs), and how the ARP Server
+   establishes the initial mappings for members of the LIS it serves.
+
+   The basic host behavior for multicasting is similar - the sender must
+   establish and manage a point to multipoint VC whose leaf nodes are
+   the group's actual members. Under UNI 3.1 these VCs can only be
+   established and altered by the source (root) interface.
+
+
+
+
+Smith & Armitage            Standards Track                     [Page 2]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+   The MARS is an evolution of the ARP Server model, and performs two
+   key functions.  The first function is the maintenance of a list of
+   ATM addresses corresponding to the members for each group.  This list
+   is created by a host registration process which involves two messages
+   - a MARS_JOIN which declares that a host wishes to join the specified
+   group(s), and a MARS_LEAVE which indicates that a host wishes to
+   leave the specified group(s).
+
+   MARS_JOIN and MARS_LEAVE messages are also redistributed to all
+   members of the group so that active senders may dynamically adjust
+   their point to multipoint VCs accordingly.
+
+   The other major function is the retrieval of group membership from
+   MARS (analogous to the ARP Server providing unicast address
+   mappings). When faced with the need to transmit an IP packet with a
+   Class D destination address, a host issues a MARS_REQUEST to the
+   MARS. If the group has members the MARS returns a MARS_MULTI
+   (possibly in multiple segments) carrying a set of ATM addresses. The
+   host then establishes an initial point to multipoint VC using these
+   ATM addresses as the leaf nodes. If the MARS had no mapping it would
+   return a MARS_NAK.
+
+   (RFC 2022 also discusses how the MARS can arrange for Class D groups
+   to be supported by either multicast servers, or meshes of point to
+   multipoint VCs from host to host.  However, from the host's
+   perspective this is transparent, and is not central to this
+   discussion of IP broadcast support.)
+
+   This memo describes how a host may utilize the registration and group
+   management functions in an existing MARS based IP/ATM network to
+   emulate IP broadcasts.
+
+3.  Broadcast as a special case of Multicast.
+
+   Many of the problems that occur when implementing a broadcast
+   solution also occur in when implementing a multicast solution.  In
+   fact, broadcast may be considered a special case of multicast.  That
+   is, broadcast is a multicast group whose members include all members
+   in the LIS.
+
+   There are two broadcast groups which this memo addresses:
+
+      1) 255.255.255.255 - "All ones" broadcast
+
+      2) x.z - CIDR-prefix (subnet) directed broadcast
+
+
+
+
+
+
+Smith & Armitage            Standards Track                     [Page 3]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+   Broadcast (1) is sometimes referred to as a limited broadcast to this
+   physical network.  Broadcast (2) can be thought of as the the
+   broadcast for subnets or networks in the old paradigm. As described
+   in [6] and [7], the notion of subnets and networks is being replaced
+   with a more efficient utilization of the routing address space known
+   as Classless Inter-Domain Routing.  The CIDR-prefix (x) is the
+   combination of IP address and subnet mask that denotes the subnet
+   number.  The host portion of the address (z) is all ones.  One should
+   note that while these broadcasts have different scopes at the IP or
+   network layer, they have precisely the same scope at the link layer
+   -- namely that all members of the LIS will receive a copy.
+
+   These addresses may be used in two environments:
+
+      o  Broadcasting to all members of a given LIS where
+         a priori knowledge of a host's IP address and
+         subnet mask are known (e.g. the CIDR-prefix directed
+         broadcast).
+
+      o  Broadcasting to all members of a physical network
+         without knowledge of a host's IP address and
+         subnet mask (e.g. the all ones broadcast).
+
+   On a broadcast medium like Ethernet, these two environments result in
+   the same physical destination.  That is, all stations on that network
+   will receive the broadcast even if they are on different logical
+   subnets, or are non-IP stations.  With ATM, this may not be the case.
+   Because ATM is non-broadcast, a registration process must take place.
+   And if there are stations that register to some broadcast groups, but
+   not others, then the different broadcast groups will have different
+   memberships.  The notion of broadcast becomes inconsistent.
+
+   One case that requires the use of the all ones broadcast is that of
+   the diskless boot, or bootp client, where the host boots up, and does
+   not know its own IP address or subnet mask.  Clearly, the host does
+   not know which subnet it belongs to.   So, to send a broadcast to its
+   bootp server, the diskless workstation must use the group which
+   contains no subnet information, i.e. the 255.255.255.255 broadcast
+   group.  Carrying the example a little further, the bootp server,
+   after receiving the broadcast, can not send either a directed frame
+   nor a subnet directed broadcast to respond to the diskless
+   workstation.  Instead, the bootp server must also use the
+   255.255.255.255 group to communicate with the client.
+
+   While the all ones broadcast is required at the IP layer, it also has
+   relevance at the link layer when deciding which broadcast group to
+   register with in MARS.  In other words, a bootp client wishing to
+   register for a link layer broadcast, can only register for
+
+
+
+Smith & Armitage            Standards Track                     [Page 4]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+   255.255.255.255 in the MARS address space because the client's subnet
+   is unknown at the time.  Given that some applications must use the
+   all ones address in MARS for their broadcast group, and that we wish
+   to minimize the number of broadcast groups used by LIS members, the
+   all ones group in MARS MUST be used by all members of the LIS when
+   registering to receive broadcast transmissions.  The VCC used for
+   transmitting any broadcast packet will be based on the members
+   registered in the MARS under the 255.255.255.255 address position.
+   This VCC will be referred to as the "broadcast channel" through the
+   remainder of this memo.
+
+4.  The MARS role in broadcast.
+
+   Many solutions have been proposed, some of which are listed in
+   Appendix A.  This memo addresses a MARS solution which appears to do
+   the best job of solving the broadcast problem.
+
+   There are a number of characteristics of the MARS architecture that
+   should be kept intact.  They include:
+
+   o  MARS contains no knowledge of subnet prefixes and subnet masks.
+      Each group address registered with MARS is managed independently.
+
+   o  A MARS may only serve one LIS. This insures that the
+      broadcast group 255.255.255.255 is joined by hosts from one
+      LIS, keeping its scope bound to conventional interpretation.
+
+   o  The Multicast Server (MCS) described in [2] may be used to service
+      the broadcast groups defined in this memo without modification.
+      The MCS will reduce the number of channels used by the network.
+
+   The MARS needs no additional code or special algorithms to handle the
+   resolution of IP broadcast addresses. It is simply a general database
+   that holds {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings, and
+   imposes no constraints on the type and length of the 'Protocol
+   address'. Whether the hosts view it as Class D or 'broadcast' (or
+   even IP) is purely a host side issue.
+
+   It is likely that end points will want to use the IP broadcast
+   emulation described here in order to support boot time location of
+   the end point's IP address. This leads to the observation that the
+   MARS should NOT expect to see both the IP source and ATM source
+   address fields of the MARS_JOIN filled in.  This is reasonable, since
+   only the ATM source address is used when registering the end point as
+   a group member.
+
+   The MARS architecture is sufficient to insure the integrity of the
+   broadcast group list without any modification.
+
+
+
+Smith & Armitage            Standards Track                     [Page 5]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+5.  Host Requirements for Broadcast.
+
+   The following list of bullets describes additional characteristics of
+   a MARS-compliant host.  These characteristics are required to take
+   advantage of the broadcast function.
+
+   o  A host must register as a MARS client.
+
+   o  A host, soon after registration MUST issue a MARS_JOIN to the
+      all ones broadcast address (i.e. 255.255.255.255) with the
+      mar$flags.layer3grp reset.
+
+   o  When transmitting packets, the host should map all IP layer
+      broadcasts to the VCC (broadcast channel) created and maintained
+      based on the all ones entry in MARS.
+
+   o  A host MUST monitor the MARS_JOIN/MARS_LEAVE messages
+      for 255.255.255.255 to keep the broadcast channel current.
+
+   o  A broadcast channel should be torn down after a period of
+      inactivity.  The corresponding timeout period MAY be specified
+      with a minimum value of one minute, and a RECOMMENDED
+      default value of 20 minutes.
+
+   One should note that while every member participating in the
+   broadcast MUST be a member of the all ones group, not all members
+   will choose to transmit broadcast information.  Some members will
+   only elect to receive broadcast information passively.  Therefore, in
+   a LIS with n stations, there may be less than n channels terminated
+   at each station for broadcast information.  Further reductions may be
+   gained by adding a Multicast Server (MCS) to the broadcast
+   environment which could reduce the number of VCs to two (one
+   incoming, one outgoing), or one for a station that only wishes to
+   listen.
+
+   It is well understood that broadcasting in this environment may tax
+   the resources of the network and of the hosts that use it.
+   Therefore, an implementer MAY choose to provide a mechanism for
+   retracting the host's entry in the broadcast group after it has been
+   established or prior to joining the group.  The MARS_LEAVE is used to
+   request withdrawal from the group if the host wishes to disable
+   broadcast reception after it has joined the group.  The default
+   behavior SHALL be to join the all ones broadcast group in MARS.
+
+
+
+
+
+
+
+
+Smith & Armitage            Standards Track                     [Page 6]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+6.  Implications of IP broadcast on ATM level resources.
+
+   RFC 2022 discusses some of the implications of large multicast groups
+   on the allocation of ATM level resources, both within the network and
+   within end station ATM interfaces.
+
+   The default mechanism is for IP multicasting to be achieved using
+   meshes of point to multipoint VCs, direct from source host to group
+   members. Under certain circumstances system administrators may, in a
+   manner completely transparent to end hosts, redirect multicast
+   traffic through ATM level Multicast Servers (MCSs). This may be
+   performed on an individual group basis.
+
+   It is sufficient to note here that the IP broadcast 'multicast group'
+   will constitute the largest consumer of VCs within your ATM network
+   when it is active. For this reason it will probably be the first
+   multicast group to have one or more ATM MCSs assigned to support it.
+   However, there is nothing unique about an MCS assigned to support IP
+   broadcast traffic, so this will not be dealt with further in this
+   memo. RFC 2022 contains further discussion on the possible
+   application of multiple MCSs to provide fault-tolerant architectures.
+
+7.  Further discussion.
+
+   A point of discussion on the ip-atm forum revolved around "auto
+   configuration" and "diskless boot".  This memo describes a broadcast
+   solution that requires the use of the MARS.  Therefore, at a minimum,
+   the ATM address of the MARS must be manually configured into a
+   diskless workstation.  Suggestions such as universal channel numbers,
+   and universal ATM addresses have been proposed, however, no agreement
+   has been reached.
+
+   Another topic for discussion is multiprotocol support.  MARS is
+   designed for protocol independence.  This memo specifically addresses
+   the IP broadcast case, identifying which addresses are most effective
+   in the IP address space.  However, the principles apply to any layer
+   3 protocol.  Further work should be performed to identify suitable
+   addresses for other layer 3 protocols.
+
+   Finally, there has been support voiced for a link layer broadcast
+   that would be independent of the layer 3 protocol.  Such a solution
+   may provide a simpler set of rules through which broadcast
+   applications may be used.  In addition, some solutions also provide
+   for more efficient use of VCCs.
+
+
+
+
+
+
+
+Smith & Armitage            Standards Track                     [Page 7]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+Security Considerations
+
+   This memo addresses a specific use of the MARS architecture and
+   components to provide the broadcast function.  As such, the security
+   implications are no greater or less than the implications of using
+   any of the other multicast groups available in the multicast address
+   range.  Should enhancements to security be required, they would need
+   to be added as an extension to the base architecture in RFC 2022.
+
+Acknowledgments
+
+   The apparent simplicity of this memo owes a lot to the services
+   provided in [2], which itself is the product of much discussion on
+   the IETF's IP-ATM working group mailing list.  Grenville Armitage
+   worked on this document while at Bellcore.
+
+References
+
+   [1]  Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
+        December 1993.
+
+   [2]  Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
+        Networks", RFC 2022, November 1995.
+
+   [3]  Deering, S., "Host Extensions for IP Multicasting", STD 5,
+        RFC 1112, August 1989.
+
+   [4]  ATM Forum, "ATM User-Network Interface Specification Version
+        3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
+
+   [5]  Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E. and
+        A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
+        February 1995.
+
+   [6]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
+        Domain Routing (CIDR): an Address Assignment and Aggregation
+        Strategy", RFC 1519, September 1993.
+
+   [7]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
+        June 1995.
+
+   [8]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels, BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+Smith & Armitage            Standards Track                     [Page 8]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+Authors' Addresses
+
+   Timothy J. Smith
+   Network Routing Systems,
+   International Business Machines Corporation.
+   N21/664
+   P.O.Box 12195
+   Research Triangle Park, NC 27709
+
+   Phone: (919) 254-4723
+   EMail: tjsmith@vnet.ibm.com
+
+
+   Grenville Armitage
+   Bell Labs, Lucent Technologies.
+   101 Crawfords Corner Rd,
+   Holmdel, NJ, 07733
+
+   EMail: gja@lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Armitage            Standards Track                     [Page 9]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+Appendix A.  Broadcast alternatives
+
+   Throughout the development of this memo, there have been a number of
+   alternatives explored and discarded for one reason or another.  This
+   appendix documents these alternatives and the reason that they were
+   not chosen.
+
+A.1  ARP Server Broadcast Solutions.
+
+   The ARP Server is a good candidate to support broadcasting.  There is
+   an ARP Server for every LIS.  The ARP Server contains the entire LIS
+   membership.  These are fundamental ingredients for the broadcast
+   function.
+
+A.1.1  Base Solution without modifications to ARP Server.
+
+   One may choose as an existing starting point to use only what is
+   available in RFC 1577.  That is, a host can easily calculate the
+   range of members in its LIS based on its own IP address and subnet
+   mask.  The host can then issue an ARP Request for every member of the
+   LIS.  With this information, the host can then set up point-to-point
+   connections with all members, or can set up a point-to-multipoint
+   connection to all members.  There you have it, the poor man's
+   broadcast.
+
+   While this solution is very straight forward, it suffers from a
+   number of problems.
+
+   o  The load on the ARP Server is very large.  If all stations on
+      a LIS choose to implement broadcasting, the initial surge of ARP
+      Requests will be huge.  Some sort of slow start sequence would be
+      needed.
+
+   o  The amount of resource required makes this a non-scalable
+      solution.  The authors believe that broadcasting will require an
+      MCS to reduce the number of channel resources required to support
+      each broadcast 'group'.  Using the ARP Server in this manner does
+      not allow an MCS to be transparently introduced. (Basic RFC1577
+      interfaces also do not implement the extended LLC/SNAP
+      encapsulation required to safely use more than one MCS).
+
+   o  The diskless boot solution can not function in this environment
+      because it may be unable to determine which subnet to which it
+      belongs.
+
+
+
+
+
+
+
+Smith & Armitage            Standards Track                    [Page 10]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+A.1.2  Enhanced ARP Server solution.
+
+   This solution is similar to the base solution except that it takes
+   some of the (MARS) multicast solution and embeds it in the ARP
+   Server.  The first enhancement is to add the MARS_MULTI command to
+   the set of opcodes that the ARP Server supports.  This would allow a
+   host to issue a single request, and to get back the list of members
+   in one or more MARS_REPLY packets.  Rather than have a registration
+   mechanism, the ARP Server could simply use the list of members that
+   have already been registered.  When a request comes in for the subnet
+   broadcast address, the ARP Server would aggregate the list, and send
+   the results to the requester.
+
+   This suffers from two drawbacks.
+
+   1)  Scalability with regard to number of VCs is still an issue.
+       One would eventually need to add in some sort of multicast
+       server solution to the ARP Server.
+
+   2)  The diskless boot scenario is still broken.  There is no
+       way for a station to perform a MARS_MULTI without first
+       knowing its IP address and subnet mask.
+
+   The diskless boot problem could be solved by adding to the ARP Server
+   a registration process where anyone could register to the
+   255.255.255.255 address.  These changes would make the ARP Server
+   look more and more like MARS.
+
+A.2  MARS Solutions.
+
+   If we wish to keep the ARP Server constant as described in RFC 1577,
+   the alternative is to use the Multicast Address Resolution Server
+   (MARS) described in [2].
+
+   MARS has three nice features for broadcasting.
+
+   1)  It has a generalized registration approach which allows
+       for any address to have a group of entities registered.
+       So, if the subnet address is not known, a host can
+       register for an address that is known (e.g. 255.255.255.255).
+
+   2)  The command set allows for lists of members to be passed
+       in a single MARS_MULTI packet.   This reduces traffic.
+
+   3)  MARS contains an architecture for dealing with the
+       scalability issues.  That is, Multicast Servers (MCSs)
+       may be used to set up the point-to-multipoint channels
+
+
+
+
+Smith & Armitage            Standards Track                    [Page 11]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+       and reduce the number of channels that a host needs to
+       set up to one.  Hosts wishing to broadcast will instead
+       send the packet to the MCS who will then forward it to
+       all members of the LIS.
+
+A.2.1.  CIDR-prefix (Subnet) Broadcast solution.
+
+   One of the earliest solutions was to simply state that broadcast
+   support would be implemented by using a single multicast group in the
+   class D address space -- namely, the CIDR-prefix (subnet) broadcast
+   address group.  All members of a LIS would be required to register to
+   this address, and use it as required.  A host wishing to use either
+   the 255.255.255.255 broadcast, or the network broadcast addresses
+   would internally map the VC to the subnet broadcast VC.  The all ones
+   and network broadcast addresses would exist on MARS, but would be
+   unused.
+
+   The problem with this approach goes back to the diskless workstation
+   problem.  Because the workstation may not know which subnet it
+   belongs to, it doesn't know which group to register with.
+
+A.2.2.  All one's first, subnet broadcast second
+
+   This solution acknowledges that the diskless boot problem requires a
+   generic address (one that does not contain CIDR-prefix (subnet)
+   information) to register with and to use until subnet knowledge is
+   known.  In essence, all stations first register to the
+   255.255.255.255 group, then as they know their subnet information,
+   they could optionally de-register from the all one's group and
+   register to the CIDR-prefix (subnet) broadcast group.
+
+   This solution would appear to solve a couple of problems:
+
+   1)  The bootp client can function if the server remains
+       registered to the all one's group continuously.
+
+   2)  There will be less traffic using the all ones group
+       because the preferred transactions will be on the
+       subnet broadcast channel.
+
+   Unfortunately the first bullet contains a flaw.  The server must
+   continually be registered to two groups -- the all ones group and the
+   subnet broadcast group.  If this server has multiple processes that
+   are running different IP applications, it may be difficult for the
+   link layer to know which broadcast VC to use.  If it always uses the
+   all ones, then it will be missing members that have removed
+   themselves from the all ones and have registered to the subnet
+   broadcast.  If it always uses the subnet broadcast group, the
+
+
+
+Smith & Armitage            Standards Track                    [Page 12]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+   diskless boot scenario gets broken.  While making the decision at the
+   link layer may require additional control flows be built into the
+   path, it may also require the rewriting of application software.
+
+   In some implementations, a simple constant is used to indicate to the
+   link layer that this packet is to be transmitted to the broadcast
+   "MAC" address.  The assumption is that the physical network broadcast
+   and the logical protocol broadcast are one and the same.  As pointed
+   out earlier, this is not the case with ATM.  Therefore applications
+   would need to specifically identify the subnet broadcast group
+   address to take advantage of the smaller group.
+
+   These problems could be solved in a number of ways, but it was
+   thought that they added unnecessarily to the complexity of the
+   broadcast solution.
+
+Appendix B.  Should MARS Be Limited to a Single LIS?
+
+   RFC 2022 explicitly states that a network administrator MUST ensure
+   that each LIS is served by a separate MARS, creating a one-to-one
+   mapping between cluster and a unicast LIS.  But, it also mentions
+   that relaxation of this restriction MAY occur after future research
+   warrants it.  This appendix discusses some to the potential
+   implications to broadcast should this restriction be removed.
+
+   The most obvious change would be that the notion of a cluster would
+   span more than one LIS.  Therefore, the broadcast group of
+   255.255.255.255 would contain members from more than one LIS.
+
+   It also should be emphasized that the one LIS limitation is not a
+   restriction of the MARS architecture.  Rather, it is only enforced if
+   an administrator chooses to do so.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Armitage            Standards Track                    [Page 13]
+
+RFC 2226             IP Broadcast over ATM Networks         October 1997
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published
+   andand distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Armitage            Standards Track                    [Page 14]
+