rfc2226.txt

RFC 的详细文档！

   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: [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.