As per Relevance of the word multicast, we have this rfc below:
Network Working Group S. E.
Request for Comments: 966 D. R.
Stanford
December 1985
Host Groups
A Multicast Extension to the Internet
1. Status of this
This RFC defines a model of service for Internet multicasting
proposes an extension to the Internet Protocol (IP) to support such
multicast service. Discussion and suggestions for improvements
requested. Distribution of this memo is unlimited
2.
This memo was adapted from a paper [7] presented at the Ninth
Communications Symposium. This work was sponsored in part by
Defense Advanced Research Projects Agency under contract N00039-83-
K-0431 and National Science Foundation Grant DCR-83-52048.
The Internet task force on end-to-end protocols, headed by
Braden, has provided valuable input in the development of the
group model
3.
In this paper, we describe a model of multicast service we call
groups and propose this model as a way to support multicast in
DARPA Internet environment [14]. We argue that it is feasible
implement this facility as an extension of the existing "unicast"
datagram model and mechanism
Multicast is the transmission of a datagram packet to a set of
or more destination hosts in a network or internetwork, with a
address specifying the set of destination hosts. For example,
A, B, C and D may be associated with multicast address X.
transmission, a packet with destination address X is delivered
datagram reliability to hosts A, B, C and D
Multicast has two primary uses, namely distributed binding
multi-destination delivery. As a binding mechanism, multicast is
robust and often more efficient alternative to the use of
servers for finding a particular object or service when a
host address is not known. For example, in a distributed
system, all the file servers may be associated with one well-
multicast address. To bind a file name to a particular server,
client sends a query packet containing the file name to the
server multicast address, for delivery to all the file servers.
Deering & Cheriton [Page 1]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
server that recognizes the file name then responds to the client
allowing subsequent interaction directly with that server host.
when name servers are employed, multicast can be used as the
step in the binding process, that is, finding a name server
Multi-destination delivery is useful to several applications
including
- distributed, replicated databases [6,9].
- conferencing [11].
- distributed parallel computation, including
gaming [2].
Ideally, multicast transmission to a set of hosts is not
complicated or expensive for the sender than transmission to a
host. Similarly, multicast transmission should not be more
for the networks and gateways than traversing the shortest path
that connects the sending host to the hosts identified by
multicast address
Multicast, transmission to a set of hosts, is properly
from broadcast, transmission to all hosts on a network
internetwork. Broadcast is not a generally useful facility
there are few reasons for communicating with all hosts
A variety of local network applications and systems make use
multicast. For instance, the V distributed system [8]
network-level multicast for implementing efficient operations
groups of processes spanning multiple machines. Similar use is
made for replicated databases [6] and other distributed
[4]. Providing multicast in the Internet environment would
porting such local network distributed applications to the Internet
as well as making some existing Internet applications more robust
portable (by, for example, removing "wired-in" lists of addresses
such as gateway addresses).
At present, an Internet application logically requiring
must send individually addressed packets to each recipient.
are two problems with this approach. Firstly, requiring the
host to know the specific addresses of all the recipients defeats
use as a binding mechanism. For example, a diskless
needs on boot to determine the network address of a disk server
it is undesirable to "wire in" specific network addresses. With
multicast facility, the multicast address of the boot servers (
Deering & Cheriton [Page 2]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
name servers that hold the addresses of the boot servers) can
well-known, allowing the workstation to transmit its initial
to this address
Secondly, transmitting multiple copies of the same packet
inefficient use of network bandwidth, gateway resources and
resources. For instance, the same packet may repeatedly traverse
same network links and pass through the same gateways. Furthermore
the local network level cannot recognize multi-destination
to take advantage of multicast facilities that the underlying
technologies may provide. For example, local-area bus, ring,
radio networks, as well as satellite-based wide-area networks,
provide efficient multicast delivery directly. Besides
excessive communication resources, the use of multiple
to effect multicast severely limits the amount of parallelism
transmission and processing that can be achieved compared to
integrated multicast facility
The next section describes the host group model of multicast service
Section 5 describes the extensions to IP to support the host
model. Section 6 discusses the implementation of multicast
the networks and gateways making up the Internet. Section 7
this model to other proposals. Finally, we conclude with remarks
our experimental prototype implementation of host groups and
on future directions for investigation
4. The Host Group
The Internet architecture defines a name space of individual
addresses. The host group model extends that name space to
addresses of host groups. A host group is a set of zero or
Internet hosts <1>. When an IP packet is sent with a host
address as its destination, it is delivered with "best effort
datagram reliability to all members of that host group
The sender need not be a member of the destination group. We
to such a group as open, in contrast to a closed group where
members are allowed to send to the group. We chose to provide
groups because they are more flexible and more consistent as
extension of conventional unicast models (even though they may
to implement).
Dynamic management of group membership provides flexible binding
Internet addresses to hosts. Hosts may join and leave groups
time. A host may also belong to more than one group at a time
Finally, a host may belong to no groups at times, during which
host is unreachable within the Internet architecture. In fact,
Deering & Cheriton [Page 3]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
host need not have an individual Internet address at all. Some
may only be associated with multi-host group addresses.
instance, there may be no reason to contact an individual time
in the Internet, so time servers would not require
addresses
Internet addresses are dynamically allocated for transient groups
groups that often last only as long as the execution of a
distributed program. In addition, a range of host group
is reserved for identifying permanent groups. One use of
host groups identifiers is for host groups with standard
meanings such as "name server group", "boot server group", "
monitor group", etc
In the current Internet architecture, addresses are bound to
hosts. The host group model generalizes the binding of
addresses to hosts by allowing one address to bind to multiple
on multiple networks, more than one address to be bound (in part)
one host, and the binding of an address to host to be dynamic, i.e
possible to be modified under application control. Within this
general model, the current architecture is supported as a
case, retaining its current semantics and implementation
The following subsections provide further details of the model
4.1. Host Group
Dynamic binding of Internet addresses to hosts is managed by
following three operations which are made available to clients
the Internet Protocol <2>:
CreateGroup ( type ) --> outcome, group-address, access-
requests the creation of a new transient host group with
invoking host as its only member. The type argument
whether the group is restricted or unrestricted. A
group restricts membership based on the access-key. Only
presenting a valid host access-key are allowed to join.
unrestricted host groups have a null access-key.
indicates whether the request is approved or denied. If it
approved, a new transient group address is returned
group-address. access-key is the protection key (or password
associated with the new group. This should fail only if there
no free transient group addresses
JoinGroup ( group-address, access-key ) -->
Deering & Cheriton [Page 4]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
requests that the invoking host become a member of the
host group (permanent or transient). outcome indicates
the request is approved or denied. A request is denied if
access key is invalid
LeaveGroup ( group-address ) -->
requests that the invoking host be dropped from membership in
identified group (permanent or transient). outcome
whether the request is approved or denied
There is no operation to destroy a transient host group because
transient host group is deemed to no longer exist when
membership goes to zero
Permanent host group addresses are allocated and published
Internet administrators, in the same way as well-known TCP and
port numbers. That is, they are published in future editions
the "Assigned Numbers" document [17].
4.2. Packet
Transmission of a packet in the host group model is controlled
two parameters of scope, one being the destination
address and the other being the "distance" to the
host(s). In particular
Send ( dest-address, source-address, data, distance )
transmits the specified data in an internetwork datagram to
host(s) identified by dest-address that are within the
distance. The destination address is thus similar to
networks except that delivery may be to multiple hosts;
distance parameter requires further discussion
Distance may be measured in several ways, including number
network hops, time to deliver and what might be
administrative distance. Administrative distance refers to
distance between the administrations of two different networks
For example, in a company the networks of the research group
advanced development group might be considered quite close to
other, networks of the corporate management more distant,
networks of other companies much more distant. One may wish
restrict a query to members within one's own administrative
because servers outside that domain may not be trusted
Similarly, error reporting outside of an administrative domain
not be productive and may in fact be confusing
Deering & Cheriton [Page 5]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
Besides limiting the scope of transmission, the distance
can be used to control the scope of multicast as a
mechanism and to implement an expanding scope of search for
desired service. For instance, to locate a name server
with a given name, one might check with nearby name servers
expand the distance (by incrementing the distance
retransmission) to include more distant name servers until
name is found
To reach all members of a group, a sender specifies the
value for the distance parameter. This maximum must exceed
"diameter" of the Internet
Packet reception is the same as conventional architectures.
is
Receive () --> dest-address, source-address,
returns the next internetwork datagram that is, or has been
received
4.3. Delivery
We identify several requirements for the packet delivery
that are essential to host groups being a useful and
facility
Firstly, given the predominance of broadcast local-area
and the locality of communication to individual networks,
delivery mechanism must be able to exploit the hardware'
capability for very efficient multicast within a single local-
network
Secondly, the delivery mechanism must scale in sophistication
efficient delivery across the Internet as it acquires high-
wide-area communication links and higher performance gateways
The former are being provided by the introduction of high-
satellite channels and long-haul fiber optic links. The
are made feasible by the falling cost of memory and
power plus the increasing importance in controlling access
relatively unprotected local network environments. A host
delivery mechanism must be able to take advantage of these
as they materialize
Finally, the delivery mechanism must avoid "systematic errors"
delivery to members of the host group. That is, a small number
repeated transmissions must result in delivery to all
Deering & Cheriton [Page 6]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
members within the specified distance, unless a member
disconnected or has failed. We refer to this property
coverage. In general, most reliable protocols make this
assumption for unicast delivery. It is important to
this assumption for multicast as well or else applications
multicast may fail in unexpected ways when coverage is
provided. For efficiency, the multicast delivery mechanism
also avoid regularly delivering multiple copies of a packet
individual hosts
Failure notification is not viewed as an essential requirement
given the datagram semantics of delivery. However, a host
extension to IP should provide "hint"-level failure
as the natural extension of the failure notification for unicast
5. Extensions to
This section discusses the specific extensions to the DARPA
Protocol required to support the host group model. The
need be implemented only on those hosts that wish to join host
or send to host groups; existing implementations are not affected
the proposed changes
5.1. Group
A portion of the 32-bit IP address space is reserved for
group addresses. The range of group addresses is chosen to
easily recognized and to not conflict with existing
addresses. Either Class A addresses with a
(currently unused) network number or Class D addresses (
starting with 111) would be suitable. The range of group
is further subdivided into a set of permanent group addresses
a set of temporary group addresses
Host group addresses may be used in the same way as
addresses in the source, destination, and options fields of
datagrams. An IP implementation adds to the list of its
individual addresses, the addresses of all groups to which
belongs. The source addresses of locally originated datagrams
validated against the list, and incoming datagrams which are
destined to an address on the list are discarded. The
on the list change dynamically as IP users create, join and
groups
Deering & Cheriton [Page 7]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
5.2. Group
To support the group management operations of CreateGroup
JoinGroup and LeaveGroup, an IP module must interact with one
more multicast agents which reside in neighbouring gateways
other special-purpose hosts. These interaction are handled by
Internet Group Management Protocol (IGMP) which, like ICMP [15],
is an integral part of the IP implementation. A
specification for IGMP is given in Appendix I
5.3. Multicast
In order to transmit a datagram destined to a host group, an
module must map the destination group address into a local
address. As with individual IP addresses, the mapping
is local-network- specific. On networks that directly
multicast, the IP host group address is mapped to a local
multicast address that includes all local members of the
group plus one or more multicast agents. For networks that do
directly support multicast, the mapping may be to a more
broadcast address, to a list of local unicast addresses,
perhaps to the address of a single machine that
multi-destination relaying
5.4. Distance
The existing Time to Live field in the IP header can be used
crude control over the delivery radius of multicast datagrams.
provide finer-grain control, a new IP option is defined to
the maximum delivery distance in "administrative units", such
"this network", "this department", "this company", "this country",
etc. The set of units and their encoding is to be determined
6.
In this section, we sketch a design for implementing the host
model within the Internet. This description of the design is
to further support the feasibility of the host group model as well
point out some of the problems yet to be addressed
Implementation of host groups involves implementing a
mechanism (binding Internet addresses to zero or more hosts) and
packet delivery mechanism (delivering a packet to each host to
its destination address binds). This facility fits most
into the gateways of the Internet and the switching nodes of
constituent point-to-point networks (as opposed to separate machines
because multicast binding and delivery is a natural extension of
Deering & Cheriton [Page 8]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
unicast binding and delivery (i.e. routing plus store-and-forward).
That is, a multicast packet is routed and transmitted to
destinations, rather than to a single destination
In the following description, we start with a basic,
implementation that provides coverage and then refine this
with various optimizations to improve efficiency of delivery
group management
6.1. Basic
A host group defines a network group, which is the set of
containing current members of the host group. When a packet
sent to a host group, a copy is delivered to each network in
corresponding network group. Then, within each network, a copy
delivered to each host belonging to the group
To support such multicast delivery, every Internet
maintains the following data structures
- routing table: conventional Internet routing information
including the distance and direction to the nearest
on every network
- network membership table: A set of records, one for
currently existing host group. The network membership
for a group lists the network group, i.e. the networks
contain members of the group
- local host membership table: A set of records, one for
host group that has members on directly attached networks
Each local host membership record indicates the local
that are members of the associated host group. For
that support multicast or broadcast, the record may
only the local network-specific multicast address used by
group plus a count of local members. Otherwise, local
members may be identified by a list of unicast addresses
be used in the software implementation of multicast
the network
A host invokes the multicast delivery service by sending
group-destined IP datagram to an immediate neighbour gateway (i.e
a gateway that is directly attached to the same network as
sending host). Upon receiving a group-destined datagram from
directly attached network, a gateway looks up the
membership record corresponding to the destination address of
datagram. For each of the networks listed in the
Deering & Cheriton [Page 9]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
record, the gateway consults its routing table. If, according
the routing table, a member network is directly attached,
gateway transmits a copy of the datagram on that network,
the network-specific multicast address allocated for the group
that network. For a member network that is not directly
the gateway creates a copy of the datagram with an
inter-gateway header identifying the destination network.
inter-gateway datagram is forwarded to the nearest gateway on
destination network, using conventional store-and-forward
techniques. At the gateway on the destination network,
datagram is stripped of its inter-gateway header and
to the group's multicast address on that network. The datagram
dropped by the relaying gateways whenever it exceeds its
limit
The network membership records and the network-specific
structures are updated in response to group management
from hosts. A host sends a request to create, join, or leave
group to an immediate neighbour gateway. If the host
creation of a group, a new network membership record is created
the serving gateway and distributed to all other gateways. If
host is the first on its network to join a group, or if the
is the last on its network to leave a group, the group's
membership record is updated in all gateways. The updates
not be performed atomically at all gateways, due to the
delivery semantics; hosts can tolerate misrouted and lost
caused by temporary gateway inconsistencies, as long as
inconsistencies are resolved within normal host
periods. In this respect, the network membership data is
to the network reachability data maintained by
routing algorithms, and can be handled by similar mechanisms
In many cases, a host joins a group that already has members
the same network, or leaves a group that has remaining members
the same network. This is then a local matter between the
and gateways on a single network: only the local host
table needs to be updated to include or exclude the host
This basic implementation strategy meets the delivery
stated at the end of Section 4. However, it is far from optimal
in terms of either delivery efficiency or group
overhead. Below, we discuss some further refinements to the
implementation
Deering & Cheriton [Page 10]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
6.2. Multicast Routing Between
Multicast routing among the Internet gateways is similar
store-and-forward routing in a point-to-point network. The
difference is that the links between the nodes (gateways) can be
mixture of broadcast and unicast-type networks with
different throughput and delay characteristics. In addition
packets are addressed to networks rather than hosts (at
gateway level).
We intend to use the extended reverse path forwarding algorithm
Dalal and Metcalfe [10]. Although originally designed
broadcast, it is a simple and efficient technique that can
well for multicast delivery if network membership records in
gateway are augmented with information from neighbouring gateways
This algorithm uses the source network identifier, rather than
destination network identifier to make routing decisions.
the source address of a datagram may be a group address, it
be used to identify the source network of the datagram; the
gateway must add a header specifying the source network.
approach minimizes redundant transmissions when
destination networks are reachable across a common
link, a problem with the basic implementation described above
Note that we eliminate from consideration techniques that fail
deliver along the branches of the shortest delay tree rooted
the source, such as Wall's center-based forwarding [16]
this compromises the meaning of the multicast distance
and detracts from multicast performance in general. We
rejected the approach of having a multicast packet carry more
one network identifier in its inter-gateway header to
multiple destination networks because the resulting
length headers would cause buffering and fragmentation problems
the gateways
6.3. Multicasting Within
A simple optimization within a network is to have the sender
the local multicast address of a host group for its
transmission. This allows the local host group members to
the transmission immediately along with the gateways (which
now "eavesdrop" on all multicast transmissions). A gateway
forwards the datagram if the destination host group
members on other networks. This scheme reduces the cost to
local group members to one packet transmission from two
Deering & Cheriton [Page 11]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
in the basic implementation <3> so transmission to local
is basically as efficient as the local multicast support
by the network
A similar opportunity for reducing packet traffic arises when
datagram must traverse a network to get from one gateway
another, and that network also holds members of the
group. Again, use of a network-specific multicast address
includes member hosts plus gateways can achieve the
effect. However, in this case, hosts must be prepared to
datagrams that include an inter-gateway header or, alternatively
every datagram must include a spare field in its header for use
gateways in lieu of an additional inter-gateway header
6.4. Distributing Membership
A refinement to host group membership maintenance is to store
host group membership record for a group only in those
that are directly connected to member networks. Information
other groups is cached in the gateway only while it is required
route to those other groups. When a gateway receives a
to be forwarded to a group for which it has no network
record (which can only happen if the gateway is not
connected to a member network), it takes the following action
The gateway assumes temporarily that the destination group
members on every network in the internetwork, except
directly attached to the sending gateway, and routes the
accordingly. In the inter-gateway header of the outgoing packet
the gateway sets a bit indicating that it wishes to receive a
of the network membership record for the destination host group
When such a datagram reaches a gateway on a member network,
gateway sends a copy of the membership record back to
requesting gateway and clears the copy request bit in
datagram
Copies of network membership records sent to gateways outside of
group's member networks are cached for use in
transmissions by those gateways. That raises the danger of
stale cache entry leading to systematic delivery failures.
counter that problem, the inter-gateway header contains a
which is a hash value or checksum on the network membership
used to route the datagram. Gateways on member networks
the checksum on incoming datagrams with their up-to-date records
If the checksums don't match, an up-to-date copy of the record
returned to the gateway with the bad record
This caching strategy minimizes intergateway traffic for
Deering & Cheriton [Page 12]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
that are only used within one network or within the set
networks on which members reside, the expected common cases
Partial replication with caching also reduces the overhead
network traffic to disseminate updates and keep all
consistent. Finally, it also reduces the total space required
all the gateways to support a large number of host groups
We have not addressed here the problem of maintaining up-to-date
consistent network membership records within the set of
connected to members of a group. This can be viewed as
distributed database problem which has been well studied in
contexts. The loose consistency requirements on
membership records suggest that the techniques used in
[3] might be useful for this application
7. Related
The use of unreliable multicast by higher-level protocols and
implementation of multicast within various individual networks
been well-studied (see [7] for references and discussion). However
there is relatively little published work on the use
implementation of internetwork multicasting
Boggs, in his thesis [4], describes a number of
applications that are impossible or very awkward to support
the flexible binding nature of broadcast addressing. Although
recognizes that almost all of his applications would be best
by a multicast mechanism, he advocates the use of "
broadcast" because it is easy to implement within many kinds
networks and can be extended across an internetwork without
any new burden on internetwork gateways. In RFC-919 [13],
proposes adopting directed broadcast for the DARPA Internet
Broadcasting has the undesirable side effect of delivering packets
more hosts than necessary, thus incurring overhead on
parties and possibly creating security problems. As more and
applications take advantage of broadcasting, the overhead on
hosts continues to rise. Clearly, broadcast does not scale up to
large internetwork. As an attempt to handle the scaling problem
directed broadcast is less attractive than true multicast because
set of hosts that can be reached by a single "send" operation is
artifact of the internetwork topology, rather than a grouping that
meaningful to the sender
In RFC-947 [12], Lebowitz and Mankins propose the use of
Deering & Cheriton [Page 13]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
repeaters that pick up broadcast datagrams from one network and
them to other networks for broadcast there. This technique is
less selective of its targets than Bogg's directed broadcast method
Aguilar [1] suggests allowing an IP datagram to carry
destination addresses, which are used by the gateways to route
datagram to each recipient. Such a facility would alleviate some
the inefficiencies of sending individual datagrams to a group, but
would not be able to take advantage of local network
facilities. More seriously, Aguilar's scheme requires the sender
know the individual IP addresses of all members of the
group and thus lacks the flexible binding nature of true multicast
broadcast
8. Concluding
We have described a model of multicast communication for
Internet. As an extension of the existing Internet architecture,
views unicast communication and time-to-live constraints as
cases of the more general form of communication arising
multicast. We have argued that this model is implementable in
Internet and that it provides a powerful facility for a variety
applications. In some cases, it provides a facility that is
for certain applications to work in the Internet environment.
other cases, it provides a more efficient, robust and possibly
elegant way of implementing existing Internet applications
We are currently implementing a prototype host group facility as
extension of IP. For practical reasons, this prototype
all group management functions and multicast routing outside of
Internet gateways, in special hosts called multicast agents,
are similar to the broadcast repeaters of Lebowitz and Mankins.
collection of multicast agents in effect provides a second
system on top of the existing Internet, for multicast purposes.
major costs of this separation are redundancy of routing
between gateways and multicast agents and the increased delay
unreliability of extra hops in the delivery path. Much of
routing information in the multicast agents must be "wired-in
because they do not have access to the gateways' routing tables
However, this rudimentary implementation provides an environment
evaluating the interface to the multicast service and
investigating group management and multicast routing protocols
eventual use in the gateways. It also serves as a testbed
porting multicast-based distributed applications to the Internet
For now, we are restricting group membership to local networks
already have a broadcast or multicast capability, such as
Deering & Cheriton [Page 14]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
Ethernet. We feel that, in the future, any network that is to
hosts other than just gateways must have a multicast addressing mode
Efficient implementation of multicast within point-to-point
virtual circuit networks deserves investigation
A significant issue raised by the host group model is
and access control in the Internet. Gateways must control
hosts can create and join host groups, presumably making
decision based on the identity of the requestor (thus
authentication) and permissions (access control lists). This
does not arise in conventional internetwork architectures
host addresses are administratively assigned with no notion
dynamic assignment and binding as provided by host groups.
believe that access control should be recognized as a proper
necessary function of gateways so as to protect the hosts of
networks from general internetwork activity. Thus, group
control can be subsumed as part of this more general mechanism
although more investigation of the general issue is called for
On a philosophical point, there has been considerable reluctance
make open use of multicast on local networks because it
network-specific and not provided across the Internet. We
originally of that school. However, we recognized that our "hidden
uses of multicast in the V distributed system were essential
we resorted to dramatically poorer solutions - wired-in addresses
We also recognized, as described in this paper, that an
multicast facility for the Internet was feasible. As a consequence
we now argue that multicast is an important and basic facility
provide in local networks and internetworks. Higher levels
communication, including applications, should feel free to make
of this powerful facility. Networks and internetworks
multicast should be regarded as deficient relative to the future (
present) requirements of sophisticated distributed applications
communication systems
Deering & Cheriton [Page 15]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
Appendix I. Internet Group Management Protocol (IGMP
The Internet Group Management Protocol (IGMP) is used between
hosts and their immediate neighbour multicast agents to support
allocation of temporary group addresses and the addition and
of members of a group
Like ICMP, IGMP is a required part of all IP implementations.
messages are encapsulated in IP datagrams, with an IP protocol
of 2. IGMP messages are formatted similarly to ICMP messages and
different IGMP message types are given values distinct from
message types, so that both protocols may share common
modules or, perhaps, be merged into a single protocol
IGMP interactions take the form of request-response transactions.
request message is sent by hosts to the permanent group of
immediate neighbour multicast agents. Multicast agents reply to
IP source address of a request. If no reply is received within
(currently unspecified) timeout interval, a host retransmits
request, up to some (currently unspecified) maximum number of times
IGMP transactions are considered idempotent, so that multicast
need not recognize and filter out duplicate requests nor
replies <4>.
The IGMP message formats and procedures are defined below, in
style used in the ICMP specification
Deering & Cheriton [Page 16]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
Create Group Request or Create Group Reply
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Access Key +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields
A Create Group Request message is sent with an individual
address of the sending host as its source, and the well-
group address of the multicast agents as its destination
The corresponding Create Group Reply is sent with those
addresses reversed
IGMP Fields
101 for Create Group
102 for Create Group
For a Create Group Request message, the Code field indicates
the group is to be restricted
0 =
1 =
For a Create Group Reply message, the Code field specifies
outcome of the request
0 = request
1 = request denied, no
Deering & Cheriton [Page 17]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
The checksum is the 16-bit one's complement of the one'
complement sum of the IGMP message starting with the IGMP Type
For computing the checksum, the checksum field should be zero
This checksum may be replaced in the future
An identifier to aid in matching Request and Reply messages
Sequence
A sequence number to aid in matching Request and
messages
Group
For a Create Group Request message, a value of 0.
For a Create Group Reply message, either a newly
group address (if the request is approved) or a value of 0 (
denied).
Access
For a Create Group Request message, a value of 0.
For a Create Group Reply message, either a pseudo-random 64-
number (if the request for a restricted group is approved)
0.
A Create Group Request message is sent to the the group
local multicast agents by a host wishing to allocate a
temporary group
If no Reply message is received within t seconds, the
is retransmitted. If no Reply is received after
transmissions, the request is deemed to have failed
The first Reply message to arrive, if any, specifies
outcome of the request. The request may be denied because
lack of resources (e.g. no table space in gateways or
temporary addresses in use).
Deering & Cheriton [Page 18]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
If the request is approved, the requesting host is
to be the first and only current member of the new host group
The Identifier and Sequence Number fields are used to match
Reply to the corresponding Request. The multicast agents
choose to use these values to minimize the chance of
more than one new group for a single request, for example
a Reply is lost and
Request is retransmitted. However, the multicast agents
be prepared to recover temporary group addresses
requiring explicit Leave Group Requests from all members;
may choose simply to allocate a new address for
retransmission and recover unused ones when needed <5>.
Deering & Cheriton [Page 19]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
Join Group Request or Join Group Reply
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Access Key +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields
A Join Group Request message is sent with an individual
address of the sending host as its source, and the well-
group address of the multicast agents as its destination
The corresponding Join Group Reply is sent with those
addresses reversed
IGMP Fields
103 for Join Group
104 for Join Group
For a Join Group Request message, the Code field contains 0.
For a Join Group Reply message, the Code field specifies
outcome of the request
0 = request
1 = request denied, no
2 = request denied, invalid group
3 = request denied, invalid access
Deering & Cheriton [Page 20]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
The checksum is the 16-bit one's complement of the one'
complement sum of the IGMP message starting with the IGMP Type
For computing the checksum, the checksum field should be zero
This checksum may be replaced in the future
An identifier to aid in matching Request and Reply messages
Sequence
A sequence number to aid in matching Request and
messages
Group
For a Join Group Request message, a host group address
For a Join Group Reply message, the same group address as
the corresponding request
Access
For a Join Group Request message, the access key allocated
the group was created (0 for unrestricted groups).
For a Join Group Reply message, the same access key as in
corresponding request
A Join Group Request message is sent to the the group of
multicast agents by a host wishing to join a specified
existing group. If no Reply message is received within
seconds, the Request is retransmitted. If no reply is
after n transmissions, the request is deemed to have failed
The first Reply message to arrive, if any, specifies
outcome of the request. The request may be denied because
an invalid access key, an invalid specified group address (e.g
non-existent group) or lack of resources (e.g. no table
in gateways).
The Identifier and Sequence Number fields are used to match
Reply to the corresponding Request. If a multicast
Deering & Cheriton [Page 21]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
receives a request from a host to join a group to which
already belongs, the agent approves the request, under
assumption that the request was a retransmission for a
Reply
Deering & Cheriton [Page 22]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
Leave Group Request or Leave Group Reply
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields
A Leave Group Request message is sent with an individual
address of the sending host as its source, and the well-
group address of the multicast agents as its destination
The corresponding Leave Group Reply is sent with those
addresses reversed
IGMP Fields
105 for Leave Group
106 for Leave Group
For a Leave Group Request message, the Code field contains 0.
For Leave Group Reply message, the Code field specifies
outcome of the request
0 = request
2 = request denied, invalid group
The checksum is the 16-bit one's complement of the one'
complement sum of the IGMP message starting with the IGMP Type
For computing the checksum, the checksum field should be zero
This checksum may be replaced in the future
Deering & Cheriton [Page 23]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
An identifier to aid in matching Request and Reply messages
Sequence
A sequence number to aid in matching Request and
messages
Group
For a Leave Group Request message, a host group address
For a Leave Group Reply message, the same group address as
the corresponding request
A Leave Group Request message is sent to the the group of
multicast agents by a host wishing to leave a specified
existing group. If no Reply message is received within
seconds, the Request is retransmitted. If no reply is
after n transmissions, the request is deemed to have succeeded
The first Reply message to arrive, if any, specifies
outcome of the request. The request may be denied only if
specified group address is invalid (e.g. an individual
than a group address.)
The Identifier and Sequence Number fields are used to match
Reply to the corresponding Request, as with other
transactions. If a multicast agent receives a request from
host to leave a group to which it does not belong, the
approves the request, under the assumption that the request
a retransmission for a lost Reply
Deering & Cheriton [Page 24]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
Notes
<1> In reality, Internet addresses (individual or group) are
to network interfaces or network attachment points, not the
machines per se
<2> In this procedure call notation, the arguments for an
are listed in parentheses after the operation name, and
returned values, if any, are listed after a --> symbol
<3> One unicast transmission from sender to gateway and
multicast transmission from gateway to local group
<4> This protocol may eventually be replaced by a more
reliable transaction protocol designed for this type
client/server interaction, as suggested in RFC-955 [5].
<5> Multicast agents can use an ICMP Echo message to determine if
group has any current members. The Echo message should
transmitted several times before deciding the group address
no longer in use
Deering & Cheriton [Page 25]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
[1] L. Aguilar. Datagram Routing for Internet Multicasting. In
SIGCOMM '84 Communications Architectures and Protocols,
58-63. ACM, June, 1984.
[2] E. J. Berglund and D. R. Cheriton. Amaze: A
multi-player game program using the distributed V kernel.
Proceedings of the Fourth International Conference
Distributed Systems. IEEE, May, 1984.
[3] A. D. Birrell et al. Grapevine: an exercise in
computing. Communications of the ACM 25(4):260-274, April
1982.
[4] D. R. Boggs. Internet Broadcasting. PhD thesis,
University, January, 1982.
[5] R. Braden. Towards a Transport Service for
Processing Applications. Technical Report RFC-919, SRI
Information Center, September, 1985.
[6] J-M. Chang. Simplifying Distributed Database Design by Using
Broadcast Network. In SIGMOD '84. ACM, June, 1984.
[7] D. R. Cheriton and S. E. Deering. Host Groups: A
Extension for Datagram Internetworks. In Proceedings of
Ninth Data Communications Symposium. ACM/IEEE, September, 1985.
[8] D. R. Cheriton and W. Zwaenepoel. Distributed Process Groups
the V Kernel. ACM Transactions on Computer Systems 3(3), May
1985.
[9] F. Cristian et al. Atomic Broadcast: from simple
diffusion to Byzantine agreement. In 15th
Conference on Fault Tolerant Computing. , Ann Arbor, Michigan
June, 1985.
[10] Y. K. Dalal and R. M. Metcalfe. Reverse Path Forwarding
Broadcast Packets. Communications of the ACM 21(2):1040-1047,
December, 1978.
[11] H. Forsdick. MMCF: A Multi-Media Conferencing Facility
personal communication
Deering & Cheriton [Page 26]
RFC 966 December 1985
Host Groups: A Multicast Extension to the Internet
[12] K. Lebowitz and D. Mankins. Multi-network Broadcasting
the Internet.Technical Report RFC-947, SRI Network
Center, June, 1985.
[13] J. Mogul. Broadcasting Internet Datagrams. Technical
RFC-919, SRI Network Information Center, October, 1984.
[14] J. Postel. Internet Protocol. Technical Report RFC-791,
Network Information Center, September, 1981.
[15] J. Postel. Internet Control Message Protocol. Technical
RFC-792, SRI Network Information Center, September, 1981.
[16] D. W, Wall. Mechanisms for Broadcast and Selective Broadcast
Technical Report 190, Computer Systems Laboratory,
University, June, 1980.
[17] J. K. Reynolds and J. Postel. Assigned Numbers.
Report RFC-960, SRI Network Information Center, September
1981.
Deering & Cheriton [Page 27]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
