Multicasting Concepts, Algorithms, and Protocols

Husnain Ahmad

Muhammad Yasir

1

Multicasting

Concepts, Algorithms, and Protocols

This is a report on Multicasting technique. In the first section we describe the general concepts

surrounding the theory of Multicasting. Then it describes the multicast protocols such as DVMRP,

MOSPF, and PIM as well as the algorithms used in these protocols such as RPM and CBT. IGMP is

also surveyed in this report. The Multicast Backbone (MBone), a real-world multicast network, is

also explored. After that an innovative and evolving approach of putting the whole burden of

multicasting toil on the application layer instead of network layer is also added to this report. Finally,

a complete list of references is provided.

MULTICASTING

2

Table of Contents Page No.

Introduction 3

Multicast Group Concept 3

Multicast Addressing 3

Addressing Technique 3

Ethernet MAC Address Mapping 4

Internet Group Management Protocol (IGMP) 5

IGMP Packet Format 5

IGMP Versions 6

Multicast Routing Algorithms 7

Flooding 7

Spanning Trees 7

Reverse Path Broadcasting (RPB) 8

Truncated Reverse Path Broadcasting (TRPB) 9

Reverse Path Multicasting (RPM) 9

Core-Based Trees (CBT) 10

Multicast Routing Protocols 11

Distance Vector Multicast Routing Protocol (DVMRP) 11

Multicast Extensions to OSPF (MOSPF) 11

o Intra-Area Routing 11

o Inter-Area Routing 12

o Inter-AS Routing 12

Protocol Independent Multicast (PIM) 12

o PIM-Dense Mode 12

o PIM-Sparse Mode 13

MBone 14

Future Research in Multicasting 15

3

Introduction

In computer networking, multicast is the delivery of a message or information to a group of destination

computers simultaneously in a single transmission from the source creating copies automatically in other

network elements, such as routers, only when the topology of the network requires it.

Multicasting can also be understood as to transmit a single message to a select group of recipients. A

simple example of multicasting is sending an e-mail message to a mailing list.

Multicast was originally a product of IP networks. Some applications such as Internet television, Internet

gaming, and IP teleconferencing applications, require data to be delivered from one or multiple senders to

multiple receivers. A service whereby data is delivered from one or multiple sender nodes to multiple

designated receiver nodes is called multipoint communication or multicast, and applications that involve

a multicast delivery service are called multicast applications. On the Internet there are two types of

addresses: unicast and multicast. A host or node on the Internet normally has only one unicast address

but can be a member of many multicast groups.

Another place where multicasting can be very helpful is in resource discovery. There are many

applications in which a host needs to find out whether a certain type of service is available or not. Internet

protocols such as Bootstrap Protocol (BOOTP) and Open Shortest path First (OSPF) protocol are among

these applications. Using multicast messages and sending the query to those hosts which are potentially

capable of providing this service would be of great help. Although some applications use multicast

messages to transmit a packet to a group of hosts residing on the same network, there is no reason to

impose this limitation. Discovering the domain-name server is where multicast messages need to be

forwarded on remote networks if there is less than one server per network. The scope of multicast packets

can be limited by using the time-to-live (TTL) field of these packets.

Multicast Group Concept

Multicast is based on the concept of a group. An arbitrary group of receivers expresses an interest in

receiving a particular data stream. This group does not have any physical or geographical boundaries—the

hosts can be located anywhere on the Internet. Hosts that are interested in receiving data flowing to a

particular group must join the group using IGMP. Hosts must be a member of the group to receive the

data stream.

Multicast Addressing

For delivering a message to a group of destination nodes which are not necessarily in the same sub

network, multicast addresses are used. While Class A, B, and C IP addresses are used for unicast

messages, Class D addresses (224.0.0.0 - 239:255.255.255) are employed by multicast messages.

Addressing Technique

The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast addresses. It

has assigned the old Class D address space to be used for IP multicast. This means that all IP multicast

group addresses will fall in the range of 224.0.0.0 to 239.255.255.255.

4

But we should remember that this address range is only for the group address or destination address of IP

multicast traffic. The source address for multicast datagrams is always the unicast source address.

The IANA has reserved addresses in the 224.0.0.0 through 224.0.0.255 to be used by network protocols

on a local network segment e.g. to exchange link state information.

