Host Extensions for IP Multicasting
Deering
network routing multicast
@misc{deering:ietf-1989,
author={S. E. Deering},
title={Host Extensions for {IP} Multicasting},
series={Request for Comments},
number={1112},
howpublished={{RFC} 1112 (Proposed Standard)},
publisher={IETF},
organization={Internet Engineering Task Force},
year={1989},
month={August},
url={\url{http://www.ietf.org/rfc/rfc1112.txt}},
note={Updated by RFC 2236}
}
Host Extensions for IP Multicasting. Deering. RFC 1112
- Coordination and forwarding between routers is not addressed in this RFC, just host requirements.
- Multicast groups are identified by Class D IP addresses, those with 1110 as their high order bits
- This ranges from 224.0.0.0 to 239.255.255.255
- 224.0.0.0 is guaranteed to not be assigned
- 224.0.0.1 is assigned to all IP hosts, including gateways
- pg 3, interesting figure, note placement of IP-to-local mapping:
| |
| 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) |
| |
- Multicast datagrams sent using same "Send IP" operation as unicast
- Desirable but not necessary extensions for sending: Multicast TTL, identification of interface to use, inhibit local delivery of datagram
- Must recognize group IP addresses and route out interfaces appropriately
- "The IP source address of the outgoing datagram must be one of the individual addresses corresponding to the outgoing interface."
- And it only goes out one interface
- To receive, must provide join & leave group functions
- Host components of IGMP version 1:
- Routers issue Host Membership Query messages to the all-hosts group
- For each group it belongs to, the host sets a timer for a random interval; when that timer expires, it issues a Host Membership Report for that group
- Membership reports are addressed to the group being reported; if a host overhears a membership report for one of its groups, it kills that timer and squelches its own report
- Hosts also generate membership reports upon joining a group (actually, one, two, or more reports, in case some are dropped)
- This is clearly all messier on a MANET