Chapter 12: Multicasting and Multicast Routing Protocols

1

Objectives 12.1 Introduction

To compare and contrast unicasting, multicasting, and broadcasting communication

12.2 Multicast Addresses To define multicast addressing space in IPv4 and show the

division of the space into several blocks 12.3 IGMP

To discuss IGMP v3 which is responsible for collecting group membership information in a network

2

Objectives 12.4 Multicast Routing

To discuss the general idea behind multicast routing protocols Source-Based Tree Group-Based Tree

12.5 Routing Protocols To discuss multicast link state routing, distance vector routing and

core-based protocol (CBT) in general and their implementation in the Internet

MOSPF / DVMRP / PIM-DM and PIM-SM 12.6 MBONE

To discuss multicast backbone (MBONE) that shows how to create a tunnel when the multicast messages need to pass through an area with no multicast routers 3

12.1 Introduction There are three communication mechanisms

defined and classified as they related to the Internet Unicasting Multicasting Broadcasting

4

Unicast In unicast routing (Fig. 12.1), the router

forwards the received packet through only one of its interfaces

In unicast routing, each router in the domain has a table that defines a shortest path tree to possible destinations

5

Unicast

R2

R1

N1 N2 N3 N4

1

1

2

2

3

3

4

N5 N6

R3 R4

Recipientis here

Source

Ethernet switch

Point-to-point WAN

Unicast router

Legend

Figure 12.1 Unicasting

6

Multicast In multicasting (Fig. 12.2), there is one

source and a group of destinations The relationship is one to many The router may forward the received packet

through several of its interfaces

7

Multicast

R1

R2 R3 R4

Nomember

Nomember

Nomember

At leastsone member

At leastsone member

At leastsone member

Source

1

1 1

2

22

3

33

4

Ethernet switch

Point-to-point WAN

Multicast router

Legend

Figure 12.2 Multicasting8

Emulation of Multicasting with Unicasting As shown in Fig. 12.3 :

Multicasting is more efficient than multiple unicasting Multicasting requires less bandwidth than multiple unicasting In multiple unicasting, some of the links must handle several

copies In multiple unicasting, the packets are created by the

source with a delay relative to each other If there are 1000 destinations, the delay between the first and

the last packet may be unacceptable In multicasting, there is little delay because of multiple packet

creation

9

D4D1 D2 D3

b. Multiple unicasting

S1

DiGi

Multicast router

Unicast destinationGroup member

Unicast router

Legend

S1

G1 G1 G1G1

a. Multicasting

Emulation of Multicasting with Unicasting

Figure 12.3 Multicasting versus multiple unicasting10

Application for Multicasting Access to Distributed Database Information Dissemination Dissemination of News Teleconferencing Distance Learning

11

Broadcasting In broadcasting communication, the

relationship between the source and the destination is one to all

The Internet does not explicitly support broadcasting because of Traffic Bandwidth

12

12.2 Multicast Addresses A multicast address is a destination address

for a group of hosts that have joined a multicast group

A packet that uses a multicast address as a destination can reach all members of the group unless there are some filtering restriction by the receiver

13

Multicast Addresses in IPv4 In classful addressing, multicast addresses

occupied the only single block in class D In classless addressing, the same block has been

used for this purpose In other words, the block assigned for multicasting is

224.0.0.0/4 This large block, or the multicast address space as

sometimes it is referred to, is divided into some smaller ranges, as shown in Table 12.1, based on RFC 3171

14

15

Multicast Addresses Ranges

Local Network Control Block The address in this block are

used for protocol control traffic Not used for general multicast

communication TTL = 1 Table 12.2 shows the assignment

of some of these addresses

16

Multicast Addresses Ranges Internetwork Control Block

Also used for protocol control traffic But the IP packets with one of these addresses as destination

can be forwarded by router through the whole Internet AD-HOC Block

This block was traditionally assigned to some applications that do not fit in the first or second block discussed above

Stream Multicast Group Block Allocated for stream multimedia

17

Multicast Addresses Ranges SAP/SDP Block

Used for Session Announcement Protocol and Session Directory Protocol

SSM Block Used for Source Specific Multicasting

GLOP Block This block defines a range of globally assigned

addresses that can be used inside an autonomous system

18

Multicast Addresses Ranges Administratively Scope Block

The addresses in this Administratively Scoped Block are used in a particular area of the Internet

The packet whose address belongs to this range is not supposed to leave the area

In other words, an address in this block is restricted to an organization

