IP Multicast

Introduction

With Unicast traffic one copy of a packet goes to each client so if there is a large group of clients a large number of the same packets take up bandwidth on the same network, particularly if the traffic is multimedia. Although this may sometimes be called 'Multicast', it is in fact 'Replicated Unicast'. A single video stream between a client and a server takes about 1.5Mbps of bandwidth. With broadcasts only one copy of a packet is sent to all clients but each client has to process the broadcast packet even if the packet is not relevant to them. Routers do not forward layer 2 broadcasts so 'Directed IP Broadcasts' would have to be used. Routers DO forward multicast packets.

Because multimedia traffic is large in volume it is impractical to expect all clients to look at all the multimedia broadcast packets. Multicast techniques use special multicast addresses that groups of clients can choose to listen to or ignore. This way we get the best of both worlds whereby only those clients that choose to be part of the group get to process the data. This group is identified by a single multicast IP address, the server does not know individual IP addresses so the clients remain anonymous. Multicast traffic is handled by UDP at the transport layer.

RFC 1112 describes the Host Extensions for IP Multicasting. This includes dynamic membership creation.

Multicast Addresses

The multicast address range is 224.0.0.0 to 239.255.255.255 and forms the Class D range which is made up of the high order bits 1110 followed by the 28 bit multicast group ID. There is no subnetting with these Class D addresses. A multicast group can have a permanently-assigned address or the group may be Transient. Well-known Class D addresses are assigned by the Internet Assigned Numbers Authority (IANA) and some of these are detailed in the following table:

Address	Purpose
224.0.0.1	All hosts on a subnet
224.0.0.2	All routers on a subnet
224.0.0.4	All DVMRP routers
224.0.0.5	All OSPF routers (DR Others)
224.0.0.6	All OSPF Designated Routers
224.0.0.7	ST Routers
224.0.0.8	ST Hosts
224.0.0.9	All RIPv2 routers
224.0.0.10	All EIGRP routers
224.0.0.11	Mobile-Agents
224.0.0.12	DHCP Server/Relay Agent
224.0.0.13	All PIM routers
224.0.0.14	RSVP Encapsulation
224.0.0.15	All CBT routers
224.0.0.18	VRRP
224.0.0.22	IGMPv3 Membership Reports
224.0.1.1	NTP
224.0.1.8	SUN NIS+
224.0.1.39	Cisco RP Announce
224.0.1.40	Cisco RP Discovery