The range of addresses from 224.0.1.0 through 238.255.255.255 is called globally scoped addresses. They

can be used to multicast data between organizations and across the Internet. However a few addresses

from this range are also reserved for special purposes.

Ethernet MAC Address Mapping [1]

The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in hexadecimal. Half of this

block is allocated for multicast addresses. This allocation allows for 23 bits in the Ethernet address to

correspond to the IP multicast group address. The mapping places the lower 23 bits of the IP multicast

group address into these available lower 23 bits in the Ethernet address as depicted in figure 1.

Figure 1: Mapping of a class D IP address into Ethernet multicast address [5]

5

Because the upper 5 bits of the IP multicast address are dropped in this mapping, the resulting address is

not unique. In fact, 32 different multicast group IDs (as five bits are dropped hence 25=32) all map to the

same Ethernet address. This causes ambiguity in Mac Addresses as shown in figure 2.

Figure 2: MAC Address Ambiguities [1]

Internet Group Management Protocol (IGMP)

IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Hosts

identify group memberships by sending IGMP messages to their local multicast router. Under IGMP,

routers listen to IGMP messages and periodically send out queries to discover which groups are active or

inactive on a particular subnet. Hence we can also say that the protocol through which hosts

communicates information with their local routers for the case of multicasting is called Internet Group

Management Protocol (IGMP). After receiving a multicast packet sent to a certain multicast group, the

router will check and see if there is at least one member of that particular group on its subnetwork. If that

is the case the router will forward the message to that subnetwork. Otherwise, it will discard the multicast

packet.

The most fundamental idea to multicasting is the concept of joining and leaving multicast groups. The

IGMP provides a method through which a host can join or leave a multicast group.

With the passage of time more and more research in Multicast field internet has seen three different

versions of IGMP version 1, 2 and 3.

IGMP Packet Format

IGMP messages are always sent with a TTL of 1 and are IP-encapsulated. The next figure shows the IGMP

version 2 packet format. The IGMP version 1 packet format is a little different than the format of version

2. The IGMP version 1 packet splits the Type field in version 2 into two parts, to include both the version

number and the type.

6

Figure 3: IGMP Packet Format [9]

The Type field [9] indicates different types of IGMP packets:

Type 11 is the IGMP membership query.

Type 12 is the IGMP version 1 membership report.

Type 16 is the IGMP version 2 membership report.

Type 17 indicates the IGMP version 2 leave group.

There are other types also but the above stated are generally the most important ones.

The Maximum Response Time field is used only in membership query messages. It specifies the

maximum time in units of 1/10 of a second that a host might wait to respond to a query message.

The Checksum field is the checksum of the IGMP message to verify packet integrity.

The Group Address field contains the multicast group that the receiver is interested in receiving. When

the general IGMP query is sent, this group address field is set to 0.

IGMP Version 2 works basically the same as Version 1. The main difference is that there is a leave group

message. The hosts now can actively communicate to the local multicast router their intention to leave the

group. The router then sends out a group-specific query and determines whether there are any remaining

hosts interested in receiving the traffic. If there are no replies, the router times out the group and stops

forwarding the traffic. This can greatly reduce the leave latency compared to IGMP Version 1 where the

router has to figure out by itself for the leave of any member by sending membership queries. When there

is no reply to three consecutive IGMP membership queries, the router times out the group and stops

forwarding traffic directed toward that group. Hence a lot of unwanted and unnecessary traffic can be

stopped much sooner.

Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest

in receiving packets *only* from specific source addresses, or from *all but* specific source addresses,

sent to a particular multicast address. That information may be used by multicast routing protocols to

avoid delivering multicast packets from specific sources to networks where there are no interested

receivers.

7

Multicast Routing Algorithms

Several algorithms have been proposed for building multicast trees through which the multicast packets

can be delivered to the destination nodes. These algorithms can be potentially used in implementing the

multicast routing protocols. In this section, we will review comparatively two simpler algorithms called

Flooding and Spanning Trees. Then, we will discuss more sophisticated algorithms such as Reverse Path

Forwarding (RPF), Truncated Reverse Path Forwarding (TRPF), Steiner Trees (ST), and Core-Based Trees

(CBT).

Flooding

The Flooding algorithm which has been already used in protocols such as OSPF is the simplest technique

for delivering the multicast datagrams to the routers of an internetwork. In this algorithm, when a router

