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