19

Selecting Multicast Address The selection of address depends on the

type of application For Limited Group:

The administrator can use the AS number (x,y) and choose an address between 239.x.y.0 and 239.x.y.255 that is not used by any other group as the multicast address for that particular group

20

Selecting Multicast Address For Larger Group:

If the group is spread beyond an AS territory, the previous solution does not work

The group needs to choose an address from the SSM block (232.0.0.0/8)

There is no need to get permission to use an address in this block, because the packets in source-specific multicasting are routed based on the group and the source address; they are unique

21

Delivery of Multicast Packets at Data Link Layer Because the IP packet has a multicast IP

address, the ARP protocol cannot find the corresponding MAC (physical) address to forward the packet at the data link layer What happens next depends on the following

two cases: Network with Multicast Support Network with no Multicast Support

22

Network with Multicast Support Most LANs support physical multicast addressing Ethernet is one of them

An MAC address is 48 bits long If the first 25 bits starts with 00000001 00000000

01011100 0, it is a physical multicast address for TCP/IP

The remaining 23 bits can be used to define a group To convert an IP multicast address into an Ethernet

address, the router extracts the least significant 23 bits of a multicast IP address and inserts them into a multicast Ethernet physical address (see Fig. 12.4)

23

Network with Multicast Support

Figure 12.4 Mapping class D to Ethernet physical address

24

Network with no Multicast Support Most WANs do not support physical

multicast addressing To send multicast packet through these

network, a process called tunneling is used In tunneling, the multicast packet is

encapsulated in a unicast packet and sent through the network (Fig. 12.5)

25

Network with no Multicast Support

Figure 12.5 Tunneling

26

12.3 IGMP In multicast, each multicast router needs to know

the list of groups to each interface It means that they need to collect information about

members and share it with others The Internet Group Management Protocol (IGMP)

is responsible for correcting and interpreting information about group members in a network It is one of the protocols designed at the IP layer for this

purpose (Fig. 12.6)

27

12.3 IGMP

Figure 12.6 Position of IGMP in the network layer

28

Group Management IGMP is not a multicasting routing protocol IGMP is a protocol that manages group membership The IGMP protocol gives the multicast routers information

about the membership status of hosts (routers) connected to the network

It helps a multicast router create and update a list of loyal members related to each router interface

29

Group Management IGMP has gone through three versions.

V1 and V2 provide any-source multicast (ASM), which means that the group members receive a multicast message no matter where it comes from

V3 provides what is called source-specific multicast (SSM), which means that the recipient can choose to receive multicast messages coming from a list of predefined sources

Only V3 is discussed in this section

30

IGMP Messages Two types of message of IGMPv3

Member ship query message Membership report message

The former can be used in three different formats

Figure 12.7 IGMP messages 31

Membership query message format A membership query message is sent by a route to

find active group members in the network

Figure 12.8 Membership query message format32

Membership query message format Type

The value is 0x11 for a membership query message Maximum Response Code

It is used to define the response time of a recipient of the query

Checksum Group Address

This field is set to 0 in a general query message; it is set to IP multicast being queried when sending a group-specific or group-and-source-specific query message

33

Membership query message format Resv

Reserved for the future S

Suppress flag: when this field is set to 1, it means that the receivers of the query message should suppress the normal timer updates

QRV Querier’s robustness variable: it is used to monitor the

robustness in the network

34

Membership query message format QQIC

Querier’s query interval code: it is used to calculate the querier’s query interval (QQI), as we will show shortly

Number of sources (N) This field defines the number of unicast source

addresses attached to the query The value of this field is zero for the general query and the

group-specific query; and non-zero in the group-and-source-specific query

Source Addresses These fields list the N source address, the origin of

multicast messages 35

Membership query message format Three formats of query messages (Fig. 12.9)

General query message The querier router probes each neighbor to report the whole

list of its group membership. Group specific message

Probes each neighbor to report if it is still interested in a specific multicast group.

The multicast group address is defined as x.y.z.t in the group address field of the query.

Group-and-source-specific query message Probes each neighbor to report if it is still in a specific

multicast group, x.y.z.t, coming from any of the N sources whose unicast addresses are defined in this packet

36

Membership query message format

Figure 12.9 Three forms of query messages

37

Membership report message format Version 3 Membership Reports are sent by IP

systems to report (to neighboring routers) the current multicast reception state, or changes in the multicast reception state, of their interfaces

Reports have the following format: (Fig. 12.10)

