home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2226 < prev    next >
Text File  |  1997-10-28  |  31KB  |  788 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           T. Smith
  8. Request for Comments: 2226                               IBM Corporation
  9. Category: Standards Track                                    G. Armitage
  10.                                                      Lucent Technologies
  11.                                                             October 1997
  12.  
  13.  
  14.                      IP Broadcast over ATM Networks
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. Copyright Notice
  26.  
  27.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  28.  
  29. Abstract
  30.  
  31.    This memo describes how the IP multicast service being developed by
  32.    the IP over ATM working group may be used to support IP broadcast
  33.    transmission. The solution revolves around treating the broadcast
  34.    problem as a special case of multicast, where every host in the
  35.    subnet or cluster is a member of the group.
  36.  
  37.    An understanding of the services provided by RFC 2022 is assumed.
  38.  
  39. 1.  Introduction.
  40.  
  41.  
  42.    The IETF's first step in solving the problems of running IP over
  43.    Asynchronous Transfer Mode (ATM) technology is described in RFC 1577
  44.    [1].  It provides for unicast communication between hosts and routers
  45.    within Logical IP Subnets (LISs), and proposes a centralized ATM ARP
  46.    Server which provides IP to ATM address resolution services to LIS
  47.    members.
  48.  
  49.    Two classes of IP service were omitted - multicast and broadcast
  50.    transmissions. Multicasting allows a single transmit operation to
  51.    cause a packet to be received by multiple remote destinations.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Smith & Armitage            Standards Track                     [Page 1]
  59.  
  60. RFC 2226             IP Broadcast over ATM Networks         October 1997
  61.  
  62.  
  63.    Broadcasting typically allows a single transmit operation to cause a
  64.    packet to be received by all IP hosts that are members of a
  65.    particular 'subnet'.
  66.  
  67.    To address the need for multicast support (represented by
  68.    transmission to IP addresses in the Class D space), RFC 2022
  69.    ("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2] was
  70.    created.  This memo creates an analog of the RFC 1577 ARP Server - a
  71.    new entity known as the MARS (Multicast Address Resolution Server).
  72.    The MARS operates as a centralized registry and distribution
  73.    mechanism for mappings between IP multicast addresses and groups of
  74.    ATM unicast addresses. Host behavior is also defined for establishing
  75.    and managing point to multipoint VCs, based on the information
  76.    returned by the MARS, when hosts wish to transmit packets to a
  77.    multicast group.
  78.  
  79.    This memo aims to show how RFC 2022 may be used to emulate IP
  80.    broadcast within Logical IP Subnets. While the broadcast technique
  81.    does not align itself well with the underlying point-to-point nature
  82.    of ATM, clearly, some applications will still wish to use IP
  83.    broadcasts.  Client-server applications where the client searches for
  84.    a server by sending out a broadcast is one scenario.  Routing
  85.    protocols, most notably RIP, are other examples.
  86.  
  87. 2.  Review of Unicast and Multicast.
  88.  
  89.    Both the unicast and multicast cases take advantage of the point-to-
  90.    point and point-to-multipoint capabilities defined in the ATM Forum
  91.    UNI 3.1 document [4].  A unicast IP address has a single ATM level
  92.    destination.  Unicast transmissions occur over point to point Virtual
  93.    Channels (VCs) between the source and destination. The ARP Server
  94.    holds mappings between IP destination addresses and their associated
  95.    ATM destination address. Hosts issue an ARP_REQUEST to the ARP Server
  96.    when they wish to ascertain a particular mapping.  The ARP Server
  97.    replies with either an ARP_REPLY containing the ATM address of the
  98.    destination, or an ARP_NAK when the ARP Server is unable to resolve
  99.    the address. If the request is successful the host establishes a VC
  100.    to the destination interface. This VC is then used to forward the
  101.    first (and subsequent) packets to that particular IP destination. RFC
  102.    1577 describes in further detail how hosts are administratively
  103.    grouped in to Logical IP Subnets (LISs), and how the ARP Server
  104.    establishes the initial mappings for members of the LIS it serves.
  105.  
  106.    The basic host behavior for multicasting is similar - the sender must
  107.    establish and manage a point to multipoint VC whose leaf nodes are
  108.    the group's actual members. Under UNI 3.1 these VCs can only be
  109.    established and altered by the source (root) interface.
  110.  
  111.  
  112.  
  113.  
  114. Smith & Armitage            Standards Track                     [Page 2]
  115.  
  116. RFC 2226             IP Broadcast over ATM Networks         October 1997
  117.  
  118.  
  119.    The MARS is an evolution of the ARP Server model, and performs two
  120.    key functions.  The first function is the maintenance of a list of
  121.    ATM addresses corresponding to the members for each group.  This list
  122.    is created by a host registration process which involves two messages
  123.    - a MARS_JOIN which declares that a host wishes to join the specified
  124.    group(s), and a MARS_LEAVE which indicates that a host wishes to
  125.    leave the specified group(s).
  126.  
  127.    MARS_JOIN and MARS_LEAVE messages are also redistributed to all
  128.    members of the group so that active senders may dynamically adjust
  129.    their point to multipoint VCs accordingly.
  130.  
  131.    The other major function is the retrieval of group membership from
  132.    MARS (analogous to the ARP Server providing unicast address
  133.    mappings). When faced with the need to transmit an IP packet with a
  134.    Class D destination address, a host issues a MARS_REQUEST to the
  135.    MARS. If the group has members the MARS returns a MARS_MULTI
  136.    (possibly in multiple segments) carrying a set of ATM addresses. The
  137.    host then establishes an initial point to multipoint VC using these
  138.    ATM addresses as the leaf nodes. If the MARS had no mapping it would
  139.    return a MARS_NAK.
  140.  
  141.    (RFC 2022 also discusses how the MARS can arrange for Class D groups
  142.    to be supported by either multicast servers, or meshes of point to
  143.    multipoint VCs from host to host.  However, from the host's
  144.    perspective this is transparent, and is not central to this
  145.    discussion of IP broadcast support.)
  146.  
  147.    This memo describes how a host may utilize the registration and group
  148.    management functions in an existing MARS based IP/ATM network to
  149.    emulate IP broadcasts.
  150.  
  151. 3.  Broadcast as a special case of Multicast.
  152.  
  153.    Many of the problems that occur when implementing a broadcast
  154.    solution also occur in when implementing a multicast solution.  In
  155.    fact, broadcast may be considered a special case of multicast.  That
  156.    is, broadcast is a multicast group whose members include all members
  157.    in the LIS.
  158.  
  159.    There are two broadcast groups which this memo addresses:
  160.  
  161.       1) 255.255.255.255 - "All ones" broadcast
  162.  
  163.       2) x.z - CIDR-prefix (subnet) directed broadcast
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Smith & Armitage            Standards Track                     [Page 3]
  171.  
  172. RFC 2226             IP Broadcast over ATM Networks         October 1997
  173.  
  174.  
  175.    Broadcast (1) is sometimes referred to as a limited broadcast to this
  176.    physical network.  Broadcast (2) can be thought of as the the
  177.    broadcast for subnets or networks in the old paradigm. As described
  178.    in [6] and [7], the notion of subnets and networks is being replaced
  179.    with a more efficient utilization of the routing address space known
  180.    as Classless Inter-Domain Routing.  The CIDR-prefix (x) is the
  181.    combination of IP address and subnet mask that denotes the subnet
  182.    number.  The host portion of the address (z) is all ones.  One should
  183.    note that while these broadcasts have different scopes at the IP or
  184.    network layer, they have precisely the same scope at the link layer
  185.    -- namely that all members of the LIS will receive a copy.
  186.  
  187.    These addresses may be used in two environments:
  188.  
  189.       o  Broadcasting to all members of a given LIS where
  190.          a priori knowledge of a host's IP address and
  191.          subnet mask are known (e.g. the CIDR-prefix directed
  192.          broadcast).
  193.  
  194.       o  Broadcasting to all members of a physical network
  195.          without knowledge of a host's IP address and
  196.          subnet mask (e.g. the all ones broadcast).
  197.  
  198.    On a broadcast medium like Ethernet, these two environments result in
  199.    the same physical destination.  That is, all stations on that network
  200.    will receive the broadcast even if they are on different logical
  201.    subnets, or are non-IP stations.  With ATM, this may not be the case.
  202.    Because ATM is non-broadcast, a registration process must take place.
  203.    And if there are stations that register to some broadcast groups, but
  204.    not others, then the different broadcast groups will have different
  205.    memberships.  The notion of broadcast becomes inconsistent.
  206.  
  207.    One case that requires the use of the all ones broadcast is that of
  208.    the diskless boot, or bootp client, where the host boots up, and does
  209.    not know its own IP address or subnet mask.  Clearly, the host does
  210.    not know which subnet it belongs to.   So, to send a broadcast to its
  211.    bootp server, the diskless workstation must use the group which
  212.    contains no subnet information, i.e. the 255.255.255.255 broadcast
  213.    group.  Carrying the example a little further, the bootp server,
  214.    after receiving the broadcast, can not send either a directed frame
  215.    nor a subnet directed broadcast to respond to the diskless
  216.    workstation.  Instead, the bootp server must also use the
  217.    255.255.255.255 group to communicate with the client.
  218.  
  219.    While the all ones broadcast is required at the IP layer, it also has
  220.    relevance at the link layer when deciding which broadcast group to
  221.    register with in MARS.  In other words, a bootp client wishing to
  222.    register for a link layer broadcast, can only register for
  223.  
  224.  
  225.  
  226. Smith & Armitage            Standards Track                     [Page 4]
  227.  
  228. RFC 2226             IP Broadcast over ATM Networks         October 1997
  229.  
  230.  
  231.    255.255.255.255 in the MARS address space because the client's subnet
  232.    is unknown at the time.  Given that some applications must use the
  233.    all ones address in MARS for their broadcast group, and that we wish
  234.    to minimize the number of broadcast groups used by LIS members, the
  235.    all ones group in MARS MUST be used by all members of the LIS when
  236.    registering to receive broadcast transmissions.  The VCC used for
  237.    transmitting any broadcast packet will be based on the members
  238.    registered in the MARS under the 255.255.255.255 address position.
  239.    This VCC will be referred to as the "broadcast channel" through the
  240.    remainder of this memo.
  241.  
  242. 4.  The MARS role in broadcast.
  243.  
  244.    Many solutions have been proposed, some of which are listed in
  245.    Appendix A.  This memo addresses a MARS solution which appears to do
  246.    the best job of solving the broadcast problem.
  247.  
  248.    There are a number of characteristics of the MARS architecture that
  249.    should be kept intact.  They include:
  250.  
  251.    o  MARS contains no knowledge of subnet prefixes and subnet masks.
  252.       Each group address registered with MARS is managed independently.
  253.  
  254.    o  A MARS may only serve one LIS. This insures that the
  255.       broadcast group 255.255.255.255 is joined by hosts from one
  256.       LIS, keeping its scope bound to conventional interpretation.
  257.  
  258.    o  The Multicast Server (MCS) described in [2] may be used to service
  259.       the broadcast groups defined in this memo without modification.
  260.       The MCS will reduce the number of channels used by the network.
  261.  
  262.    The MARS needs no additional code or special algorithms to handle the
  263.    resolution of IP broadcast addresses. It is simply a general database
  264.    that holds {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings, and
  265.    imposes no constraints on the type and length of the 'Protocol
  266.    address'. Whether the hosts view it as Class D or 'broadcast' (or
  267.    even IP) is purely a host side issue.
  268.  
  269.    It is likely that end points will want to use the IP broadcast
  270.    emulation described here in order to support boot time location of
  271.    the end point's IP address. This leads to the observation that the
  272.    MARS should NOT expect to see both the IP source and ATM source
  273.    address fields of the MARS_JOIN filled in.  This is reasonable, since
  274.    only the ATM source address is used when registering the end point as
  275.    a group member.
  276.  
  277.    The MARS architecture is sufficient to insure the integrity of the
  278.    broadcast group list without any modification.
  279.  
  280.  
  281.  
  282. Smith & Armitage            Standards Track                     [Page 5]
  283.  
  284. RFC 2226             IP Broadcast over ATM Networks         October 1997
  285.  
  286.  
  287. 5.  Host Requirements for Broadcast.
  288.  
  289.    The following list of bullets describes additional characteristics of
  290.    a MARS-compliant host.  These characteristics are required to take
  291.    advantage of the broadcast function.
  292.  
  293.    o  A host must register as a MARS client.
  294.  
  295.    o  A host, soon after registration MUST issue a MARS_JOIN to the
  296.       all ones broadcast address (i.e. 255.255.255.255) with the
  297.       mar$flags.layer3grp reset.
  298.  
  299.    o  When transmitting packets, the host should map all IP layer
  300.       broadcasts to the VCC (broadcast channel) created and maintained
  301.       based on the all ones entry in MARS.
  302.  
  303.    o  A host MUST monitor the MARS_JOIN/MARS_LEAVE messages
  304.       for 255.255.255.255 to keep the broadcast channel current.
  305.  
  306.    o  A broadcast channel should be torn down after a period of
  307.       inactivity.  The corresponding timeout period MAY be specified
  308.       with a minimum value of one minute, and a RECOMMENDED
  309.       default value of 20 minutes.
  310.  
  311.    One should note that while every member participating in the
  312.    broadcast MUST be a member of the all ones group, not all members
  313.    will choose to transmit broadcast information.  Some members will
  314.    only elect to receive broadcast information passively.  Therefore, in
  315.    a LIS with n stations, there may be less than n channels terminated
  316.    at each station for broadcast information.  Further reductions may be
  317.    gained by adding a Multicast Server (MCS) to the broadcast
  318.    environment which could reduce the number of VCs to two (one
  319.    incoming, one outgoing), or one for a station that only wishes to
  320.    listen.
  321.  
  322.    It is well understood that broadcasting in this environment may tax
  323.    the resources of the network and of the hosts that use it.
  324.    Therefore, an implementer MAY choose to provide a mechanism for
  325.    retracting the host's entry in the broadcast group after it has been
  326.    established or prior to joining the group.  The MARS_LEAVE is used to
  327.    request withdrawal from the group if the host wishes to disable
  328.    broadcast reception after it has joined the group.  The default
  329.    behavior SHALL be to join the all ones broadcast group in MARS.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Smith & Armitage            Standards Track                     [Page 6]
  339.  
  340. RFC 2226             IP Broadcast over ATM Networks         October 1997
  341.  
  342.  
  343. 6.  Implications of IP broadcast on ATM level resources.
  344.  
  345.    RFC 2022 discusses some of the implications of large multicast groups
  346.    on the allocation of ATM level resources, both within the network and
  347.    within end station ATM interfaces.
  348.  
  349.    The default mechanism is for IP multicasting to be achieved using
  350.    meshes of point to multipoint VCs, direct from source host to group
  351.    members. Under certain circumstances system administrators may, in a
  352.    manner completely transparent to end hosts, redirect multicast
  353.    traffic through ATM level Multicast Servers (MCSs). This may be
  354.    performed on an individual group basis.
  355.  
  356.    It is sufficient to note here that the IP broadcast 'multicast group'
  357.    will constitute the largest consumer of VCs within your ATM network
  358.    when it is active. For this reason it will probably be the first
  359.    multicast group to have one or more ATM MCSs assigned to support it.
  360.    However, there is nothing unique about an MCS assigned to support IP
  361.    broadcast traffic, so this will not be dealt with further in this
  362.    memo. RFC 2022 contains further discussion on the possible
  363.    application of multiple MCSs to provide fault-tolerant architectures.
  364.  
  365. 7.  Further discussion.
  366.  
  367.    A point of discussion on the ip-atm forum revolved around "auto
  368.    configuration" and "diskless boot".  This memo describes a broadcast
  369.    solution that requires the use of the MARS.  Therefore, at a minimum,
  370.    the ATM address of the MARS must be manually configured into a
  371.    diskless workstation.  Suggestions such as universal channel numbers,
  372.    and universal ATM addresses have been proposed, however, no agreement
  373.    has been reached.
  374.  
  375.    Another topic for discussion is multiprotocol support.  MARS is
  376.    designed for protocol independence.  This memo specifically addresses
  377.    the IP broadcast case, identifying which addresses are most effective
  378.    in the IP address space.  However, the principles apply to any layer
  379.    3 protocol.  Further work should be performed to identify suitable
  380.    addresses for other layer 3 protocols.
  381.  
  382.    Finally, there has been support voiced for a link layer broadcast
  383.    that would be independent of the layer 3 protocol.  Such a solution
  384.    may provide a simpler set of rules through which broadcast
  385.    applications may be used.  In addition, some solutions also provide
  386.    for more efficient use of VCCs.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Smith & Armitage            Standards Track                     [Page 7]
  395.  
  396. RFC 2226             IP Broadcast over ATM Networks         October 1997
  397.  
  398.  
  399. Security Considerations
  400.  
  401.    This memo addresses a specific use of the MARS architecture and
  402.    components to provide the broadcast function.  As such, the security
  403.    implications are no greater or less than the implications of using
  404.    any of the other multicast groups available in the multicast address
  405.    range.  Should enhancements to security be required, they would need
  406.    to be added as an extension to the base architecture in RFC 2022.
  407.  
  408. Acknowledgments
  409.  
  410.    The apparent simplicity of this memo owes a lot to the services
  411.    provided in [2], which itself is the product of much discussion on
  412.    the IETF's IP-ATM working group mailing list.  Grenville Armitage
  413.    worked on this document while at Bellcore.
  414.  
  415. References
  416.  
  417.    [1]  Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
  418.         December 1993.
  419.  
  420.    [2]  Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
  421.         Networks", RFC 2022, November 1995.
  422.  
  423.    [3]  Deering, S., "Host Extensions for IP Multicasting", STD 5,
  424.         RFC 1112, August 1989.
  425.  
  426.    [4]  ATM Forum, "ATM User-Network Interface Specification Version
  427.         3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
  428.  
  429.    [5]  Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E. and
  430.         A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
  431.         February 1995.
  432.  
  433.    [6]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
  434.         Domain Routing (CIDR): an Address Assignment and Aggregation
  435.         Strategy", RFC 1519, September 1993.
  436.  
  437.    [7]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
  438.         June 1995.
  439.  
  440.    [8]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
  441.         Levels, BCP 14, RFC 2119, March 1997.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Smith & Armitage            Standards Track                     [Page 8]
  451.  
  452. RFC 2226             IP Broadcast over ATM Networks         October 1997
  453.  
  454.  
  455. Authors' Addresses
  456.  
  457.    Timothy J. Smith
  458.    Network Routing Systems,
  459.    International Business Machines Corporation.
  460.    N21/664
  461.    P.O.Box 12195
  462.    Research Triangle Park, NC 27709
  463.  
  464.    Phone: (919) 254-4723
  465.    EMail: tjsmith@vnet.ibm.com
  466.  
  467.  
  468.    Grenville Armitage
  469.    Bell Labs, Lucent Technologies.
  470.    101 Crawfords Corner Rd,
  471.    Holmdel, NJ, 07733
  472.  
  473.    EMail: gja@lucent.com
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Smith & Armitage            Standards Track                     [Page 9]
  507.  
  508. RFC 2226             IP Broadcast over ATM Networks         October 1997
  509.  
  510.  
  511. Appendix A.  Broadcast alternatives
  512.  
  513.    Throughout the development of this memo, there have been a number of
  514.    alternatives explored and discarded for one reason or another.  This
  515.    appendix documents these alternatives and the reason that they were
  516.    not chosen.
  517.  
  518. A.1  ARP Server Broadcast Solutions.
  519.  
  520.    The ARP Server is a good candidate to support broadcasting.  There is
  521.    an ARP Server for every LIS.  The ARP Server contains the entire LIS
  522.    membership.  These are fundamental ingredients for the broadcast
  523.    function.
  524.  
  525. A.1.1  Base Solution without modifications to ARP Server.
  526.  
  527.    One may choose as an existing starting point to use only what is
  528.    available in RFC 1577.  That is, a host can easily calculate the
  529.    range of members in its LIS based on its own IP address and subnet
  530.    mask.  The host can then issue an ARP Request for every member of the
  531.    LIS.  With this information, the host can then set up point-to-point
  532.    connections with all members, or can set up a point-to-multipoint
  533.    connection to all members.  There you have it, the poor man's
  534.    broadcast.
  535.  
  536.    While this solution is very straight forward, it suffers from a
  537.    number of problems.
  538.  
  539.    o  The load on the ARP Server is very large.  If all stations on
  540.       a LIS choose to implement broadcasting, the initial surge of ARP
  541.       Requests will be huge.  Some sort of slow start sequence would be
  542.       needed.
  543.  
  544.    o  The amount of resource required makes this a non-scalable
  545.       solution.  The authors believe that broadcasting will require an
  546.       MCS to reduce the number of channel resources required to support
  547.       each broadcast 'group'.  Using the ARP Server in this manner does
  548.       not allow an MCS to be transparently introduced. (Basic RFC1577
  549.       interfaces also do not implement the extended LLC/SNAP
  550.       encapsulation required to safely use more than one MCS).
  551.  
  552.    o  The diskless boot solution can not function in this environment
  553.       because it may be unable to determine which subnet to which it
  554.       belongs.
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Smith & Armitage            Standards Track                    [Page 10]
  563.  
  564. RFC 2226             IP Broadcast over ATM Networks         October 1997
  565.  
  566.  
  567. A.1.2  Enhanced ARP Server solution.
  568.  
  569.    This solution is similar to the base solution except that it takes
  570.    some of the (MARS) multicast solution and embeds it in the ARP
  571.    Server.  The first enhancement is to add the MARS_MULTI command to
  572.    the set of opcodes that the ARP Server supports.  This would allow a
  573.    host to issue a single request, and to get back the list of members
  574.    in one or more MARS_REPLY packets.  Rather than have a registration
  575.    mechanism, the ARP Server could simply use the list of members that
  576.    have already been registered.  When a request comes in for the subnet
  577.    broadcast address, the ARP Server would aggregate the list, and send
  578.    the results to the requester.
  579.  
  580.    This suffers from two drawbacks.
  581.  
  582.    1)  Scalability with regard to number of VCs is still an issue.
  583.        One would eventually need to add in some sort of multicast
  584.        server solution to the ARP Server.
  585.  
  586.    2)  The diskless boot scenario is still broken.  There is no
  587.        way for a station to perform a MARS_MULTI without first
  588.        knowing its IP address and subnet mask.
  589.  
  590.    The diskless boot problem could be solved by adding to the ARP Server
  591.    a registration process where anyone could register to the
  592.    255.255.255.255 address.  These changes would make the ARP Server
  593.    look more and more like MARS.
  594.  
  595. A.2  MARS Solutions.
  596.  
  597.    If we wish to keep the ARP Server constant as described in RFC 1577,
  598.    the alternative is to use the Multicast Address Resolution Server
  599.    (MARS) described in [2].
  600.  
  601.    MARS has three nice features for broadcasting.
  602.  
  603.    1)  It has a generalized registration approach which allows
  604.        for any address to have a group of entities registered.
  605.        So, if the subnet address is not known, a host can
  606.        register for an address that is known (e.g. 255.255.255.255).
  607.  
  608.    2)  The command set allows for lists of members to be passed
  609.        in a single MARS_MULTI packet.   This reduces traffic.
  610.  
  611.    3)  MARS contains an architecture for dealing with the
  612.        scalability issues.  That is, Multicast Servers (MCSs)
  613.        may be used to set up the point-to-multipoint channels
  614.  
  615.  
  616.  
  617.  
  618. Smith & Armitage            Standards Track                    [Page 11]
  619.  
  620. RFC 2226             IP Broadcast over ATM Networks         October 1997
  621.  
  622.  
  623.        and reduce the number of channels that a host needs to
  624.        set up to one.  Hosts wishing to broadcast will instead
  625.        send the packet to the MCS who will then forward it to
  626.        all members of the LIS.
  627.  
  628. A.2.1.  CIDR-prefix (Subnet) Broadcast solution.
  629.  
  630.    One of the earliest solutions was to simply state that broadcast
  631.    support would be implemented by using a single multicast group in the
  632.    class D address space -- namely, the CIDR-prefix (subnet) broadcast
  633.    address group.  All members of a LIS would be required to register to
  634.    this address, and use it as required.  A host wishing to use either
  635.    the 255.255.255.255 broadcast, or the network broadcast addresses
  636.    would internally map the VC to the subnet broadcast VC.  The all ones
  637.    and network broadcast addresses would exist on MARS, but would be
  638.    unused.
  639.  
  640.    The problem with this approach goes back to the diskless workstation
  641.    problem.  Because the workstation may not know which subnet it
  642.    belongs to, it doesn't know which group to register with.
  643.  
  644. A.2.2.  All one's first, subnet broadcast second
  645.  
  646.    This solution acknowledges that the diskless boot problem requires a
  647.    generic address (one that does not contain CIDR-prefix (subnet)
  648.    information) to register with and to use until subnet knowledge is
  649.    known.  In essence, all stations first register to the
  650.    255.255.255.255 group, then as they know their subnet information,
  651.    they could optionally de-register from the all one's group and
  652.    register to the CIDR-prefix (subnet) broadcast group.
  653.  
  654.    This solution would appear to solve a couple of problems:
  655.  
  656.    1)  The bootp client can function if the server remains
  657.        registered to the all one's group continuously.
  658.  
  659.    2)  There will be less traffic using the all ones group
  660.        because the preferred transactions will be on the
  661.        subnet broadcast channel.
  662.  
  663.    Unfortunately the first bullet contains a flaw.  The server must
  664.    continually be registered to two groups -- the all ones group and the
  665.    subnet broadcast group.  If this server has multiple processes that
  666.    are running different IP applications, it may be difficult for the
  667.    link layer to know which broadcast VC to use.  If it always uses the
  668.    all ones, then it will be missing members that have removed
  669.    themselves from the all ones and have registered to the subnet
  670.    broadcast.  If it always uses the subnet broadcast group, the
  671.  
  672.  
  673.  
  674. Smith & Armitage            Standards Track                    [Page 12]
  675.  
  676. RFC 2226             IP Broadcast over ATM Networks         October 1997
  677.  
  678.  
  679.    diskless boot scenario gets broken.  While making the decision at the
  680.    link layer may require additional control flows be built into the
  681.    path, it may also require the rewriting of application software.
  682.  
  683.    In some implementations, a simple constant is used to indicate to the
  684.    link layer that this packet is to be transmitted to the broadcast
  685.    "MAC" address.  The assumption is that the physical network broadcast
  686.    and the logical protocol broadcast are one and the same.  As pointed
  687.    out earlier, this is not the case with ATM.  Therefore applications
  688.    would need to specifically identify the subnet broadcast group
  689.    address to take advantage of the smaller group.
  690.  
  691.    These problems could be solved in a number of ways, but it was
  692.    thought that they added unnecessarily to the complexity of the
  693.    broadcast solution.
  694.  
  695. Appendix B.  Should MARS Be Limited to a Single LIS?
  696.  
  697.    RFC 2022 explicitly states that a network administrator MUST ensure
  698.    that each LIS is served by a separate MARS, creating a one-to-one
  699.    mapping between cluster and a unicast LIS.  But, it also mentions
  700.    that relaxation of this restriction MAY occur after future research
  701.    warrants it.  This appendix discusses some to the potential
  702.    implications to broadcast should this restriction be removed.
  703.  
  704.    The most obvious change would be that the notion of a cluster would
  705.    span more than one LIS.  Therefore, the broadcast group of
  706.    255.255.255.255 would contain members from more than one LIS.
  707.  
  708.    It also should be emphasized that the one LIS limitation is not a
  709.    restriction of the MARS architecture.  Rather, it is only enforced if
  710.    an administrator chooses to do so.
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Smith & Armitage            Standards Track                    [Page 13]
  731.  
  732. RFC 2226             IP Broadcast over ATM Networks         October 1997
  733.  
  734.  
  735. Full Copyright Statement
  736.  
  737.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  738.  
  739.    This document and translations of it may be copied and furnished to
  740.    others, and derivative works that comment on or otherwise explain it
  741.    or assist in its implmentation may be prepared, copied, published
  742.    andand distributed, in whole or in part, without restriction of any
  743.    kind, provided that the above copyright notice and this paragraph are
  744.    included on all such copies and derivative works.  However, this
  745.    document itself may not be modified in any way, such as by removing
  746.    the copyright notice or references to the Internet Society or other
  747.    Internet organizations, except as needed for the purpose of
  748.    developing Internet standards in which case the procedures for
  749.    copyrights defined in the Internet Standards process must be
  750.    followed, or as required to translate it into languages other than
  751.    English.
  752.  
  753.    The limited permissions granted above are perpetual and will not be
  754.    revoked by the Internet Society or its successors or assigns.
  755.  
  756.    This document and the information contained herein is provided on an
  757.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  758.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  759.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  760.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  761.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Smith & Armitage            Standards Track                    [Page 14]
  787.  
  788.