receives a multicast packet it will first check whether it has seen this particular packet earlier or this is the

first time that this packet has reached this router. If this is the first time, the router will forward the

packet on all interfaces, except the one from which the packet has been received. Otherwise, the router

will simply discard the packet. This way we make sure that all routers in the internetwork will receive at

least one copy of the packet. Although this algorithm is pretty simple, it has some major disadvantages.

The flooding algorithm generates a large number of duplicated packets and waste the network bandwidth.

Furthermore, since each router needs to keep track of the packets it has received in order to find out

whether this is the first time that a particular packet has been seen or not, it needs to maintain a distinct

entry in its table for each recently seen packet. Therefore, the Flooding algorithm makes inefficient use of

router memory resources.

Spanning Trees

A better algorithm than Flooding is the Spanning Tree algorithm. In this algorithm, a subset of

internetwork links is selected to define a tree structure such that there is only one active path between any

two routers. Since this tree spans to all nodes in the internetwork it is called spanning tree. Whenever a

router receives a multicast packet, it forwards the packet on all the links which belong to the spanning tree

except the one on which the packet has arrived, guaranteeing that the multicast packet reaches all the

routers in the internetwork. Noticeably, the only information a router needs to keep is a Boolean variable

per network interface indicating whether the link belongs to the spanning tree or not. For further

illustration let us see an example where we use a small network with five nodes and six links to show

different trees. We assume that the links are symmetric. The spanning tree from source node (C) is shown

in next part of Figure:

Figure 4: Test Network [5]

8

The spanning tree algorithm has two drawbacks: It centralizes all the traffic on a small set of links and it

does not consider the group membership.

Reverse Path Broadcasting (RPB)

The RPB algorithm is a modification of the Spanning Tree algorithm. In this algorithm, instead of

building a network-wide spanning tree, an implicit spanning tree is constructed for each source. Based on

this algorithm whenever a router receives a multicast packet on a link from a source, the router will check

and see if the link belongs to the shortest path toward the source. If this is the case the packet is forwarded

on all links except the one received from. Otherwise, the packet is discarded. Multicast trees from two

different sources of our test network are shown in Figure.

Figure 6: RPB Trees for two different sources [5]

Figure 5: Formation of a Spanning Tree with C as source [5]

9

The RPB algorithm can be easily improved by considering the fact that if the local router is not on the

shortest path between the source node and a neighbour; the packet will be discarded at the neighbouring

router. Therefore, if this is the case there is no need to forward the message to that neighbour. This

algorithm is efficient and easy to implement. Furthermore since the packets are forwarded through the

shortest path from the source to the destination nodes, it is very fast. The RPB algorithm does not need

any mechanism to stop the forwarding process. The routers do not need to know about the entire

spanning tree and since the packets are delivered through different spanning trees traffic is distributed

over multiple trees and network is better utilized. Still, the RPB algorithm suffer from a major deficiency:

it does not take into account the information about multicast group membership for constructing the

distribution trees.

Truncated Reverse Path Broadcasting (TRPB)

The TRPB algorithm has been proposed to overcome some of the limitations of the RPB algorithm. As

earlier mentioned that by using IGMP protocol, a router can determine whether members of a given

multicast group are present on the router subnetwork or not. If this subnetwork is a leaf subnetwork (it

doesn't have any other router connected to it) the router will truncate the spanning tree. It should be

noted here that TRPB similar to RPB won't forward the message to a neighbour router if the local router is

not on the shortest path from the neighbour router to the source node. Although, multicast group

membership is used in the TRPB algorithm and the leaf subnets are truncated from the spanning trees

but, it does not eliminate unnecessary traffic on non-leaf subnetworks which do not have group member.

Reverse Path Multicasting (RPM)

The RPM algorithm (also known as RPB with prunes) is an enhancement to the RPB and TRPB

algorithms. RPM constructs a delivery tree that spans only:

1) Subnetworks with group members

2) Routers and subnetworks along the shortest path to subnetworks with group members.

The RPM tree can be pruned such that the multicast packets are forwarded along links which lead to

members of the destination group. For a given pair of source and group the first multicast packet is

forwarded based on the TRPB algorithm. If a leaf router receives a multicast packet for a source and group

pair and it does not have any group member on its subnetworks, it will send a "prune" message to the