38

Membership report message format

Figure 12.10 Membership report message format 39

Membership report message format Type

0x22 defines this type of the message Checksum Number of Group Records (M)

This field defines the number of group records carried by the packet

There can be zero or more group records of variable length

40

Membership report message format Each group record includes the following

information related to the responder’s membership in a single multicast group

Record Type Six record types

41

Membership report message format Aux Data Len

This field defines the length of the auxiliary data included in each group record

It may contain zero, to indicate the absence of any auxiliary data

Number of Sources (N) The Number of Sources (N) field specifies how many

source addresses are present in this Group Record

42

Membership report message format Source Addresses

These fields list the source addresses Aux Data

This field contains any auxiliary data that may be included in the report message

The IGMP has not yet defined any auxiliary data, but it may be added to the protocol in the future

43

IGMP Protocol Applied to Host How a host implements IGMP is discussed

in this section Hosts need to do the management of groups

Each process (running application programs) associated with each socket

How to maintain the socket states? Several interfaces are used

How to maintain interface states? Can interface states be simplified?

44

Socket state Each process has a record for each multicast

group The record shows one of the two modes:

Include mode It lists the unicast source addresses from which the

socket accepts the group messages Exclude mode

It lists the unicast source addresses that the socket will not accept the group messages

45

Figure 12.11 shows a host with three processes: S1, S2, and S3. The first process has only one record; the second and the third processes each have two records. We have used lowercase alphabet to show the source address.

Example 12.4

Figure 12.11 Socket state46

Interface State If a record with the same multicast group

has many lists of resources, the following two rules need to be followed to combine the list of resources Each time there is a change in any socket

record, the interface state will change

47

Interface State Rule 1:

If any of the records to be combined has the exclusive filter mode, then the resulting interface record will have the exclusive filter mode and the list of the source addresses is made as shown below:

Apply the set intersection operation on all the address lists with exclusive filters

Apply the set difference operation on the result of part a and all the address lists with inclusive filters

48

Interface State Rule 2:

If all the records to be combined have the inclusive filter mode,

Then the resulting interface record will have the inclusive filter mode

And the list of the source addresses is found by applying the set union operations on all the address lists

49

We use the two rules described above to create the interface state for the host in Example 12.4. First we found the list of source address for each multicast group.a. Multicast group 226.14.5.2 has two exclude lists and one include list. The result is an exclude list as calculated below.

Example 12.5

b. Multicast group: 228.24.21.4 has two include lists. The result is an include list as calculated below. We use the plus sign for the union operation.

Figure 12.12 shows the interface state.

50

Figure 12.12 Interface state

Example 12.5

51

Sending Change-State Reports If there is any change in the interface state,

the host needs to immediately send a membership report message for that group, using the appropriate group record(s)

As Figure 12.13 shows, four different cases may occur in the change, based on the old-state filter and the new state filter Only the group records are shown, not the

whole report52

Figure 12.13 Sending change state reports53

Receiving Query Reports When a host receives a query, it does not

respond immediately It delays the response by a random amount of

time calculated from the value of the Max Resp Code field

The action of the host depends on the type of the query received as shown below:

54

Receiving Query Reports1. If the received query is a general query, the host reset the

interface timer (see Fig. 12.12) to the calculated delay value

This means if there is any previous delayed response, it is cancelled

2. If the received query is a group-specific query, then the corresponding group time (see Fig. 12.12) is reset to the shorter value of the remaining time for the timer or the calculated delay

If a timer is not running, its remaining time is considered to be infinity

55

Receiving Query Reports3. If the received query is a group-and-source-specific query,

then the action is the same as the previous case In addition, the list of source is recorded for the delayed response

56

Timer Expiration Membership report messages are sent by a

host when a timer expires However, the types and number of group

records contained in the message depends on the timer

57

Timer Expiration

1. General query received timer expires: Host sends a membership report contains one Current-

State-Record for each group in the interface state If all records to be sent do not fit in one report

They can be split into several reports

2. Group-specific query received timer expires: Host sends a membership report contains only one

Current-State-Record for that particular group if it is still active

58

Timer Expiration

3. Group-and-source-specific query received timer expires: Same as 2. The type of the single record contained in the report

and source list depends on the filter mode of the group Include

The record type is Mode_Is_Include (type 1) and the source list is (A . B) A: group source list / B: received source list .(dot sign) means the intersection operation