(A full list of Multicast addresses can be found at http://www.iana.org/assignments/multicast-addresses and RFC 1700)

The range 224.0.0.0 to 224.0.0.255 are reserved for local purposes meaning that routers should not forward these datagrams since the applications that use these addresses do not need the datagrams to go further than one hop. The range 239.0.0.0 to 239.255.255.255 is reserved for administrative scoping (RFC 2365). This is where groups of routers agree an address range to and from which multicast traffic is prevented from entering or leaving a defined zone.

In order to do away with the need for ARP when resolving Ethernet MAC addresses to IP multicast addresses the IANA have reserved a block of Ethernet addresses that map on to the Class D multicast addresses. The reserved address 0x0100.5e00.0000 is used by Ethernet to determine a unique multicast MAC. The following diagram illustrates the mapping:

The low order 23 bits of the MAC address give a range of 0x0000.5e00.0000 to 0x0000.5eff.ffff. Half of these are used for multicast addresses and since the least significant bit of the first byte of a MAC address is the I/G bit (Individual/Group) this is set to 1 giving the hex value of 01 for the first octet of the multicast address. The range of MAC addresses used for multicast is therefore 0x0100.5e00.0000 to 0x0100.5e7f.ffff. The E comes from the fact that the LSB of the third octet is always 0.

The problem with this address mapping is that we have only got 23 bits in the MAC address and the IP multicast addresses have 28 bits. Only the least significant 23 bits of the IP multicast address are placed into the MAC address and the other 5 bits are ignored. This results in 2⁵ = 32 different multicast groups overlapping. An example is the Class D address 224.26.10.5 (binary = 11100000.00011010.00001010.00000101 which in hex is E0.1A.0A.05) and the Class D address 236.154.10.5 (binary = 11101100.10011010.00001010.00000101 which in hex is EC.9A.0A.05). Although the Class D multicast addresses are different you will see that they differ only in the 5 most significant bits, the 23 least significant bits remain the same so both these addresses map to the same MAC address of 0x0100.5E1A.0A05. Although mathematically there are 32 possibilities for overlap of addresses it is very unlikely to happen in real life and if it does, the impact is that another set of stations receives the multicast traffic. This is still far preferable to ALL stations receiving the traffic. Notice how that the second most significant octet in 224.26.10.5 differs from that in 236.154.10.5 by 128. This is always the case where two IP multicast addresses share the same MAC address.

Token Ring use one of the functional addresses for multicast addresses and have both the locally administered bit and the I/G bit set as well as the functional address bit set the address format is as follows:

Octet	1	2	3	4	5	6
Bits	11000000	00000000	0XXXXXXX	XXXXXXXX	XXXXXXXX	XXXXXXXX

The first two bits are the I/G and U/L bits and are set to 1 in this instance and therefore indicate that the address is a multicast/broadcast (Group) address and it is Locally administered. The first bit in the third octet is the Functional Address Indicator Bit and when it is set to 0, it indicates that the remaining bits form the functional address (used by the various Token Ring functions as detailed below). This results in a functional address such as 0xC000.0004.0000 (non-canonical) which happens to be the one used for multicasting in Token Ring. Be aware that the address 0xc000.0004.0000 is not used exclusively for multicasting! Some Token Ring NICs cannot deal with interrupting the CPU when multicast MACs are received so sometimes the only choice is to use the broadcast address 0xFFFF.FFFF.FFFF.

FDDI frame format corresponds to Ethernet other than they are transmitted 'little-endian' or non-canonical so that a Sniffer analysing the FDDI frames would not see the addresses 0x0100.5Exx.xxxx but 0x8000.7axx.xxxx.

Overview

The source of the multicast does not need to know to whom it is sending the traffic, nor does it have to be a member of the multicast group.

Once the client has determined the multicast group that it wishes to join (via means such as Session Description Protocol (SDP), Session Advertisement Protocol (SAP) etc.), the client then makes a join request. In a simple network, the multicast server (Source) converts the multicast address to the Ethernet group address and the clients (Receivers) participating in the multicast communication are configured to receive datagrams from the specified multicast address.

When more devices are involved across a more complex network then routers become involved and they need to be selective as to where they forward this traffic. A distribution tree is set up to manage the traffic flow through the switches and the routers. This tree aids in establishing a path.

Rather than entirely leave the task to routers, to look for hosts that want to join a particular group, the hosts can actively request to join or leave multicast groups. This aids in creating an efficiently 'pruned' distribution tree that enhances the efficiency of the network. In addition, where a number of routers take part in multicast routing, one router is elected as the 'Querier' i.e. the one that forwards the multicast stream.

Internet Group Management Protocol (IGMP)

IGMPv1

IGMP is a mechanism within IPv4 to let multicast routers know of hosts that members of multicast groups. IGMP operates on local network switches where the hosts connect. There are three versions of IGMP.

IGMPv1 described in RFC 1112 controls the flow of multicast traffic. Devices such as routers are called Queriers and belong to the same multicast group as the hosts receiving the data. These Queriers send messages to find out which devices are members of a particular multicast group. These devices respond to inform the Querier of its membership status.

IGMP uses IP protocol 2 and the router always sets the TTL to 1 so that it remains purely within the local network. The IGMPv1 packet is described below:

Type - Type 1 is a Host membership query and Type 2 is Host Membership report.
Checksum - this is the 16-bit one's complement of the one's complement sum of the 8-bit IGMP message.
Group Address - this is only in the Host Membership Report and contains the address of the group being reported.

IGMPv1 operation:

When a host wants to join a multicast group it sends an unsolicited Host Membership Report to the All-hosts Group Address 224.0.0.1. Normally a couple are sent at intervals of 10 seconds just to ensure that the router receives them and the other hosts.
Every 60 seconds the Querier (there could be a number of them with IGMPv1) sends Host Membership Queries (or General Query) to the All-hosts address 224.0.0.1 to discover which hosts belong to which multicast group. When a host receives a query it starts a countdown timer for each multicast group being asked about and for which it is a member. This countdown timer has a random value between 1 and 10 seconds and is not configurable.
When the timer reaches zero the host sends a membership report to all in the group including the Querier (using 224.0.0.1 again, unless the host receives a membership report from another host, in which case it cancels the timer. This is called Report Suppression and saves bandwidth since only one host per group sends a membership report.
If a router does not receive any reports after a number of queries it turns off the multicast stream since the group has timed out on a particular interface.

IGMPv2

IGMPv2 defined in RFC 2236 has some enhancements. The IGMPv2 packet is described below:

Type - 0x11 is a Membership Query, 0x12 is a Version 1 Membership Report, 0x16 is a Version 2 Membership Report and 0x17 is a Leave Report.
Maximum Response Time - The default is 10 seconds and this can be changed in increments of 0.1 seconds.
Group Address - 0 is a General Query whereas a multicast address in here means that it is a group-specific query.

IGMPv2 operation:

When routers first come on line they perform a Querier Election to determine the Querier for each network. When a multicast router first connects it sends a General Query. It keeps sending the General Query every 60 seconds whilst listening for other routers' General Queries. If it sees another router's General Query, it examines the IP address of the source router and if that address is lower than its own the router stops sending General Queries. Eventually, the last remaining router sending General Queries is the one with the lowest IP address and becomes the Querier for the network. The other Non-querier routers listen for queries all the time so that if they do not hear any for 120 seconds, the election process starts again. The Query-Interval Response Time controls the burstiness of reports.
Joining a multicast group in version 2 is the same process as version 1 by sending a host membership report to 224.0.0.1.
Using queries and reports the multicast router builds a table of the hosts in each multicast group on each interface. This table is called the Group Database and details the up time and the time left before expiry depending on Host Membership Reports.
As well as there being the General Query, the Group Specific Query has been introduced so that the router queries membership of specific groups using the group's multicast address rather than use the General Query to the all hosts address 224.0.0.1.
The group is maintained as in IGMPv1 with Membership Queries to the all hosts address 224.0.0.1 and the timers on the hosts randomly set.
When a host receives a Group-Specific Query for which it is a member then it sets the timer according to the randomly generated number provided that this number is less than the time left on an existing countdown if there is one from another query. The Maximum Response Time is a new field that can be set.
On expiry of the timer the host sends a Version 2 Membership Report.
If a host wants to leave a group it can now send a Leave Group Message to the All Routers Group address 224.0.0.2 (only the routers need to see this). This reduces the leave latency when the last host in a particular group leaves. The router can therefore cut short the multicast stream sooner than it would have happened with version 1 i.e. in version 1 the datastream would continue for a maximum of 60 seconds. The router does this by immediately sending a Group-Specific Query to check if there are any hosts left in that group before shutting down the multicast stream.

IGMPv3

IGMP version 3 is a major revision of the IGMP protocol. Described in RFC 3376 it allows receiver hosts to determine specifically which groups they will receive multicast data from and from which sources. This is called source filtering. The receiver has a filter list which it can use in one of two filter modes:

INCLUDE MODE - The receiver announces membership to a group and sends an Include list of IP addresses from which it will receive the multicast stream.
EXCLUDE MODE - The receiver announces membership to a group and sends an Exclude list of IP addresses from which it does not want to receive the multicast stream.

The benefits of IGMPv3 are that less multicast traffic will occur as the Include and Exclude lists limit the memberships. Related to that is that Denial of service attacks from unknown sources is less likely. Also IGMPv3 can be used with Source Specific Multicast (SSM). IGMPv3 has to be available in the routers, the switches and the hosts, otherwise it will not operate correctly and will revert to IGMPv2 or IGMPv1 operation as it is backwardly compatible.

The Membership Query message (0x11) has become more complex:

Type - 0x11 is a Membership Query, 0x12 is a Version 1 Membership Report, 0x16 is a Version 2 Membership Report, 0x17 is a Leave Report and 0x22 is a Version 3 Membership Report. In this case we are looking at 0x11, a Membership Query
Maximum Response Time - The default is 10 seconds and this can be changed in increments of 0.1 seconds.
Checksum - this is the 16-bit one's complement of the one's complement sum of the 8-bit IGMP message.
Group Address - a value of '0' is a General Query whereas a multicast address in here means that it is a group-specific query.
Reserved - set to '0'
Suppress Router-side processing (S) - if set to one, the 'S' Flag tells the receiving multicast router that is to to suppress the normal timer updates it performs when hearing a Query.
Querier Robustness Variable (QRV) - multicast routers take on the value sent by the previous querier up to a value of '7'.
Querier's query Interval Code (QQIC) - is a code value for the query interval used by the querier. If the interval is less than 128 seconds then the 8 bit field represents the number of seconds directly. If the interval is equal to or greater than 128 seconds then this code is made up of binary '1' in the first bit, the exponent in the next three bits and the mantissa in the final four bits
Number of sources (N) - the number of source addesses in the query
Source addresses - a list of 'N' source addresses

The query message sent by the multicast routers can be one of three forms:

General Query - group address and source address fields are zero
Group-Specific Query - group address field contains the group address, whereas the address fields are zero
Group-and_Source-Specific Query - group address field contains the group address, and the source address fields contain the sources that are emanating the multicast streams

The Membership Report message (0x22) is new:

Type - 0x11 is a Membership Query, 0x12 is a Version 1 Membership Report, 0x16 is a Version 2 Membership Report, 0x17 is a Leave Report and 0x22 is a Version 3 Membership Report. In this case we are looking at 0x22, a Membership Report
Reserved - set to '0'
Checksum - this is the 16-bit one's complement of the one's complement sum of the 8-bit IGMP message.
Reserved - set to '0'
Number of Group Records (M) - the number of group records in this query
Group Record
- Record Type
- Aux Data Length - in units of 32-bit words, this must be zero at the moment because this is only for future use!
- Number of sources (N) - the number of source addresses
- Multicast address of this group record
- Source addresses - the source of the multicast streams

There are a number of Group record types:

Current-state-record - which could be MODE_IS_INCLUDE or MODE_IS_EXCLUDE representing the filter state of the interface when filtering the source addresses to include or exclude when joining this group records group address.
Filter-mode-change-record - indicating a filter mode change, either CHANGE_TO_INCLUDE_MODE or CHANGE_TO_EXCLUDE_MODE.
Source-list-change-record - either ALLOW_NEW_SOURCES or BLOCK_OLD_SOURCES

IGMPv3 membership reports are sent to the address 224.0.0.22, all IGMPv3 capable routers listen on this address.

Cisco Group Multicast Protocol (CGMP)

Layer 2 switches on seeing the multicast MAC address will naturally forward this unknown address out of ALL its ports. This loads the switch up and results in multicast traffic being unnecessarily sent to hosts that have not requested it.

IGMP Snooping

One method is IGMP Snooping where the switch has the intelligence to examine all the multicast queries and reports to determine the port mappings of the group members. Using this information it then rewrites its own forwarding tables. This is processor intensive for the switch and the router has all this information already.

Manual Configuration

Another method is to manually configure multicast MAC addresses within the switch forwarding table, however this can be tedious, prone to error and inflexible.

GMRP

As part of 802.1p and therefore an open standard, GARP Multicast Registration Protocol (GMRP) allows dynamic learning of multicast MAC addresses within a switch.

CGMP

Cisco's proprietary Cisco Group Management Protocol (CGMP) takes the multicast information, such as which hosts are members of which groups, and allows the routers/layer 3 switches to directly write the information to the layer 2 forwarding tables of the switches so that the switches can dynamically switch the IP multicasts at switch speed. If non-Cisco routers are using multicast, say with Distance Vector Multicast Routing Protocol (DVMRP), then although Cisco does not fully support DVMRP, the router will 'proxy' for these other routers and feed this information into the switches configured for CGMP.

In CGMP, the multicast router is considered to be the server since it has done all the work and the layer 2 switch is the CGMP client that uses the router's information to construct its forwarding tables (CAM) i.e. the router produces the CGMP packet and the switch reads it.

A CGMP router starts by sending a Join packet with the Group Destination MAC Address set to all zeros (meaning all multicast groups) and the source address as its own MAC address. This packet is sent every 60 seconds so that connected switches know that a CGMP router is online.

The CGMP packet looks as follows:

Version - Always set to 0x1.
Type - Either Join (0x0), or Leave (0x1).
Reserved - Always set to 0x0000.
Count - How many GDA/USA pairs are in the packet.
Group Destination Address (GDA) - MAC address of multicast group.
Unicast Source Address (USA) - MAC address of group member.

When a multicast router sees a client's IGMP packet it creates a CGMP packet. It maps the client's MAC address to the multicast MAC address within the CGMP packet. The CGMP packet contains a type field (Join or Leave a multicast group), the MAC address of the IGMP client and the multicast address of the group. The router is considered a CGMP server and the switch is the CGMP client. CGMP multicast packets are sent to the switches using the well-known multicast address 0x0100.0cdd.dddd. The switches take the CGMP mapping information and the forwarding table is programmed accordingly because the switch knows which client MAC address needs to see data from the multicast MAC address and adds the port to its list of forwarding ports for that particular mulicast group. Similarly, when a client wishes to leave a multicast group, a CGMP Leave message is created by the router and this results in the switch removing the client port from the forwarding table, thereby minimising the traffic throughput.

Multicast Routing

So far we have looked at the local Host to router connection. We now look at how the routers talk to one another to route the multicast traffic. There are multicast Interior Gateway protocols (IGP) and multicast Exterior Gateway Protocols (EGP). Multicast IGPs are considered below and include DVMRP, MOSPF, CBT, PIM-DM and PIM-SM. Multicast EGPs are still being developed but will more than likely take names such as MBGP, in the meantime MSDP and Anytime RP are used when multicasting between ASs.

The multicast address identifies a transmission session rather than a specific host. Routers need to exchange information about multicast sessions and groups with each other so that if one router does not have any clients in a particular session it knows a router that does.

For efficient transmission a distribution tree of routers is created where all members of a particular multicast group are connected only once, so that there are no loops and therefore no packet duplication. Multicast packets then only flow downstream, from the Source to the Group destination. Each router knows which multicast groups exist on which interface and creates the branches accordingly. As the multicast members join and leave so branches are added and pruned. In order to do this the router maintains a multicast forwarding table made up of (Source, Group) pairs of addresses i.e. the Source address of the multicast stream and the Group address to which the traffic is destined. The router receives the traffic on an upstream interface and sends it out of the downstream interface(s) so each (S,G) pair will have an Outgoing Interface list (OIL). So this distribution tree has the router that is directly connected to the Source of the multicast, as the core of the tree, and this tree is dynamically changing all the time as multicast sessions start and finish.

The Source-Specific Tree finds the shortest path from each sender to each receiver by building a Spanning Tree for each source. PIM calls this the Shortest Path Tree (SPT). A technique called Reverse Path Forwarding (RPF) is used where packets arriving on a link (Parent Link) that is believed to be the shortest path back to the Source, are forwarded on all the other interfaces that are part of the distribution tree as determined by IGMP/GMRP. The outgoing interface is sometimes referred to as the Child Link. If a packet arrives from a source but on another link that is not considered to be the shortest route then it is dropped. Typically the Root router is as close to each source as possible. The Root router is analogous to the Root bridge in Spanning Tree in a per VLAN Spanning Tree environment i.e. there is a separate tree for each multicast group. The good thing about the Source-Specific Tree is that it avoids duplication of packets, you would want that for a video stream for instance.

The Shared Distribution Tree makes use of distribution centres (made up of one or more routers) to create a single multicast tree which is used to distribute multicast traffic for all groups. PIM calls this the Rendezvous Point Tree (RPT). Devices wishing to receive multicast traffic must join the shared tree.

Because multicast traffic is inherently bandwidth hungry it is a good idea to use the TTL field to limit the scope of the multicast traffic i.e. the limit to how far the multicast trees can grow. The MBone has recommendations for TTL scoping.

A TTL of 0 means that the packet never leaves the host.
1 restricts the packet to the subnet.
15 restricts the packet to the same site or organisation.
63 restricts the packet to the same region
127 is worldwide.
191 is worlwide with limited bandwidth
255 is unrestricted.

The router will only forward a multicast packet out of an interface if the TTL field in the packet is greater than the TTL Threshold configured on the interface.

Another way to limit the spread of multicast sessions is to use address or administrative scoping. The address range 239.255.0.0/16 is suggested to be used for local scoping and the address range 239.192.0.0/14 for organisational scoping. This is recommended in RFC 2365. The address range 239.0.0.0-239.255.255.255 must therefore be filtered from reaching the Internet because these are non-unique, in the same way that RFC 1918 addresses need to be filtered.

Dense Mode Routing Protocols

These protocols assume that group members are densely populated throughout the network and that there is plenty of bandwidth so that they can have periodic flooding of the network in order to set up and maintain the distribution tree. A typical Dense environment could be a LAN. These protocols send the packet everywhere unless told not to and then they prune back where there are no group members. Examples of Dense Mode multicast routing protocols include Distance Vector Multicast Routing (DVMRP), Multicast Open Shortest Path First (MOSPF) and Protocol Independent Multicast Dense Mode (PIM DM).

Distance Vector Multicast Routing (DVMRP)

Currently used across the Internet Multicast Backbone or MBONE, DVMRP use reverse path flooding i.e. when it receives a packet it floods the packet out of all interfaces except the one that leads back to the source. Prune messages are sent up the distribution tree to prevent subsequent packets travelling to where no members exist. Periodic flooding occurs as DVMRP tries to establish if there are any other potential new group members.

To determine which interfaces lead back to the source DVMRP uses a unicast hop-based routing protocol which is similar to RIP.

RFC 1075 describes DVMRP.

Multicast Open Shortest Path First (MOSPF)

MOSPF depends on OSPF running and includes multicast information in OSPF Link State Advertisements. MOSPF builds a distribution tree for each Source/Group pair and a tree for the active sources. These trees are held in a cache and are updated everytime that there is a link change. An unstable environment with many source/group pairs would be most unsuitable for MOSPF so it does not scale well.

RFC 1584 describes MOSPF.

Protocol Independent Multicast Dense Mode (PIM DM)

This protocol operates in the same way that DVMRP does except that it is not dependent on a unicast routing protocol.

PIMv1 uses IP protocol 2 and queries are multicast to all routers using 224.0.0.2 every 30 seconds by default (PIMv2 sends queries to all PIM routers on 224.0.0.13 and uses IP protocol 103). On a multiaccess network like Ethernet a Designated Router is elected (the highest IP address wins) and this router is the one that sends IGMP host query messages on a LAN.

PIM first floods the multicast packets to all routers and then prunes those that do not have members of particular groups or if the path to members is redundant and not the shortest route. Ideally senders and receivers should be close to one another and the ratio of receivers to senders should be large. Dense mode is fine if the volume of multicast traffic is large and constant.

Sparse Mode Routing Protocols

If bandwidth is low and the group members are sparsely distributed then a Sparse Mode protocol is more appropriate.

Flooding will cause problems so more selective techniques are used to create the trees. The trees start off empty of any branches until there are explicit requests to join the distribution tree i.e. no packets are sent unless specifically asked for them.

Two sparse mode routing protocols are Core-Based Trees (CBT) and Protocol Independent Multicast Sparse Mode (PIM SM).

Core-Based Tree (CBT)

A single tree is constructed that is shared by all members of a group and all multicast traffic is sent over this tree regardless of the source i.e. the sources share the tree. This means that individual routers do not have to maintain such a high level of multicast information.

A Core router takes responsibility for constructing the tree and the other routers join the tree by sending join messages to this core router. The core sends a join acknowledgement over the reverse path thus forming a branch. If a router already on a branch receives a join message then it acknowledges the message instead of the core router, thereby minimising traffic.

RFC 2201 describes CBT.

Protocol Independent Multicast Sparse Mode (PIM SM)

If multicast traffic is intermittent and there are few receivers then the idea of Rendezvous Points (RP) is introduced. If a source wants to send data it first sends it to the Rendezvous Point (another router designated as such). When a receiver wants to receive this data it registers with the Rendezvous Point, this is the Explicit Join Model. At this point data flows and the sender and receiver work out the most direct route between themselves automatically. The first-hop router receives PIM register messages by hosts wanting to send data to a group. These register messages are sent to the RP. The last-hop routers send PIM join or prune messages to the RP.

You can think of the Rendezvous Point as the root of a shared distribution tree. In fact, multiple shared trees are built around the Rendezvous Point.

With Source trees, Reverse Path Forwarding (RPF) only accepts multicast traffic if it is received on an interface that has the route to the source out of that interface. With Shared trees, multicast traffic is only accepted when it is received on an interface that has the route to the RP.

PIM can support Dense Mode for some multicast groups and Sparse Mode for others. If no Rendezvous Point is found then Dense Mode could be used instead. An RP can act for many groups and one group can have multiple RPs.

RFCs

RFC 988 describes the now obsolete version 0 of IGMP.
RFC 1112 describes the Host Extensions for IP Multicasting (IGMP).
RFC 2365 describes Administratively Scoped IP Multicast.

Home

Disclaimer