router from which it has received the multicast packet. The prune message indicates that the multicast

packets of that particular source and group pair should not be forwarded on the link from which the prune

message has been received. It is important to note that prune messages are only sent one hop back

towards the source. The upstream router is required to record the prune information in its memory. On

the other hand, if the upstream router does not have any local recipient and receives prune messages from

all of its children in the TRPB tree, the upstream router will send a prune message to its parent in the

TRPB tree indicating that the multicast packets for the source group pair need not be forwarded to it. The

cascaded prune messages will truncate the original TRPB tree such that the multicast packets will be

forwarded only on those links that will lead to a destination node (multicast group member). Figure 6

illustrates the whole concept:

10

Unfortunately the network topology can dynamically change and the prune state of delivery trees should

be refreshed at regular intervals. Therefore, in RPM algorithm the prune information in routers is

removed periodically and the next packet for a source and group is forwarded to all leaf routers. This is

essentially the first drawback of RPM. Relatively big memory space required for maintaining state

information for all source and group pairs is another drawback which makes this algorithm not scalable

for very large networks.

Core-Based Trees (CBT)

The latest algorithm proposed for constructing multicast delivery trees is called Core-Based Tree (CBT)

algorithm. Unlike other algorithms discussed earlier, CBT creates a single delivery tree for each group. In

other words, the tree used for forwarding multicast messages of a particular group, is a single tree

regardless of the location of the source node. A single router or a set of routers are chosen to be the "core"

router of a delivery tree. All messages to a particular group are forwarded as unicast messages toward the

core router until they reach a router which belongs to the corresponding delivery tree. Then, the packet is

forwarded to all ongoing interfaces which are part of the delivery tree except the incoming interface.

This has been illustrated in Fig 8.

Figure 7: Reverse Path Multicast Concept [5]

Figure 8: Multicasting using CBT approach [5]

11

Since CBT constructs only one delivery tree for each multicast group, multicast routers are required to

keep less information in comparison to the requirements of other routing algorithms. CBT conserves

network bandwidth too because, it does not require flooding of any multicast packet over the

internetwork. However, using a single tree for each group may lead to traffic concentration and

bottlenecks around the core routers.

Multicast Routing Protocols

Like unicast routing protocols (such as Open Shortest Path First (OSPF) protocol), there are multicast

routing protocols which helps multicast routers to determine where to forward multicast messages. We

will now see three routing protocols (Distance Vector Multicast Routing Protocol (DVMRP), Multicast

Extensions to OSPF (MOSPF) protocol, and Protocol Independent Multicast - Dense Mode (PIM-DM)

protocol) which are more efficient in situations where multicast group members are densely distributed

over the network and then the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol which

performs better when group members are sparsely distributed.

Distance Vector Multicast Routing Protocol (DVMRP)

The Distance Vector Multicast Routing Protocol (DVMRP) was driven from Routing Information Protocol

(RIP) with the difference being that RIP forwards the unicast packets based on the information about the

next-hop toward a destination, while DVMRP constructs delivery trees based on the information on the

previous hop back to the source. The earlier version of this distance-vector routing algorithm constructs

delivery trees based on TRPB algorithm. Later on, DVMRP was enhanced to use RPM. The first packet of

multicast messages sent from a particular source to a particular multicast group is flooded across the

internetwork. Then, prune messages are used to truncate the branches which do not lead to a group

member. Furthermore, a new type of messages is used to quickly "graft" back a previously pruned branch

of a delivery tree in case a new host on that branch joins the multicast group.

Multicast Extensions to OSPF (MOSPF)

The Multicast Extensions to OSPF (MOSPF) is built on top of Open Shortest Path First (OSPF). MOSPF

uses the group membership information obtained through IGMP and with the help of OSPF database

builds multicast delivery trees. These trees are shortest-path trees constructed for each source and group

pair. MOSPF supports hierarchical routing. All hosts in the Internet are partitioned into some

"Autonomous Systems" (AS). Each AS is further divided into subgroups called "areas". Let’s divide the

multicast routing of MOSPF into three parts for better understanding:

Intra-Area Routing

Inter-Area Routing

Inter-AS Routing

Intra-Area Routing

OSPF is a link-state routing protocol which allows AS (Autonomous System) to be split into areas. The

OSPF link state database provides the complete map of an area at each router. By adding a new type of

