home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc966 < prev    next >
Text File  |  1991-04-21  |  59KB  |  1,538 lines
  1. Network Working Group                                      S. E. Deering
  2. Request for Comments: 966                                 D. R. Cheriton
  3.                                                      Stanford University
  4.                                                            December 1985
  5.  
  6.                               Host Groups:
  7.              A Multicast Extension to the Internet Protocol
  8.  
  9.  
  10. 1. Status of this Memo
  11.  
  12.    This RFC defines a model of service for Internet multicasting and
  13.    proposes an extension to the Internet Protocol (IP) to support such a
  14.    multicast service.  Discussion and suggestions for improvements are
  15.    requested.  Distribution of this memo is unlimited.
  16.  
  17. 2. Acknowledgements
  18.  
  19.    This memo was adapted from a paper [7] presented at the Ninth Data
  20.    Communications Symposium.  This work was sponsored in part by the
  21.    Defense Advanced Research Projects Agency under contract N00039-83-
  22.    K-0431 and National Science Foundation Grant DCR-83-52048.
  23.  
  24.    The Internet task force on end-to-end protocols, headed by Bob
  25.    Braden, has provided valuable input in the development of the host
  26.    group model.
  27.  
  28. 3. Introduction
  29.  
  30.    In this paper, we describe a model of multicast service we call host
  31.    groups and propose this model as a way to support multicast in the
  32.    DARPA Internet environment [14].  We argue that it is feasible to
  33.    implement this facility as an extension of the existing "unicast" IP
  34.    datagram model and mechanism.
  35.  
  36.    Multicast is the transmission of a datagram packet to a set of zero
  37.    or more destination hosts in a network or internetwork, with a single
  38.    address specifying the set of destination hosts.  For example, hosts
  39.    A, B, C and D may be associated with multicast address X. On
  40.    transmission, a packet with destination address X is delivered with
  41.    datagram reliability to hosts A, B, C and D.
  42.  
  43.    Multicast has two primary uses, namely distributed binding and
  44.    multi-destination delivery.  As a binding mechanism, multicast is a
  45.    robust and often more efficient alternative to the use of name
  46.    servers for finding a particular object or service when a particular
  47.    host address is not known.  For example, in a distributed file
  48.    system, all the file servers may be associated with one well-known
  49.    multicast address.  To bind a file name to a particular server, a
  50.    client sends a query packet containing the file name to the file
  51.    server multicast address, for delivery to all the file servers.  The
  52.  
  53.  
  54. Deering & Cheriton                                              [Page 1]
  55.  
  56.  
  57.  
  58. RFC 966                                                    December 1985
  59. Host Groups: A Multicast Extension to the Internet Protocol
  60.  
  61.  
  62.    server that recognizes the file name then responds to the client,
  63.    allowing subsequent interaction directly with that server host.  Even
  64.    when name servers are employed, multicast can be used as the first
  65.    step in the binding process, that is, finding a name server.
  66.  
  67.    Multi-destination delivery is useful to several applications,
  68.    including:
  69.  
  70.       - distributed, replicated databases [6,9].
  71.  
  72.       - conferencing [11].
  73.  
  74.       - distributed parallel computation, including distributed
  75.         gaming [2].
  76.  
  77.    Ideally, multicast transmission to a set of hosts is not more
  78.    complicated or expensive for the sender than transmission to a single
  79.    host.  Similarly, multicast transmission should not be more expensive
  80.    for the networks and gateways than traversing the shortest path tree
  81.    that connects the sending host to the hosts identified by the
  82.    multicast address.
  83.  
  84.    Multicast, transmission to a set of hosts, is properly distinguished
  85.    from broadcast, transmission to all hosts on a network or
  86.    internetwork. Broadcast is not a generally useful facility since
  87.    there are few reasons for communicating with all hosts.
  88.  
  89.    A variety of local network applications and systems make use of
  90.    multicast.  For instance, the V distributed system [8] uses
  91.    network-level multicast for implementing efficient operations on
  92.    groups of processes spanning multiple machines.  Similar use is being
  93.    made for replicated databases [6] and other distributed applications
  94.    [4]. Providing multicast in the Internet environment would allow
  95.    porting such local network distributed applications to the Internet,
  96.    as well as making some existing Internet applications more robust and
  97.    portable (by, for example, removing "wired-in" lists of addresses,
  98.    such as gateway addresses).
  99.  
  100.    At present, an Internet application logically requiring multicast
  101.    must send individually addressed packets to each recipient.  There
  102.    are two problems with this approach.  Firstly, requiring the sending
  103.    host to know the specific addresses of all the recipients defeats its
  104.    use as a binding mechanism.  For example, a diskless workstation
  105.    needs on boot to determine the network address of a disk server and
  106.    it is undesirable to "wire in" specific network addresses.  With a
  107.    multicast facility, the multicast address of the boot servers (or
  108.  
  109.  
  110.  
  111. Deering & Cheriton                                              [Page 2]
  112.  
  113.  
  114.  
  115. RFC 966                                                    December 1985
  116. Host Groups: A Multicast Extension to the Internet Protocol
  117.  
  118.  
  119.    name servers that hold the addresses of the boot servers) can be
  120.    well-known, allowing the workstation to transmit its initial queries
  121.    to this address.
  122.  
  123.    Secondly, transmitting multiple copies of the same packet makes
  124.    inefficient use of network bandwidth, gateway resources and sender
  125.    resources.  For instance, the same packet may repeatedly traverse the
  126.    same network links and pass through the same gateways.  Furthermore,
  127.    the local network level cannot recognize multi-destination delivery
  128.    to take advantage of multicast facilities that the underlying network
  129.    technologies may provide.  For example, local-area bus, ring, or
  130.    radio networks, as well as satellite-based wide-area networks, can
  131.    provide efficient multicast delivery directly.  Besides using
  132.    excessive communication resources, the use of multiple transmissions
  133.    to effect multicast severely limits the amount of parallelism in
  134.    transmission and processing that can be achieved compared to an
  135.    integrated multicast facility.
  136.  
  137.    The next section describes the host group model of multicast service.
  138.    Section 5 describes the extensions to IP to support the host group
  139.    model.  Section 6 discusses the implementation of multicast within
  140.    the networks and gateways making up the Internet.  Section 7 relates
  141.    this model to other proposals.  Finally, we conclude with remarks on
  142.    our experimental prototype implementation of host groups and comments
  143.    on future directions for investigation.
  144.  
  145. 4. The Host Group Model
  146.  
  147.    The Internet architecture defines a name space of individual host
  148.    addresses.  The host group model extends that name space to include
  149.    addresses of host groups.  A host group is a set of zero or more
  150.    Internet hosts <1>.   When an IP packet is sent with a host group
  151.    address as its destination, it is delivered with "best effort"
  152.    datagram reliability to all members of that host group.
  153.  
  154.    The sender need not be a member of the destination group.  We refer
  155.    to such a group as open, in contrast to a closed group where only
  156.    members are allowed to send to the group.  We chose to provide open
  157.    groups because they are more flexible and more consistent as an
  158.    extension of conventional unicast models (even though they may harder
  159.    to implement).
  160.  
  161.    Dynamic management of group membership provides flexible binding of
  162.    Internet addresses to hosts.  Hosts may join and leave groups over
  163.    time. A host may also belong to more than one group at a time.
  164.    Finally, a host may belong to no groups at times, during which that
  165.    host is unreachable within the Internet architecture.  In fact, a
  166.  
  167.  
  168. Deering & Cheriton                                              [Page 3]
  169.  
  170.  
  171.  
  172. RFC 966                                                    December 1985
  173. Host Groups: A Multicast Extension to the Internet Protocol
  174.  
  175.  
  176.    host need not have an individual Internet address at all.  Some hosts
  177.    may only be associated with multi-host group addresses.  For
  178.    instance, there may be no reason to contact an individual time server
  179.    in the Internet, so time servers would not require individual
  180.    addresses.
  181.  
  182.    Internet addresses are dynamically allocated for transient groups,
  183.    groups that often last only as long as the execution of a single
  184.    distributed program.  In addition, a range of host group identifiers
  185.    is reserved for identifying permanent groups.  One use of permanent
  186.    host groups identifiers is for host groups with standard logical
  187.    meanings such as "name server group", "boot server group", "Internet
  188.    monitor group", etc.
  189.  
  190.    In the current Internet architecture, addresses are bound to single
  191.    hosts.  The host group model generalizes the binding of Internet
  192.    addresses to hosts by allowing one address to bind to multiple hosts
  193.    on multiple networks, more than one address to be bound (in part) to
  194.    one host, and the binding of an address to host to be dynamic, i.e.
  195.    possible to be modified under application control.  Within this more
  196.    general model, the current architecture is supported as a special
  197.    case, retaining its current semantics and implementation.
  198.  
  199.    The following subsections provide further details of the model.
  200.  
  201.    4.1. Host Group Management
  202.  
  203.       Dynamic binding of Internet addresses to hosts is managed by the
  204.       following three operations which are made available to clients of
  205.       the Internet Protocol <2>:
  206.  
  207.          CreateGroup ( type ) --> outcome, group-address, access-key
  208.  
  209.       requests the creation of a new transient host group with the
  210.       invoking host as its only member.  The type argument specifies
  211.       whether the group is restricted or unrestricted.  A restricted
  212.       group restricts membership based on the access-key.  Only hosts
  213.       presenting a valid host access-key are allowed to join.  All
  214.       unrestricted host groups have a null access-key.  outcome
  215.       indicates whether the request is approved or denied.  If it is
  216.       approved, a new transient group address is returned in
  217.       group-address.  access-key is the protection key (or password)
  218.       associated with the new group.  This should fail only if there are
  219.       no free transient group addresses.
  220.  
  221.          JoinGroup ( group-address, access-key ) --> outcome
  222.  
  223.  
  224.  
  225. Deering & Cheriton                                              [Page 4]
  226.  
  227.  
  228.  
  229. RFC 966                                                    December 1985
  230. Host Groups: A Multicast Extension to the Internet Protocol
  231.  
  232.  
  233.       requests that the invoking host become a member of the identified
  234.       host group (permanent or transient).  outcome indicates whether
  235.       the request is approved or denied.  A request is denied if the
  236.       access key is invalid.
  237.  
  238.          LeaveGroup ( group-address ) --> outcome
  239.  
  240.       requests that the invoking host be dropped from membership in the
  241.       identified group (permanent or transient).  outcome indicates
  242.       whether the request is approved or denied.
  243.  
  244.       There is no operation to destroy a transient host group because a
  245.       transient host group is deemed to no longer exist when its
  246.       membership goes to zero.
  247.  
  248.       Permanent host group addresses are allocated and published by
  249.       Internet administrators, in the same way as well-known TCP and UDP
  250.       port numbers.  That is, they are published in future editions of
  251.       the "Assigned Numbers" document [17].
  252.  
  253.    4.2. Packet Transmission
  254.  
  255.       Transmission of a packet in the host group model is controlled by
  256.       two parameters of scope, one being the destination internetwork
  257.       address and the other being the "distance" to the destination
  258.       host(s).  In particular,
  259.  
  260.          Send ( dest-address, source-address, data, distance )
  261.  
  262.       transmits the specified data in an internetwork datagram to the
  263.       host(s) identified by dest-address that are within the specified
  264.       distance.  The destination address is thus similar to conventional
  265.       networks except that delivery may be to multiple hosts; the
  266.       distance parameter requires further discussion.
  267.  
  268.       Distance may be measured in several ways, including number of
  269.       network hops, time to deliver and what might be called
  270.       administrative distance. Administrative distance refers to the
  271.       distance between the administrations of two different networks.
  272.       For example, in a company the networks of the research group and
  273.       advanced development group might be considered quite close to each
  274.       other, networks of the corporate management more distant, and
  275.       networks of other companies much more distant.  One may wish to
  276.       restrict a query to members within one's own administrative domain
  277.       because servers outside that domain may not be trusted.
  278.       Similarly, error reporting outside of an administrative domain may
  279.       not be productive and may in fact be confusing.
  280.  
  281.  
  282. Deering & Cheriton                                              [Page 5]
  283.  
  284.  
  285.  
  286. RFC 966                                                    December 1985
  287. Host Groups: A Multicast Extension to the Internet Protocol
  288.  
  289.  
  290.       Besides limiting the scope of transmission, the distance parameter
  291.       can be used to control the scope of multicast as a binding
  292.       mechanism and to implement an expanding scope of search for a
  293.       desired service.  For instance, to locate a name server familiar
  294.       with a given name, one might check with nearby name servers and
  295.       expand the distance (by incrementing the distance on
  296.       retransmission) to include more distant name servers until the
  297.       name is found.
  298.  
  299.       To reach all members of a group, a sender specifies the maximum
  300.       value for the distance parameter.  This maximum must exceed the
  301.       "diameter" of the Internet.
  302.  
  303.       Packet reception is the same as conventional architectures.  That
  304.       is,
  305.  
  306.          Receive () --> dest-address, source-address, data
  307.  
  308.       returns the next internetwork datagram that is, or has been,
  309.       received.
  310.  
  311.    4.3. Delivery Requirements
  312.  
  313.       We identify several requirements for the packet delivery mechanism
  314.       that are essential to host groups being a useful and used
  315.       facility.
  316.  
  317.       Firstly, given the predominance of broadcast local-area networks
  318.       and the locality of communication to individual networks, the
  319.       delivery mechanism must be able to exploit the hardware's
  320.       capability for very efficient multicast within a single local-area
  321.       network.
  322.  
  323.       Secondly, the delivery mechanism must scale in sophistication to
  324.       efficient delivery across the Internet as it acquires high-speed
  325.       wide-area communication links and higher performance gateways.
  326.       The former are being provided by the introduction of high-speed
  327.       satellite channels and long-haul fiber optic links.  The latter
  328.       are made feasible by the falling cost of memory and processing
  329.       power plus the increasing importance in controlling access to
  330.       relatively unprotected local network environments.  A host group
  331.       delivery mechanism must be able to take advantage of these trends
  332.       as they materialize.
  333.  
  334.       Finally, the delivery mechanism must avoid "systematic errors" in
  335.       delivery to members of the host group.  That is, a small number of
  336.       repeated transmissions must result in delivery to all group
  337.  
  338.  
  339. Deering & Cheriton                                              [Page 6]
  340.  
  341.  
  342.  
  343. RFC 966                                                    December 1985
  344. Host Groups: A Multicast Extension to the Internet Protocol
  345.  
  346.  
  347.       members within the specified distance, unless a member is
  348.       disconnected or has failed.  We refer to this property as
  349.       coverage.  In general, most reliable protocols make this basic
  350.       assumption for unicast delivery.  It is important to guarantee
  351.       this assumption for multicast as well or else applications using
  352.       multicast may fail in unexpected ways when coverage is not
  353.       provided.  For efficiency, the multicast delivery mechanism should
  354.       also avoid regularly delivering multiple copies of a packet to
  355.       individual hosts.
  356.  
  357.       Failure notification is not viewed as an essential requirement,
  358.       given the datagram semantics of delivery.  However, a host group
  359.       extension to IP should provide "hint"-level failure notification
  360.       as the natural extension of the failure notification for unicast.
  361.  
  362. 5. Extensions to IP
  363.  
  364.    This section discusses the specific extensions to the DARPA Internet
  365.    Protocol required to support the host group model.  The extensions
  366.    need be implemented only on those hosts that wish to join host groups
  367.    or send to host groups; existing implementations are not affected by
  368.    the proposed changes.
  369.  
  370.    5.1. Group Addresses
  371.  
  372.       A portion of the 32-bit IP address space is reserved for host
  373.       group addresses.  The range of group addresses is chosen to be
  374.       easily recognized and to not conflict with existing individual
  375.       addresses. Either Class A addresses with a distinguished
  376.       (currently unused) network number or Class D addresses (those
  377.       starting with 111) would be suitable. The range of group addresses
  378.       is further subdivided into a set of permanent group addresses and
  379.       a set of temporary group addresses.
  380.  
  381.       Host group addresses may be used in the same way as individual
  382.       addresses in the source, destination, and options fields of IP
  383.       datagrams.  An IP implementation adds to the list of its own
  384.       individual addresses, the addresses of all groups to which it
  385.       belongs.  The source addresses of locally originated datagrams are
  386.       validated against the list, and incoming datagrams which are not
  387.       destined to an address on the list are discarded.  The addresses
  388.       on the list change dynamically as IP users create, join and leave
  389.       groups.
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396. Deering & Cheriton                                              [Page 7]
  397.  
  398.  
  399.  
  400. RFC 966                                                    December 1985
  401. Host Groups: A Multicast Extension to the Internet Protocol
  402.  
  403.  
  404.    5.2. Group Management
  405.  
  406.       To support the group management operations of CreateGroup,
  407.       JoinGroup and LeaveGroup, an IP module must interact with one or
  408.       more multicast agents which reside in neighbouring gateways or
  409.       other special-purpose hosts.  These interaction are handled by an
  410.       Internet Group Management Protocol (IGMP) which, like ICMP [15],
  411.       is an integral part of the IP implementation.  A proposed
  412.       specification for IGMP is given in Appendix I.
  413.  
  414.    5.3. Multicast Delivery
  415.  
  416.       In order to transmit a datagram destined to a host group, an IP
  417.       module must map the destination group address into a local network
  418.       address.  As with individual IP addresses, the mapping algorithm
  419.       is local-network- specific.  On networks that directly support
  420.       multicast, the IP host group address is mapped to a local network
  421.       multicast address that includes all local members of the host
  422.       group plus one or more multicast agents.  For networks that do not
  423.       directly support multicast, the mapping may be to a more general
  424.       broadcast address, to a list of local unicast addresses, or
  425.       perhaps to the address of a single machine that handles
  426.       multi-destination relaying.
  427.  
  428.    5.4. Distance Control
  429.  
  430.       The existing Time to Live field in the IP header can be used for
  431.       crude control over the delivery radius of multicast datagrams.  To
  432.       provide finer-grain control, a new IP option is defined to specify
  433.       the maximum delivery distance in "administrative units", such as
  434.       "this network", "this department", "this company", "this country",
  435.       etc.  The set of units and their encoding is to be determined.
  436.  
  437. 6. Implementation
  438.  
  439.    In this section, we sketch a design for implementing the host group
  440.    model within the Internet.  This description of the design is given
  441.    to further support the feasibility of the host group model as well as
  442.    point out some of the problems yet to be addressed.
  443.  
  444.    Implementation of host groups involves implementing a binding
  445.    mechanism (binding Internet addresses to zero or more hosts) and a
  446.    packet delivery mechanism (delivering a packet to each host to which
  447.    its destination address binds).  This facility fits most naturally
  448.    into the gateways of the Internet and the switching nodes of the
  449.    constituent point-to-point networks (as opposed to separate machines)
  450.    because multicast binding and delivery is a natural extension of the
  451.  
  452.  
  453. Deering & Cheriton                                              [Page 8]
  454.  
  455.  
  456.  
  457. RFC 966                                                    December 1985
  458. Host Groups: A Multicast Extension to the Internet Protocol
  459.  
  460.  
  461.    unicast binding and delivery (i.e. routing plus store-and-forward).
  462.    That is, a multicast packet is routed and transmitted to multiple
  463.    destinations, rather than to a single destination.
  464.  
  465.    In the following description, we start with a basic, simple
  466.    implementation that provides coverage and then refine this mechanism
  467.    with various optimizations to improve efficiency of delivery and
  468.    group management.
  469.  
  470.    6.1. Basic Implementation
  471.  
  472.       A host group defines a network group, which is the set of networks
  473.       containing current members of the host group.  When a packet is
  474.       sent to a host group, a copy is delivered to each network in the
  475.       corresponding network group.  Then, within each network, a copy is
  476.       delivered to each host belonging to the group.
  477.  
  478.       To support such multicast delivery, every Internet gateway
  479.       maintains the following data structures:
  480.  
  481.          - routing table: conventional Internet routing information,
  482.            including the distance and direction to the nearest gateway
  483.            on every network.
  484.  
  485.          - network membership table:  A set of records, one for every
  486.            currently existing host group.  The network membership record
  487.            for a group lists the network group, i.e. the networks that
  488.            contain members of the group.
  489.  
  490.          - local host membership table:  A set of records, one for each
  491.            host group that has members on directly attached networks.
  492.            Each local host membership record indicates the local hosts
  493.            that are members of the associated host group.  For networks
  494.            that support multicast or broadcast, the record may contain
  495.            only the local network-specific multicast address used by the
  496.            group plus a count of local members.  Otherwise, local group
  497.            members may be identified by a list of unicast addresses to
  498.            be used in the software implementation of multicast within
  499.            the network.
  500.  
  501.       A host invokes the multicast delivery service by sending a
  502.       group-destined IP datagram to an immediate neighbour gateway (i.e.
  503.       a gateway that is directly attached to the same network as the
  504.       sending host).  Upon receiving a group-destined datagram from a
  505.       directly attached network, a gateway looks up the network
  506.       membership record corresponding to the destination address of the
  507.       datagram.  For each of the networks listed in the membership
  508.  
  509.  
  510. Deering & Cheriton                                              [Page 9]
  511.  
  512.  
  513.  
  514. RFC 966                                                    December 1985
  515. Host Groups: A Multicast Extension to the Internet Protocol
  516.  
  517.  
  518.       record, the gateway consults its routing table.  If, according to
  519.       the routing table, a member network is directly attached, the
  520.       gateway transmits a copy of the datagram on that network, using
  521.       the network-specific multicast address allocated for the group on
  522.       that network.  For a member network that is not directly attached
  523.       the gateway creates a copy of the datagram with an additional
  524.       inter-gateway header identifying the destination network.  This
  525.       inter-gateway datagram is forwarded to the nearest gateway on the
  526.       destination network, using conventional store-and-forward routing
  527.       techniques.  At the gateway on the destination network, the
  528.       datagram is stripped of its inter-gateway header and transmitted
  529.       to the group's multicast address on that network.  The datagram is
  530.       dropped by the relaying gateways whenever it exceeds its distance
  531.       limit.
  532.  
  533.       The network membership records and the network-specific multicast
  534.       structures are updated in response to group management requests
  535.       from hosts.  A host sends a request to create, join, or leave a
  536.       group to an immediate neighbour gateway.  If the host requests
  537.       creation of a group, a new network membership record is created by
  538.       the serving gateway and distributed to all other gateways.  If the
  539.       host is the first on its network to join a group, or if the host
  540.       is the last on its network to leave a group, the group's network
  541.       membership record is updated in all gateways.  The updates need
  542.       not be performed atomically at all gateways, due to the datagram
  543.       delivery semantics; hosts can tolerate misrouted and lost packets
  544.       caused by temporary gateway inconsistencies, as long as the
  545.       inconsistencies are resolved within normal host retransmission
  546.       periods. In this respect, the network membership data is similar
  547.       to the network reachability data maintained by conventional
  548.       routing algorithms, and can be handled by similar mechanisms.
  549.  
  550.       In many cases, a host joins a group that already has members on
  551.       the same network, or leaves a group that has remaining members on
  552.       the same network.  This is then a local matter between the hosts
  553.       and gateways on a single network:  only the local host membership
  554.       table needs to be updated to include or exclude the host.
  555.  
  556.       This basic implementation strategy meets the delivery requirements
  557.       stated at the end of Section 4.  However, it is far from optimal,
  558.       in terms of either delivery efficiency or group management
  559.       overhead. Below, we discuss some further refinements to the basic
  560.       implementation.
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567. Deering & Cheriton                                             [Page 10]
  568.  
  569.  
  570.  
  571. RFC 966                                                    December 1985
  572. Host Groups: A Multicast Extension to the Internet Protocol
  573.  
  574.  
  575.    6.2. Multicast Routing Between Networks
  576.  
  577.       Multicast routing among the Internet gateways is similar to
  578.       store-and-forward routing in a point-to-point network.  The main
  579.       difference is that the links between the nodes (gateways) can be a
  580.       mixture of broadcast and unicast-type networks with widely
  581.       different throughput and delay characteristics.  In addition,
  582.       packets are addressed to networks rather than hosts (at the
  583.       gateway level).
  584.  
  585.       We intend to use the extended reverse path forwarding algorithm of
  586.       Dalal and Metcalfe [10].  Although originally designed for
  587.       broadcast, it is a simple and efficient technique that can serve
  588.       well for multicast delivery if network membership records in each
  589.       gateway are augmented with information from neighbouring gateways.
  590.       This algorithm uses the source network identifier, rather than a
  591.       destination network identifier to make routing decisions.  Since
  592.       the source address of a datagram may be a group address, it cannot
  593.       be used to identify the source network of the datagram; the first
  594.       gateway must add a header specifying the source network.  This
  595.       approach minimizes redundant transmissions when multiple
  596.       destination networks are reachable across a common intergateway
  597.       link, a problem with the basic implementation described above.
  598.  
  599.       Note that we eliminate from consideration techniques that fail to
  600.       deliver along the branches of the shortest delay tree rooted at
  601.       the source, such as Wall's center-based forwarding [16] because
  602.       this compromises the meaning of the multicast distance parameter
  603.       and detracts from multicast performance in general.  We also
  604.       rejected the approach of having a multicast packet carry more than
  605.       one network identifier in its inter-gateway header to indicate
  606.       multiple destination networks because the resulting variable
  607.       length headers would cause buffering and fragmentation problems in
  608.       the gateways.
  609.  
  610.    6.3. Multicasting Within Networks
  611.  
  612.       A simple optimization within a network is to have the sender use
  613.       the local multicast address of a host group for its initial
  614.       transmission. This allows the local host group members to receive
  615.       the transmission immediately along with the gateways (which must
  616.       now "eavesdrop" on all multicast transmissions).  A gateway only
  617.       forwards the datagram if the destination host group includes
  618.       members on other networks.  This scheme reduces the cost to reach
  619.       local group members to one packet transmission from two required
  620.  
  621.  
  622.  
  623.  
  624. Deering & Cheriton                                             [Page 11]
  625.  
  626.  
  627.  
  628. RFC 966                                                    December 1985
  629. Host Groups: A Multicast Extension to the Internet Protocol
  630.  
  631.  
  632.       in the basic implementation <3> so transmission to local members
  633.       is basically as efficient as the local multicast support provided
  634.       by the network.
  635.  
  636.       A similar opportunity for reducing packet traffic arises when a
  637.       datagram must traverse a network to get from one gateway to
  638.       another, and that network also holds members of the destination
  639.       group.  Again, use of a network-specific multicast address which
  640.       includes member hosts plus gateways can achieve the desired
  641.       effect.  However, in this case, hosts must be prepared to accept
  642.       datagrams that include an inter-gateway header or, alternatively,
  643.       every datagram must include a spare field in its header for use by
  644.       gateways in lieu of an additional inter-gateway header.
  645.  
  646.    6.4. Distributing Membership Information
  647.  
  648.       A refinement to host group membership maintenance is to store the
  649.       host group membership record for a group only in those gateways
  650.       that are directly connected to member networks.  Information about
  651.       other groups is cached in the gateway only while it is required to
  652.       route to those other groups.  When a gateway receives a datagram
  653.       to be forwarded to a group for which it has no network membership
  654.       record (which can only happen if the gateway is not directly
  655.       connected to a member network), it takes the following action.
  656.       The gateway assumes temporarily that the destination group has
  657.       members on every network in the internetwork, except those
  658.       directly attached to the sending gateway, and routes the datagram
  659.       accordingly.  In the inter-gateway header of the outgoing packet,
  660.       the gateway sets a bit indicating that it wishes to receive a copy
  661.       of the network membership record for the destination host group.
  662.       When such a datagram reaches a gateway on a member network, that
  663.       gateway sends a copy of the membership record back to the
  664.       requesting gateway and clears the copy request bit in the
  665.       datagram.
  666.  
  667.       Copies of network membership records sent to gateways outside of a
  668.       group's member networks are cached for use in subsequent
  669.       transmissions by those gateways.  That raises the danger of a
  670.       stale cache entry leading to systematic delivery failures.  To
  671.       counter that problem, the inter-gateway header contains a field
  672.       which is a hash value or checksum on the network membership record
  673.       used to route the datagram.  Gateways on member networks compare
  674.       the checksum on incoming datagrams with their up-to-date records.
  675.       If the checksums don't match, an up-to-date copy of the record is
  676.       returned to the gateway with the bad record.
  677.  
  678.       This caching strategy minimizes intergateway traffic for groups
  679.  
  680.  
  681. Deering & Cheriton                                             [Page 12]
  682.  
  683.  
  684.  
  685. RFC 966                                                    December 1985
  686. Host Groups: A Multicast Extension to the Internet Protocol
  687.  
  688.  
  689.       that are only used within one network or within the set of
  690.       networks on which members reside, the expected common cases.
  691.       Partial replication with caching also reduces the overhead for
  692.       network traffic to disseminate updates and keep all copies
  693.       consistent.  Finally, it also reduces the total space required in
  694.       all the gateways to support a large number of host groups.
  695.  
  696.       We have not addressed here the problem of maintaining up-to-date,
  697.       consistent network membership records within the set of gateways
  698.       connected to members of a group.  This can be viewed as a
  699.       distributed database problem which has been well studied in other
  700.       contexts.  The loose consistency requirements on network
  701.       membership records suggest that the techniques used in Grapevine
  702.       [3] might be useful for this application.
  703.  
  704. 7. Related Work
  705.  
  706.    The use of unreliable multicast by higher-level protocols and the
  707.    implementation of multicast within various individual networks have
  708.    been well-studied (see [7] for references and discussion).  However,
  709.    there is relatively little published work on the use or
  710.    implementation of internetwork multicasting.
  711.  
  712.    Boggs, in his thesis [4], describes a number of distributed
  713.    applications that are impossible or very awkward to support without
  714.    the flexible binding nature of broadcast addressing.  Although he
  715.    recognizes that almost all of his applications would be best served
  716.    by a multicast mechanism, he advocates the use of "directed
  717.    broadcast" because it is easy to implement within many kinds of
  718.    networks and can be extended across an internetwork without placing
  719.    any new burden on internetwork gateways.  In RFC-919 [13], Mogul
  720.    proposes adopting directed broadcast for the DARPA Internet.
  721.  
  722.    Broadcasting has the undesirable side effect of delivering packets to
  723.    more hosts than necessary, thus incurring overhead on uninvolved
  724.    parties and possibly creating security problems.  As more and more
  725.    applications take advantage of broadcasting, the overhead on all
  726.    hosts continues to rise.  Clearly, broadcast does not scale up to a
  727.    large internetwork.  As an attempt to handle the scaling problem,
  728.    directed broadcast is less attractive than true multicast because the
  729.    set of hosts that can be reached by a single "send" operation is an
  730.    artifact of the internetwork topology, rather than a grouping that is
  731.    meaningful to the sender.
  732.  
  733.    In RFC-947 [12], Lebowitz and Mankins propose the use of broadcast
  734.  
  735.  
  736.  
  737.  
  738. Deering & Cheriton                                             [Page 13]
  739.  
  740.  
  741.  
  742. RFC 966                                                    December 1985
  743. Host Groups: A Multicast Extension to the Internet Protocol
  744.  
  745.  
  746.    repeaters that pick up broadcast datagrams from one network and relay
  747.    them to other networks for broadcast there.  This technique is even
  748.    less selective of its targets than Bogg's directed broadcast method.
  749.  
  750.    Aguilar [1] suggests allowing an IP datagram to carry multiple
  751.    destination addresses, which are used by the gateways to route the
  752.    datagram to each recipient.  Such a facility would alleviate some of
  753.    the inefficiencies of sending individual datagrams to a group, but it
  754.    would not be able to take advantage of local network multicast
  755.    facilities. More seriously, Aguilar's scheme requires the sender to
  756.    know the individual IP addresses of all members of the destination
  757.    group and thus lacks the flexible binding nature of true multicast or
  758.    broadcast.
  759.  
  760. 8. Concluding Remarks
  761.  
  762.    We have described a model of multicast communication for the
  763.    Internet. As an extension of the existing Internet architecture, it
  764.    views unicast communication and time-to-live constraints as special
  765.    cases of the more general form of communication arising with
  766.    multicast.  We have argued that this model is implementable in the
  767.    Internet and that it provides a powerful facility for a variety of
  768.    applications.  In some cases, it provides a facility that is required
  769.    for certain applications to work in the Internet environment.  In
  770.    other cases, it provides a more efficient, robust and possibly more
  771.    elegant way of implementing existing Internet applications.
  772.  
  773.    We are currently implementing a prototype host group facility as an
  774.    extension of IP.  For practical reasons, this prototype implements
  775.    all group management functions and multicast routing outside of the
  776.    Internet gateways, in special hosts called multicast agents, which
  777.    are similar to the broadcast repeaters of Lebowitz and Mankins.  The
  778.    collection of multicast agents in effect provides a second gateway
  779.    system on top of the existing Internet, for multicast purposes.  The
  780.    major costs of this separation are redundancy of routing tables
  781.    between gateways and multicast agents and the increased delay and
  782.    unreliability of extra hops in the delivery path.  Much of the
  783.    routing information in the multicast agents must be "wired-in"
  784.    because they do not have access to the gateways' routing tables.
  785.    However, this rudimentary implementation provides an environment for
  786.    evaluating the interface to the multicast service and for
  787.    investigating group management and multicast routing protocols for
  788.    eventual use in the gateways.  It also serves as a testbed for
  789.    porting multicast-based distributed applications to the Internet.
  790.  
  791.    For now, we are restricting group membership to local networks that
  792.    already have a broadcast or multicast capability, such as the
  793.  
  794.  
  795. Deering & Cheriton                                             [Page 14]
  796.  
  797.  
  798.  
  799. RFC 966                                                    December 1985
  800. Host Groups: A Multicast Extension to the Internet Protocol
  801.  
  802.  
  803.    Ethernet. We feel that, in the future, any network that is to support
  804.    hosts other than just gateways must have a multicast addressing mode.
  805.    Efficient implementation of multicast within point-to-point or
  806.    virtual circuit networks deserves investigation.
  807.  
  808.    A significant issue raised by the host group model is authentication
  809.    and access control in the Internet.  Gateways must control which
  810.    hosts can create and join host groups, presumably making their
  811.    decision based on the identity of the requestor (thus requiring
  812.    authentication) and permissions (access control lists).  This issue
  813.    does not arise in conventional internetwork architectures because
  814.    host addresses are administratively assigned with no notion of
  815.    dynamic assignment and binding as provided by host groups.  We
  816.    believe that access control should be recognized as a proper and
  817.    necessary function of gateways so as to protect the hosts of local
  818.    networks from general internetwork activity.  Thus, group access
  819.    control can be subsumed as part of this more general mechanism,
  820.    although more investigation of the general issue is called for.
  821.  
  822.    On a philosophical point, there has been considerable reluctance to
  823.    make open use of multicast on local networks because it was
  824.    network-specific and not provided across the Internet.  We were
  825.    originally of that school.  However, we recognized that our "hidden"
  826.    uses of multicast in the V distributed system were essential unless
  827.    we resorted to dramatically poorer solutions - wired-in addresses.
  828.    We also recognized, as described in this paper, that an adequate
  829.    multicast facility for the Internet was feasible.  As a consequence,
  830.    we now argue that multicast is an important and basic facility to
  831.    provide in local networks and internetworks.  Higher levels of
  832.    communication, including applications, should feel free to make use
  833.    of this powerful facility. Networks and internetworks lacking
  834.    multicast should be regarded as deficient relative to the future (and
  835.    present) requirements of sophisticated distributed applications and
  836.    communication systems.
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852. Deering & Cheriton                                             [Page 15]
  853.  
  854.  
  855.  
  856. RFC 966                                                    December 1985
  857. Host Groups: A Multicast Extension to the Internet Protocol
  858.  
  859.  
  860. Appendix I. Internet Group Management Protocol (IGMP)
  861.  
  862.    The Internet Group Management Protocol (IGMP) is used between IP
  863.    hosts and their immediate neighbour multicast agents to support the
  864.    allocation of temporary group addresses and the addition and deletion
  865.    of members of a group.
  866.  
  867.    Like ICMP, IGMP is a required part of all IP implementations.  IGMP
  868.    messages are encapsulated in IP datagrams, with an IP protocol number
  869.    of 2.  IGMP messages are formatted similarly to ICMP messages and the
  870.    different IGMP message types are given values distinct from ICMP
  871.    message types, so that both protocols may share common implementation
  872.    modules or, perhaps, be merged into a single protocol.
  873.  
  874.    IGMP interactions take the form of request-response transactions.  A
  875.    request message is sent by hosts to the permanent group of all
  876.    immediate neighbour multicast agents.  Multicast agents reply to the
  877.    IP source address of a request.  If no reply is received within a
  878.    (currently unspecified) timeout interval, a host retransmits its
  879.    request, up to some (currently unspecified) maximum number of times.
  880.    IGMP transactions are considered idempotent, so that multicast agents
  881.    need not recognize and filter out duplicate requests nor buffer
  882.    replies <4>.
  883.  
  884.    The IGMP message formats and procedures are defined below, in the
  885.    style used in the ICMP specification.
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909. Deering & Cheriton                                             [Page 16]
  910.  
  911.  
  912.  
  913. RFC 966                                                    December 1985
  914. Host Groups: A Multicast Extension to the Internet Protocol
  915.  
  916.  
  917.    Create Group Request or Create Group Reply Message
  918.  
  919.        0                   1                   2                   3
  920.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  921.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  922.       |     Type      |     Code      |           Checksum            |
  923.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  924.       |           Identifier          |        Sequence Number        |
  925.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  926.       |                         Group Address                         |
  927.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  928.       |                                                               |
  929.       +                         Access Key                            +
  930.       |                                                               |
  931.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  932.  
  933.       IP Fields:
  934.  
  935.       Addresses
  936.  
  937.          A Create Group Request message is sent with an individual IP
  938.          address of the sending host as its source, and the well-known
  939.          group address of the multicast agents as its destination.
  940.  
  941.          The corresponding Create Group Reply is sent with those two
  942.          addresses reversed.
  943.  
  944.       IGMP Fields:
  945.  
  946.       Type
  947.  
  948.          101 for Create Group Request
  949.          102 for Create Group Reply
  950.  
  951.       Code
  952.  
  953.          For a Create Group Request message, the Code field indicates if
  954.          the group is to be restricted:
  955.  
  956.             0 = unrestricted
  957.             1 = restricted
  958.  
  959.          For a Create Group Reply message, the Code field specifies the
  960.          outcome of the request:
  961.  
  962.             0 = request approved
  963.             1 = request denied, no resources
  964.  
  965.  
  966. Deering & Cheriton                                             [Page 17]
  967.  
  968.  
  969.  
  970. RFC 966                                                    December 1985
  971. Host Groups: A Multicast Extension to the Internet Protocol
  972.  
  973.  
  974.       Checksum
  975.  
  976.          The checksum is the 16-bit one's complement of the one's
  977.          complement sum of the IGMP message starting with the IGMP Type.
  978.          For computing the checksum, the checksum field should be zero.
  979.          This checksum may be replaced in the future.
  980.  
  981.       Identifier
  982.  
  983.          An identifier to aid in matching Request and Reply messages.
  984.  
  985.       Sequence Number
  986.  
  987.          A sequence number to aid in matching Request and Reply
  988.          messages.
  989.  
  990.       Group Address
  991.  
  992.          For a Create Group Request message, a value of 0.
  993.  
  994.          For a Create Group Reply message, either a newly allocated
  995.          group address (if the request is approved) or a value of 0 (if
  996.          denied).
  997.  
  998.       Access Key
  999.  
  1000.          For a Create Group Request message, a value of 0.
  1001.  
  1002.          For a Create Group Reply message, either a pseudo-random 64-bit
  1003.          number (if the request for a restricted group is approved) or
  1004.          0.
  1005.  
  1006.       Description
  1007.  
  1008.          A Create Group Request message is sent to the the group of
  1009.          local multicast agents by a host wishing to allocate a new
  1010.          temporary group.
  1011.  
  1012.          If no Reply message is received within t seconds, the Request
  1013.          is retransmitted.  If no Reply is received after n
  1014.          transmissions, the request is deemed to have failed.
  1015.  
  1016.          The first Reply message to arrive, if any, specifies the
  1017.          outcome of the request.  The request may be denied because of
  1018.          lack of resources (e.g. no table space in gateways or all
  1019.          temporary addresses in use).
  1020.  
  1021.  
  1022.  
  1023. Deering & Cheriton                                             [Page 18]
  1024.  
  1025.  
  1026.  
  1027. RFC 966                                                    December 1985
  1028. Host Groups: A Multicast Extension to the Internet Protocol
  1029.  
  1030.  
  1031.          If the request is approved, the requesting host is considered
  1032.          to be the first and only current member of the new host group.
  1033.  
  1034.          The Identifier and Sequence Number fields are used to match the
  1035.          Reply to the corresponding Request.  The multicast agents may
  1036.          choose to use these values to minimize the chance of allocating
  1037.          more than one new group for a single request, for example when
  1038.          a Reply is lost and a
  1039.  
  1040.          Request is retransmitted.  However, the multicast agents must
  1041.          be prepared to recover temporary group addresses without
  1042.          requiring explicit Leave Group Requests from all members; they
  1043.          may choose simply to allocate a new address for every
  1044.          retransmission and recover unused ones when needed <5>.
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080. Deering & Cheriton                                             [Page 19]
  1081.  
  1082.  
  1083.  
  1084. RFC 966                                                    December 1985
  1085. Host Groups: A Multicast Extension to the Internet Protocol
  1086.  
  1087.  
  1088.    Join Group Request or Join Group Reply Message
  1089.  
  1090.        0                   1                   2                   3
  1091.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1092.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1093.       |     Type      |     Code      |           Checksum            |
  1094.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1095.       |           Identifier          |        Sequence Number        |
  1096.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1097.       |                         Group Address                         |
  1098.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1099.       |                                                               |
  1100.       +                         Access Key                            +
  1101.       |                                                               |
  1102.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1103.  
  1104.       IP Fields:
  1105.  
  1106.       Addresses
  1107.  
  1108.          A Join Group Request message is sent with an individual IP
  1109.          address of the sending host as its source, and the well-known
  1110.          group address of the multicast agents as its destination.
  1111.  
  1112.          The corresponding Join Group Reply is sent with those two
  1113.          addresses reversed.
  1114.  
  1115.       IGMP Fields:
  1116.  
  1117.       Type
  1118.  
  1119.          103 for Join Group Request
  1120.          104 for Join Group Reply
  1121.  
  1122.       Code
  1123.  
  1124.          For a Join Group Request message, the Code field contains 0.
  1125.  
  1126.          For a Join Group Reply message, the Code field specifies the
  1127.          outcome of the request:
  1128.  
  1129.             0 = request approved
  1130.             1 = request denied, no resources
  1131.             2 = request denied, invalid group address
  1132.             3 = request denied, invalid access key
  1133.  
  1134.  
  1135.  
  1136.  
  1137. Deering & Cheriton                                             [Page 20]
  1138.  
  1139.  
  1140.  
  1141. RFC 966                                                    December 1985
  1142. Host Groups: A Multicast Extension to the Internet Protocol
  1143.  
  1144.  
  1145.       Checksum
  1146.  
  1147.          The checksum is the 16-bit one's complement of the one's
  1148.          complement sum of the IGMP message starting with the IGMP Type.
  1149.          For computing the checksum, the checksum field should be zero.
  1150.          This checksum may be replaced in the future.
  1151.  
  1152.       Identifier
  1153.  
  1154.          An identifier to aid in matching Request and Reply messages.
  1155.  
  1156.       Sequence Number
  1157.  
  1158.          A sequence number to aid in matching Request and Reply
  1159.          messages.
  1160.  
  1161.       Group Address
  1162.  
  1163.          For a Join Group Request message, a host group address.
  1164.  
  1165.          For a Join Group Reply message, the same group address as in
  1166.          the corresponding request.
  1167.  
  1168.       Access Key
  1169.  
  1170.          For a Join Group Request message, the access key allocated when
  1171.          the group was created (0 for unrestricted groups).
  1172.  
  1173.          For a Join Group Reply message, the same access key as in the
  1174.          corresponding request.
  1175.  
  1176.       Description
  1177.  
  1178.          A Join Group Request message is sent to the the group of local
  1179.          multicast agents by a host wishing to join a specified,
  1180.          existing group.  If no Reply message is received within t
  1181.          seconds, the Request is retransmitted.  If no reply is received
  1182.          after n transmissions, the request is deemed to have failed.
  1183.  
  1184.          The first Reply message to arrive, if any, specifies the
  1185.          outcome of the request.  The request may be denied because of
  1186.          an invalid access key, an invalid specified group address (e.g.
  1187.          non-existent group) or lack of resources (e.g. no table space
  1188.          in gateways).
  1189.  
  1190.          The Identifier and Sequence Number fields are used to match the
  1191.          Reply to the corresponding Request.  If a multicast agent
  1192.  
  1193.  
  1194. Deering & Cheriton                                             [Page 21]
  1195.  
  1196.  
  1197.  
  1198. RFC 966                                                    December 1985
  1199. Host Groups: A Multicast Extension to the Internet Protocol
  1200.  
  1201.  
  1202.          receives a request from a host to join a group to which it
  1203.          already belongs, the agent approves the request, under the
  1204.          assumption that the request was a retransmission for a lost
  1205.          Reply.
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251. Deering & Cheriton                                             [Page 22]
  1252.  
  1253.  
  1254.  
  1255. RFC 966                                                    December 1985
  1256. Host Groups: A Multicast Extension to the Internet Protocol
  1257.  
  1258.  
  1259.    Leave Group Request or Leave Group Reply Message
  1260.  
  1261.        0                   1                   2                   3
  1262.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1263.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1264.       |     Type      |     Code      |           Checksum            |
  1265.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1266.       |           Identifier          |        Sequence Number        |
  1267.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1268.       |                         Group Address                         |
  1269.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1270.  
  1271.       IP Fields:
  1272.  
  1273.       Addresses
  1274.  
  1275.          A Leave Group Request message is sent with an individual IP
  1276.          address of the sending host as its source, and the well-known
  1277.          group address of the multicast agents as its destination.
  1278.  
  1279.          The corresponding Leave Group Reply is sent with those two
  1280.          addresses reversed.
  1281.  
  1282.       IGMP Fields:
  1283.  
  1284.       Type
  1285.  
  1286.          105 for Leave Group Request
  1287.          106 for Leave Group Reply
  1288.  
  1289.       Code
  1290.  
  1291.          For a Leave Group Request message, the Code field contains 0.
  1292.  
  1293.          For  Leave Group Reply message, the Code field specifies the
  1294.          outcome of the request:
  1295.  
  1296.             0 = request approved
  1297.             2 = request denied, invalid group address
  1298.  
  1299.       Checksum
  1300.  
  1301.          The checksum is the 16-bit one's complement of the one's
  1302.          complement sum of the IGMP message starting with the IGMP Type.
  1303.          For computing the checksum, the checksum field should be zero.
  1304.          This checksum may be replaced in the future.
  1305.  
  1306.  
  1307.  
  1308. Deering & Cheriton                                             [Page 23]
  1309.  
  1310.  
  1311.  
  1312. RFC 966                                                    December 1985
  1313. Host Groups: A Multicast Extension to the Internet Protocol
  1314.  
  1315.  
  1316.       Identifier
  1317.  
  1318.          An identifier to aid in matching Request and Reply messages.
  1319.  
  1320.       Sequence Number
  1321.  
  1322.          A sequence number to aid in matching Request and Reply
  1323.          messages.
  1324.  
  1325.       Group Address
  1326.  
  1327.          For a Leave Group Request message, a host group address.
  1328.  
  1329.          For a Leave Group Reply message, the same group address as in
  1330.          the corresponding request.
  1331.  
  1332.       Description
  1333.  
  1334.          A Leave Group Request message is sent to the the group of local
  1335.          multicast agents by a host wishing to leave a specified,
  1336.          existing group.  If no Reply message is received within t
  1337.          seconds, the Request is retransmitted.  If no reply is received
  1338.          after n transmissions, the request is deemed to have succeeded.
  1339.  
  1340.          The first Reply message to arrive, if any, specifies the
  1341.          outcome of the request.  The request may be denied only if the
  1342.          specified group address is invalid (e.g. an individual rather
  1343.          than a group address.)
  1344.  
  1345.          The Identifier and Sequence Number fields are used to match the
  1346.          Reply to the corresponding Request, as with other ICMP
  1347.          transactions. If a multicast agent receives a request from a
  1348.          host to leave a group to which it does not belong, the agent
  1349.          approves the request, under the assumption that the request was
  1350.          a retransmission for a lost Reply.
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365. Deering & Cheriton                                             [Page 24]
  1366.  
  1367.  
  1368.  
  1369. RFC 966                                                    December 1985
  1370. Host Groups: A Multicast Extension to the Internet Protocol
  1371.  
  1372.  
  1373. Notes:
  1374.  
  1375.    <1>  In reality, Internet addresses (individual or group) are bound
  1376.         to network interfaces or network attachment points, not the host
  1377.         machines per se.
  1378.  
  1379.    <2>  In this procedure call notation, the arguments for an operation
  1380.         are listed in parentheses after the operation name, and the
  1381.         returned values, if any, are listed after a --> symbol.
  1382.  
  1383.    <3>  One unicast transmission from sender to gateway and one
  1384.         multicast transmission from gateway to local group members
  1385.  
  1386.    <4>  This protocol may eventually be replaced by a more general
  1387.         reliable transaction protocol designed for this type of
  1388.         client/server interaction, as suggested in RFC-955 [5].
  1389.  
  1390.    <5>  Multicast agents can use an ICMP Echo message to determine if a
  1391.         group has any current members.  The Echo message should be
  1392.         transmitted several times before deciding the group address is
  1393.         no longer in use.
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402.  
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422. Deering & Cheriton                                             [Page 25]
  1423.  
  1424.  
  1425.  
  1426. RFC 966                                                    December 1985
  1427. Host Groups: A Multicast Extension to the Internet Protocol
  1428.  
  1429.  
  1430. References
  1431.  
  1432.    [1]   L. Aguilar. Datagram Routing for Internet Multicasting. In ACM
  1433.          SIGCOMM '84 Communications Architectures and Protocols, pages
  1434.          58-63. ACM, June, 1984.
  1435.  
  1436.    [2]   E. J. Berglund and D. R. Cheriton. Amaze: A distributed
  1437.          multi-player game program using the distributed V kernel. In
  1438.          Proceedings of the Fourth International Conference on
  1439.          Distributed Systems. IEEE, May, 1984.
  1440.  
  1441.    [3]   A. D. Birrell et al. Grapevine: an exercise in distributed
  1442.          computing. Communications of the ACM 25(4):260-274, April,
  1443.          1982.
  1444.  
  1445.    [4]   D. R. Boggs. Internet Broadcasting. PhD thesis, Stanford
  1446.          University, January, 1982.
  1447.  
  1448.    [5]   R. Braden. Towards a Transport Service for Transaction
  1449.          Processing Applications. Technical Report RFC-919, SRI Network
  1450.          Information Center, September, 1985.
  1451.  
  1452.    [6]   J-M. Chang. Simplifying Distributed Database Design by Using a
  1453.          Broadcast Network. In SIGMOD '84. ACM, June, 1984.
  1454.  
  1455.    [7]   D. R. Cheriton and S. E. Deering. Host Groups: A Multicast
  1456.          Extension for Datagram Internetworks. In Proceedings of the
  1457.          Ninth Data Communications Symposium. ACM/IEEE, September, 1985.
  1458.  
  1459.    [8]   D. R. Cheriton and W. Zwaenepoel. Distributed Process Groups in
  1460.          the V Kernel. ACM Transactions on Computer Systems 3(3), May,
  1461.          1985.
  1462.  
  1463.    [9]   F. Cristian et al. Atomic Broadcast: from simple message
  1464.          diffusion to Byzantine agreement. In 15th International
  1465.          Conference on Fault Tolerant Computing. , Ann Arbor, Michigan,
  1466.          June, 1985.
  1467.  
  1468.    [10]  Y. K. Dalal and R. M. Metcalfe. Reverse Path Forwarding of
  1469.          Broadcast Packets. Communications of the ACM 21(2):1040-1047,
  1470.          December, 1978.
  1471.  
  1472.    [11]  H. Forsdick. MMCF: A Multi-Media Conferencing Facility.
  1473.          personal communication.
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479. Deering & Cheriton                                             [Page 26]
  1480.  
  1481.  
  1482.  
  1483. RFC 966                                                    December 1985
  1484. Host Groups: A Multicast Extension to the Internet Protocol
  1485.  
  1486.  
  1487.    [12]  K. Lebowitz and D. Mankins. Multi-network Broadcasting within
  1488.          the Internet.Technical Report RFC-947, SRI Network Information
  1489.          Center, June, 1985.
  1490.  
  1491.    [13]  J. Mogul. Broadcasting Internet Datagrams. Technical Report
  1492.          RFC-919, SRI Network Information Center, October, 1984.
  1493.  
  1494.    [14]  J. Postel. Internet Protocol. Technical Report RFC-791, SRI
  1495.          Network Information Center, September, 1981.
  1496.  
  1497.    [15]  J. Postel. Internet Control Message Protocol. Technical Report
  1498.          RFC-792, SRI Network Information Center, September, 1981.
  1499.  
  1500.    [16]  D. W, Wall. Mechanisms for Broadcast and Selective Broadcast.
  1501.          Technical Report 190, Computer Systems Laboratory, Stanford
  1502.          University, June, 1980.
  1503.  
  1504.    [17]  J. K. Reynolds and J. Postel. Assigned Numbers. Technical
  1505.          Report RFC-960, SRI Network Information Center, September,
  1506.          1981.
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536. Deering & Cheriton                                             [Page 27]
  1537.  
  1538.