|
|
IP
Extension for Multicast
This page is a summary of RFC
1112.
Conformance
There are 3 levels of conformance to the specification of
multicast;
Level 0 |
No support for IP Multicasting. Hosts of this nature are uneffected
my multicast activity. The exception is in the present of Level 1 or
2 hosts where misdelivery of multicast datagrams to level 0 hosts may
occur. These data grams can be easily identified by the presence of
Class D IP address in their destination field and so should be discarded
by hosts that are level 0. |
Level 1 |
Hosts may partake in some multicast based services, such as resource
location or status reporting, but may not join any host groups. |
Level 2 |
Hosts may join and leave host groups as well as send IP datagrams
to host groups. It requires the implementation of Internet Group Management
Protocol (IGMP) and externsion of hte IP and flocal network service
interfaces within the host. |
Host Group Addressing
Internet Host group addresses are identified by class D IP addresses (ie
1110 as their high order four bits). In the standard dotted decimal notation,
x.0.0.0 is guranateed not to be assigned to any groiup, and x.0.0.1 is assigned
to the permenant group of all IP hosts (including gateways). This is used
to address all multicast hosts on the directly connected network.
Host Group Addresses - The binding of an IP host group address to a physical
network may be considered as a generalisation of unicast addressing. A IP
host group address is dynamically bound to a set of local network interfaces
on a set of IP networks - NOT to a set of IP unicast addresses. The multicast
routers do not need to maintain a list of individual members to a host group.
Transient Host Group Addresses - A transient group are IP multicast addresses
that are not reserved for permanent groups and are dynamically assigned
(as long as they have members).
TBA
Multicast Extension to IP
| |
| Upper-Layer Protocol Modules |
|__________________________________________________________|
--------------------- IP Service Interface -----------------------
__________________________________________________________
| | | |
| | ICMP | IGMP |
| IP |______________|______________|
| Module |
| |
|__________________________________________________________|
---------------- Local Network Service Interface -----------------
__________________________________________________________
| | |
| Local | IP-to-local address mapping |
| Network | (e.g., ARP) |
| Modules |_____________________________|
| (e.g., Ethernet) |
| |
|
In this model, ICMP and IGMP (for level 2 hosts) are implemented within
the IP module. The mapping of IP addresses to local network addresses is
the resonbility of local network modules.
To provide level 1 multicasting, the host IP implemenation must support
the transmission of IP multicast datagrams.
Extension |
Sending Multicast IP Datagrams |
Receiving Multicast IP
Datagrams |
IP Service Interface |
Sent using the same 'Send IP' operation for unicast IP datagrams
- an upper level protocol modules merely specifies an IP host group
address. Certain extensions may be necessary and or desireable;
1) The service interface should procide a way for aupper-layer protocol
to specify the IP time-to-live. It should default to 1 such tha an
explicit choice is required.
2) For hosts that may be attatched to one or more networks, the service
interface should provide a way for the upper-layer protocol to identify
which network interface is to be used for multicast transmission.
Only multicast routers should be responsible for forwarding to other
networks.
3) For level 2 only, when a host is itself a member of a groupto
which a datagram is being sent, the service interface should provide
a way for upper-layer protocol to inhibit local delivery of the datagram,
ie prevent loopback.
|
Incoming multicast IP datagrams are received by upper-layer protocol
modules using the same 'Receive IP' operation as with unicast datagrams.
Selection of destination upper-layer protocals is based on the protocol
field in the IP header. However, before any datagrams destined for
a particular group is received, an upper-lay protocol must ask the
IP module to join that group. Hence two new operations must be included
in the IP serivice interface - JoinHostGroup and LeaveHostGroup. Both
operations should return immediately (non-blocking) indicating success
or failure.
It is permissible to joing the same group on more than one interface
(should the host have more than one interface). It is also permissible
for more than one upper-layer protocol to request membership in the
same group.
|
IP Module |
Must be extended to recognise IP host group addresses when routing
outgoing datagrams. This may need a change in the logic of the IP
implementation to include host group recognition and forwarding.
The IP source address must be one of the individual addresses corresponding
to the outgoing interface.
The host group address field should NOT be published in the source
address field, or anywhere in a source route or recod route option.
|
A list of host group memberships associated with each network interface
should be maintained. Processing of incoming datagrams is the same
as that of unicast tranmissions.
Should datagrams be received by the hosts which do not belong to
that group, the datagram should be discarded without log nor error.
This is also true if a datagram is received on the wrong interface
on the correct host. Similarly, an incoming datagram with an IP host
group address in its source address field is also discarded. ICMP
error messages are never generated in response to a datagram destined
to an IP host.
List of group host memberships is updated in response to JoinHostGroup
and LeaveHostGroup. Each membership should have an associated reference
count or similar to handle multile requests to join and leave the
same group. Upon the first and last request to Join and Leave a group
respectively, the local network module for the interface should be
notified (to update its multicast reception filter)
The IP Module must also implement the IGMP protocol. IGMP is used
to is used to keep neighbouring multicast routers informed of the
host group memberships present on a particular network. In order to
support IGMP, every level 2 host must join the 'all-hosts' group (x.0.0.1)
on each network interface at initialisation and remain a member whilst
the host is active. Datagrams addressed to the all-hosts network are
recognised as a special case and never forwarded beyond a single network,
regardless of their ttl.
|
Local Network Serive Interface |
No change. |
Incoming multicast packets are delievered to the IP module using
the same 'Receive Local' operation as local network unicast packets.
To allow the IP module to tell the local network module which multicast
packets to accept, the local network service interface is extended
to provide two new operations: JoinLocalGroup and LeaveLocalGroup,
both with parameter group-address (IP host group address).
The local network module is expected to map the IP host group addresses
to local network addresses as required to update its multicast reception
filter.
The local network module must not deliver up any mlticast packets
that were transmitted from that module - loopback of multicasts is
handled at the IP layer or higher.
|
Ethernet Local Network Module |
Ethernet directly supports the sending of local multicast
packets. However, a method for the sending of IP multicast datagrams
through the mapping of IP host addresses to Ethernet multicast addresses
is required. |
To support multicast IP datagrams, an Ethernet module
must be able to receive packets addressed to the Ethernet multicast
address that corresponds to the hosts IP host group addresses. |
Other Local Network Modules |
Networks that directly support multicasting need only to be mapped
to the host group. For networks that support broadcast, but not multicast
(eg Experimental Ethernet), all IP host group addresses may be mapped
to a single local broadcast address.
For point to point links (such as those joining to hosts or a host
and a multicast router), multicasts should be transmitted exactly
like unicasts.
For store and forward networks (ARPANET or public X.25) all IP host
group addresses may be mapped to the well-known address of an IP multicast
router - this router would take responsibility for completing multicast
delivery.
|
Other multicast networks, such as IEEE 802.2 networks,
can be handled in the same way as Ethernet for hte purpose of receiving
multicast IP datagrams. For pure bradcast networks (eg Experimental
Ethernet) all incoming broadcast packets can be accepted and passed
to the IP module for IP-level filtering. On point to point and store
and forward networks, multicast IP datagrams will arrive as local network
unicasts, so no cahnage to the module is necessary. |
Thu, 18 October, 2001 16:46
|
  |
|
|
|
© 2001-2003, Yee-Ting Li, email: ytl@hep.ucl.ac.uk,
Tel: +44 (0) 20 7679 1376, Fax: +44 (0) 20 7679 7145
Room D14, High Energy Particle Physics, Dept. of Physics & Astronomy,
UCL, Gower St, London, WC1E 6BT |
|