link state advertisement "Group-Membership-LSA" (Group-Membership Link State Advertisement) the

information about the location of members of multicast groups can be obtained and put in the database.

From OSPF link state information, shortest-path delivery trees rooted at the source nodes are constructed

12

using Dijkstra algorithm. Then, group membership information is used to prune those links which don't

end up to a group member. It should be noted here that delivery trees are constructed on demand. In

other words, when a router receives the first multicast datagram of a source and group pair, it will build

the delivery tree. Based on a delivery tree, a router easily knows from which interface it should expect to

receive multicast messages and to which interface(s) it should forward them. Unlike DVMRP, the first

packet need not to be flooded in an area.

Inter-Area Routing

If the source and/or some of the group members are in different areas of an AS, the simple mechanism

described in the previous section won't be enough for forwarding multicast messages. To solve this

problem, a subnet of the area border routers (ABRs) is elected to function as "inter-area multicast

forwarders". Inter-area multicast forwards are responsible for forwarding a summarized version of group

membership information of their attached areas to the backbone area using a new type of group

membership LSAs. It should be noted here that this information is not flooded into non-backbone areas.

Inter-AS Routing

Inter-AS routing involves the cases in which source and/or some of the destination multicast group

members are in different Autonomous Systems. The approach for implementing inter-AS routing is very

similar to that of inter-area routing. Some of the AS Boundary Routers (ASBRs) are configures as "inter-

AS multicast forwarders". MOSPF assumes that inter-AS multicast forwarders construct RPB trees for

forwarding multicast messages.

Protocol-Independent Multicast (PIM)

The Protocol Independent Multicast (PIM) routing protocols are being developed by the Inter-Domain

Multicast Routing (IDMR), a working group of the IETF. IDMR plans to develop a set of multicast routing

protocols which independent of any particular unicast routing protocol can provide scalable Internet-wide

multicast routing. Of course, PIM requires the existence of a unicast routing protocol. The major proposed

multicast protocols perform well if group members are densely packed and bandwidth is not a problem.

However, the fact that DVMRP periodically floods the network and the fact that MOSPF sends group

membership information over the links, make these protocols not efficient in cases where group members

are sparsely distributed among regions and the bandwidth is not plentiful. To address these issues, PIM

contains two protocols: PIM - Dense Mode (PIM-DM) which is more efficient when the group members

are densely distributed, and PIM - Sparse Mode (PIM-SM) which performs better in cases where group

members are sparsely distributed. Although these two algorithms belong to PIM and they share similar

control messages, they are essentially two different protocols. PIM does not send and receive multicast

routing updates between routers like other routing protocols do.

PIM Dense Mode [1]

PIM Dense Mode (PIM-DM) uses a push model to flood multicast traffic to every corner of the network.

This is a brute-force method for delivering data to the receivers, but in certain applications, this might be

an efficient mechanism if there are active receivers on every subnet in the network. PIM-DM initially

floods multicast traffic throughout the network. Routers that do not have any downstream neighbours

prune back the unwanted traffic. This process repeats every 3 minutes. The flood and prune mechanism is

how the routers accumulate their state information. The data streams contain the source and group

information so that downstream routers can build up their multicast forwarding tables. PIM-DM is

independent of the mechanisms employed by any specific unicast routing protocol. This is different from

13

DVMRP and MOSPF protocols. DVMRP uses RIP-like exchange messages to build its unicast routing

table, and MOSPF relies on OSPF link state database.

PIM Sparse Mode [2]

PIM Sparse Mode (PIM-SM) uses a pull model to deliver multicast traffic. Only networks that have active

receivers that have explicitly requested the data will be forwarded the traffic. PIM-SM has two key

differences with existing dense-mode protocols (DVMRP, MOSPF, and PIM-DM). In PIM-SM protocol

routers need to explicitly announce their will for receiving multicast messages of multicast groups, while

dense-mode protocols assumes that all routers need to receive multicast messages unless they explicitly

send a prune message. The other key difference is the concept "rendezvous point" (RP) which has been

employed in PIM-SM protocol.

Each sparse-mode network has a set of routers acting as RPs. Furthermore, each group has a single RP at

any given time. Every router which wants to receive multicast messages from a certain group needs to

send a join message to the RP of that group. Each host has a Designated Router (DR) which is the router

