rfc2226.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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: [phone]
   EMail: [e-mail]


   Grenville Armitage
   Bell Labs, Lucent Technologies.
   101 Crawfords Corner Rd,
   Holmdel, NJ, 07733

   EMail: [e-mail]
































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]