Exclude The record type is Mode_Is_Exclude(type 2) and the source list is (B - A) -(minus sign) means the difference operation

59

Report Suppression In IGMPv2,

If a host receives a report sent by another host, it cancelled the corresponding timer in its interface state, which means suppressing the pending report

In IGMPv3, This mechanism has been removed from the

protocol for some practical reasons described in RFC 3376

60

IGMP Protocol Applied to Router How a router implements IGMP is

discussed in this section A querier (multicast router) in IGMPv3

needs to handle 6 types of group records contained in a membership report Multiple interfaces are used

How to maintain their states?

61

Querier’s State

The multicast router needs to maintain the state information for each multicast group associated with each network interface

Figure 12.14 shows an example of a multicast router and its two state tables

62

Querier’s State

Figure 12.14 Router States

63

Action Taken on Membership Report Reception A multicast router sends out queries and receives

reports When a multicast router receives the reports, it needs to

take some actions to change its state Reception of Report in Response to General Query Reception of Reports in Response to Other Queries

64

Reception of Report in Response to General Query When a router sends a general query, it expects to

receive a report or reports This types of a report normally contains Current-State-

Record(types 1 and 2) When such a report arrives, the router changes its state,

as shown in Figure 12.15

65

Figure 12.15 Change of state related to general query report

Reception of Report in Response to General Query

66

Reception of Reports in Response to Other Queries When a router sends a group-specific or group-

and-source-specific query, it expects to receive a report or reports This types of a report normally contains Filter-

State_Mode_Change_Record (types 3 and 4) or Source_List_Change_Record (types 5 and 6)

When such a report arrives, the router changes its state, as shown in Figure 12.16

67

Figure 12.16 Change of state related to other report types 68

Role of IGMP in Forwarding In previous versions of IGMP, the forwarding

recommendation was based only on the destination multicast address of a packet

In IGMPv3, the recommendation is based on both destination address and the source address. RFC 3376 mentions 6 different recommendations that

IGMPv3 software can give to the IP multicast router to forward or not to forward a packet with respect to an interface

69

Role of IGMP in Forwarding If the multicast destination address does not exist in the router state,

the recommendation is definitely not to forward the packet

70

Variables and Timers Maximum Response Time

The maximum response time is the maximum time allowed before sending a report in response to a query

It is calculated from the value of the 8-bit Max Resp Code field in the query

The calculation of the maximum response time is shown in Fig. 12.17

71

Variables and Timers

72Figure 12.17 Calculation of maximum response time

RFC 3376:The Max Response Time in Query messages has an exponential range, changing the maximum from 25.5 seconds to about 53 minutes, for use on links with huge numbers of systems

Variables and Timers

Querier’s Robustness Variable (QRV) It dictates how many times a response message

to a query should be sent The number of times a host should send a

response to a query is QRV -1 Default value is 2

73

Variables and Timers

Qurier’s Query Interval This is the interval between the general queries Default value is 125 This value can be changed by an administrator

to control the traffic on the network Other Variables and Timers

See RFC 3376

74

IGMP Encapsulation The IGMP message is encapsulated in an IP datagram with

the value of protocol field set to 2 and the TTL field set to 1

The destination IP address of datagram, however, depends on the type of the message, as shown in Table 12.5

75

IGMP Compatibility with Older Versions To be compatible with V1 and V2, IGMPv3 software is

designed to accept messages defined in V1 and V2. Table 12.6 shows the value of type fields and the type of

messages in V1 and V2

76

12.4 Multicast Routing Objectives

To discuss the idea of optimal routing, common in all multicast protocols

Optimal Routing: Shortest Path Trees To discuss the general idea behind multicast routing

protocols Source-Based Tree Group-Based Tree

77

Optimal Routing: Shortest Path Trees The process of optimal inter-domain routing

eventually results in the finding of the shortest path tree

However, the number of trees and the formation of the trees in unicast and multicast routing are different

78

79

Unicast routing In unicast routing, each router in the

domain has a table that defines a shortest path tree to possible destinations

Fig. 12.18 shows the situation

Figure 12.18 Shortest path tree in multicast routing

80

Multicast routing A multicast packet may have destinations in more

than one network Forwarding of a single packet to members of a

group requires a shortest path tree N group N trees (complexity is high) Two approaches have been used to solve the problem:

Source-based trees Group-shared trees

81

Source-based trees In a source-based tree approach, the combination of

source and group determines the tree If there are N groups and M sources in the system, there

can be a maximum of N*M different trees In the source-based tree approach, each router needs to have one