connected to the same subnetwork with the highest IP address. When a DR receives an IGMP message

indicating the membership of a host to a certain group, the DR finds the RP of that group and forwards a

unicast PIM-Join message to the RP. The DR and intermediate routers create an entry in their multicast

forwarding table for the pair such that they can know how to forward multicast messages coming from the

RP of that multicast group to the DR and group members.

Figure 9: Host joins a Multicast Group [5]

When a source sends a message to a certain group, the DR of that source encapsulates the first message in

a PIM-SM-Register packet and sends it to the RP of that group as a unicast message. After receiving this

message, the RP sends back a PIM-Join message to the DR of the source. While this message is being

forwarded to the DR, all intermediate routers add a new entry in their multicast forwarding tables for the

new pair. This way, next multicast messages of this source can be forwarded to the RP easily. Obviously,

RP will be responsible for forwarding these multicast messages to the members of the group. It should be

14

noted that until these entries have been added in all intermediate routers’ tables, all multicast messages

will be forwarded as encapsulated unicast messages.

Figure 10: Source sends to a multicast group [5]

MBone [8]

MBone (multicast backbone) was an experimental backbone for IP multicast traffic across the Internet

developed in the early 1990s. It required specialized hardware and software. Since most Internet routers

have IP multicast disabled due to concerns of bandwidth tracking and billing, the MBone evolved to

connect multicast-capable networks over the existing Internet infrastructure. The commercialization of

multicast routers is difficult because there are no efficient access control capabilities to the multicast trees

(multicast routers and their protocols), and because Internet service providers have difficulty computing

charges for multicast traffic.

A November 1994 Rolling Stones concert at the Cotton Bowl in Dallas with 50,000 fans was the "first

major cyberspace multicast concert." Mick Jagger opened the concert by saying,

"I wanna say a special welcome to everyone that's, uh, climbed into the Internet tonight and, uh, has got

into the M-bone. And I hope it doesn't all collapse."[8]

By 1995 there were M-bone links in Russia, as well as at the McMurdo Sound research station in

Antarctica.

A recent application with support over MBone was Virtual Room Videoconferencing System (VRVS).

15

Future Research in Multicasting [3]

Due to the sparse deployment of IP multicast in the Internet today, some researchers have proposed

application layer multicast as a new approach to implement wide area multicast services. In this approach

multicast functionality is implemented at the end-hosts instead of network routers. Unlike network-layer

multicast, application layer multicast requires no infrastructure support and can be easily deployed in the

Internet. However, more than a decade after its initial proposal, deployment of IP Multicast has been

limited and sparse due to a variety of technical and non-technical reasons.

Therefore some researchers in the recent past have revisited the issue whether the network layer is

necessarily the best layer for implementing multicast functionality and have proposed application layer

multicast as an alternate technique for multicasting. As the name suggests, in application layer multicast,

the multicasting functionality is implemented at the application layer, i.e. at the end-hosts instead of the

network routers.

Unlike network layer multicast where data packets are replicated at routers inside the network, in

application layer multicast data packets are replicated at end-hosts. Logically, the end-hosts form an

overlay network, and the goal of application layer multicast is to construct and maintain an efficient

overlay for data transmission.

16

References

1. Williamson, Beau. Developing IP Multicast Networks. Indianapolis: Cisco Press, 2000.

Multicast Quick Start Configuration Guide (http://www.cisco.com/warp/105/48.html)

2. IP Multicasting Protocols: IGMP, RPM, CBT, DVMRP, MOSPF, PIM, MBONE

Mohammad Banikazemi, banikaze@cis-ohio-state.edu

3. A Comparative Study of Application Layer Multicast Protocols by Suman Banerjee, Bobby Bhattacharjee

Department of Computer Science, University of Maryland, College Park, MD 20742, USA.

4. W. R. Stevens, "TCP/IP Illustrated," Addison-Wesley, 1994.

5. C. Huitema, "Routing in the Internet," Prentice-Hall, Inc., 1995.

6. T. Maufer, C. Semeria, "Introduction to IP Multicast Routing”.

7. "Internet Group Management Protocol, Version 3“ draft-ietf-idmr-igmp-v3-08.txt

8. Wikipedia MBone: http://en.wikipedia.org/wiki/M_Bone

9. http://cisco.iphelp.ru/faq/5/ch12lev1sec4.html