shortest path tree for each group See Fig. 12.19

82

Source-based trees

83Figure 12.19 Source-based tree approach

Group-shared trees In the group-shared tree approach, the group determines

the tree If there are N groups in the system, there is a maximum of

N trees In the group-shared tree approach, only the core router,

which has a shortest path tree for each group, is involved in multicasting

See Fig. 12.20

84

Group-shared trees

85Figure 12.20 Group-shared tree approach

During the last few decades, several multicast routing protocols have emerged

Some of these protocols are extensions of unicast routing protocols; some are totally new Figure 12.21 shows the taxonomy of these protocols

86

12.5 Routing Protocols

Multicast routing protocols

87

Figure 12.21 Taxonomy of common multicast protocols

DVMRP The Distance Vector Multicast Routing Protocol

(DVMRP) must achieve the following It must prevent the formation of loops It must prevent duplications It must provide for dynamic membership

88

DVMRP Reverse Path Forwarding (RPF):

In reverse path forwarding (RPF), the router forwards only the packets that have traveled the shortest path from the source to the router; all other copies are discarded

RPF prevents the formation of loops in the flooding process

89

DVMRPFigure 12.22 RPF

90

DVMRP

Reverse Path Broadcasting (RPB) Net3 has two parents: routers R2 and R4 For each source, the router sends the packet only out of those

interfaces for which it is the designated parent. This policy is called reverse path broadcasting

To eliminate duplication, the most common policy is to select the router with the shortest path to the source as the designed parent router 91

DVMRP

RPF versus RPB RPB creates a shortest path broadcast tree from the

source to each destination. It guarantees that each destination receives one and only one copy of the packet

92

DVMRP Reverse Path Multicasting (RPM)

Pruning: The router sends a prune message to the upstream can stop sending multicast messages for this group through that interface

Grafting: The graft message forces the upstream router to resume sending the multicast messages

RPM adds pruning and grafting to RPB to create a multicast shortest path tree that supports dynamic membership changes

93

DVMRP

RPF, RPB, and RPM 94

95

MOSPF

The Multicast Open Shortest Path First (MOSPF) is an extension of the OSPF protocol that uses multicast link state routing to create source-based trees

The tree is a least-cost tree (using a metric) The tree is made all at once

CBT

Shared-group tree with rendezvous router The Core-Based Tree (CBT) protocol is a group-shared

protocol that uses a core as the root of the tree The autonomous system is divided into regions and a

core (center router) is chosen for each region96

CBT Procedure of Transmission in CBT

The source, which may or may not be part of the tree, encapsulates the multicast packet inside a unicast packet with the unicast destination address of the core and sends it to the core

This part of delivery is done using a unicast address; the only recipient is the core router

The core decapsulates the unicast packet and forwards it to all “interested” interfaces

Each router that receives the multicast packet, in turn, forwards it to all interested interfaces

97

CBT

Sending a multicast packet to the rendezvous router98

99

CBT In CBT, the source sends the multicast

packet (encapsulated in a unicast packet) to the core router

The core router decapsulates the packet and forwards it to all interested interfaces

.

PIM Protocol Independent Multicast (PIM) is the

name given to two independent multicast routing protocols: Protocol Independent Multicast, Dense Mode

(PIM-DM) Protocol Independent Multicast, Sparse Mode

(PIM-SM)

100

PIM PIM-DM

PIM-DM is used in a dense multicast environment, such as a LAN environment.

PIM-DM uses RPF and prunning/grafting strategies to handle multicasting. However, it is independent from the underlying unicast protocol.

PIM-SM PIM-SM is used in a sparse multicast environment such

as a WAN. PIM-SM is a group shared routing should notify

protocol that has a rendezvous point (RP) as the source of the tree.

PIM-SM is similar to CBT but uses a simpler procedure. 101

12.6 MBONE

MBONE The multicast routers may not be connected directly, but

they are connected logically Only the routers enclosed in the shaded circles are

capable of multicasting With tunneling, these multicast routers are not isolated

islands 102

MBONE Procedure of Transmission in MBONE

A logical tunnel is established by encapsulating the multicast packet inside a unicast packet.

The multicast packet becomes the data of the unicast packet

The intermediate (non-multicast) routers route the packet as unicast routers and deliver the packet from one island to another

It’s as if the unicast routers do not exist and the two multicast routers are neighbors.

DVMRP supports MBNOE103

MBONE

MBONE104