Multicast in Network Level Presented by Apichan Kanjanavapastit, PhD (Telecom) Department of Telecommunication Engineering Faculty of Engineering Mahanakorn.

Multicast in Network Level

Presented by

Apichan Kanjanavapastit, PhD (Telecom)

Department of Telecommunication EngineeringFaculty of Engineering

Mahanakorn University of [email protected]

Multicast Communication

• In multicasting communication, there is one source and a group of destinations thus the relationship is one-to-many

• In this type of communication, the source address is a unicast address, but the destination is a group address which defines the members of the group

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

Multicast Addresses

• A multicast address is a destination address for a group of hosts that would need to receive messages from source of the 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 or network or the receiver

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• The block assigned for multicasting is 224.0.0.0/4

Local Network Control Block

• The addresses in this block are used for protocol control traffic

• Some multicast or multicast-related protocols use these addresses

• The IP packet with the destination address in this range needs to have the value of TTL set to 1, which means that the routers are not allowed to forward these packets

Some Addresses in Network Control Block

Internetwork Control Block

• The addresses in this block are 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

• For example, the address 224.0.1.1 is used by the NTP (Network Time Protocol) service

AD HOC Block

• The multicast group range of 224.0.2.0 through 224.0.255.255 is the Ad Hoc Multicast Block

• Historically, addresses in this range have been assigned to applications that do not clearly fall into the Local Network Control and Inter-Network Control categories

AD HOC Block (cont.)• In general, the guidelines provided in RFC

3171bis for the assignment of addresses in this range state that the IANA should assign addresses in this range only under special circumstances

ST Multicast Group Block

• The block 224.1.0.0/16 is allocated for the Internet Stream Protocol (ST)

• ST protocol is an experimental resource reservation protocol intended to provide end-to-end real-time guarantees over an internet

• It allows applications to build multi-destination simplex data streams with a desired quality of service

SDP/SAP Multicast Block

• The multicast group range is reserved for applications that send and receive multimedia session announcements using the SAP (Session Announcement Protocol) which is protocol for broadcasting multicast session information

• An example of an application that uses SAP is the Session Directory tool (SDR), which transmits global scope SAP announcements on groups 224.2.127.254 and 224.2.127.255

SSM Block

• The block 232.0.0.0/8 is used for Source Specific Multicasting (SSM)

• The SSM i s a method of deliveringmulticast packets in which the only pa

ckets that are delivered to a receiver are those originating from a specific s

ource address requested by the receiver

• SSM will later be described in IGMPv3

GLOP

• The block 233.0.0.0/8 is called the GLOP block (not an acronym nor an abbreviation)

• This range has been assigned as an experimental, public statically assigned multicast address space for Content Providers and Internet Service Providers, or anyone wishing

to source content into the global Internet

GLOP Block (cont.)

• The allocation method in this block uses an autonomous system number (ASN)

• Each AS is assigned a 16-bit number (the newer extension consists 32-bit number), one can insert the AS number as the two middle octet in the block to create a range of 256 multicast addresses (233.x.y.0 to 233.x.y.255), in which x.y is the AS number

Administratively Scoped Block

• The block 239.0.0.0/8 is called Administratively Scoped Block

• The addresses in this block are used for private multicast domains in a

particular area of the Internet by any one without concern for address collis ions,

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

Selecting Multicast Address: 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

• For example, assume a college professor needs to create a group address to communicate with his students. If the AS number that the college belongs to is 91.156

• The college administration can grant the professor, for example, 239.91.156.47 which can become the group address for the professor to use to send multicast addresses to the students

• However, the packets cannot go beyond the college AS territory

Selecting Multicast Address: 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)

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

Introduction to IGMP

• Multicast communication means that a sender sends a message to a group of recipients that are members of the same group

• Each multicast router needs to know the list of groups that have at least one loyal member related to each interface

• Collection of this type of information is done at two levels: locally and globally

Introduction to IGMP (cont.)

• The first task is done by the IGMP (Internet Group Management Protocol); the second task is done by the multicast routing protocols

• IGMP is not a multicast routing protocol; it is a protocol that manages group membership

• The IGMP protocol gives the multicast routers create and update list of loyal members related to each router interface

Position of IGMP in the Network Layer

• The (IGMP) is responsible for collecting information about group members in a network

• It is one of the protocols designed at the IP layer for this purpose

Versions of IGMP

• IGMP has gone through 3 versions• Version 1 and 2 provide what is called any-

source multicast (ASM), which means that the group members receive a multicast message no matter where it comes from

• The IGMP version 3 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

IGMP Messages

Membership Query Message Format

• A membership query message is sent by a router to find active group members in the network

Membership Query Message Format (cont.)

• Response code. It is used to define the response time of a recipient of the query

• 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

• QRV. This field is called querier’s robustness variable. It is used to monitor robustness in the network

• QQIC. This field is called querier’s query interval code. This is used to calculate the querier’s query interval (QQI)

Membership Query Message Format (cont.)

• 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 nonzero in the group-and-source specific query

• Source Addresses. These multiple fields list the N source addresses, the origin of multicasat messages

Three formats of query messages

• In a general query message, the querier router probes each neighbor to report the whole list of its group membership (interest in any multicast group)

• In a group-specific query message, the querier router probes each neighbor to report if it is still interested in a specific multicast group

• In a group-and-source-specific query message, the querier router probes each neighbor to report if it is still in a specific multicast group, coming from any of the N sources whose unicast addresses are defined in this packet

Three forms of query messages

Membership Report Message Format

Membership Report Message Format (cont.)

• Record Type. Currently there are 6 record types as shown in the table

IGMP Protocol Applied to Host: Socket State

• The management of groups starts with the processes on a host connected to an interface

• Each process, which is associated with a socket, has a record for each multicast group from the socket wishes to receive a multicast message

• The record also shows one of the 2 modes: include mode or exclude mode

• If the record is in include mode, it lists the unicast source addresses from which the socket accepts the group messages

IGMP Protocol Applied to Host: Socket State (cont.)

• If the record is in exclude mode, it lists the unicast source address that the socket will not accept the group messages

• In other words, the include mode means “only….,” the exclude mode means “all, but….”

• The state can be organized in a table, in which a row defines one single record

• A socket may have more than one record if it expects to receive multicast messages destined for more than one group

Figure below 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.

ExampleExample

IGMP Protocol Applied to Host: Interface State

• As seen in the previous, there can be overlap information in the socket records

• To be efficient, group management requires that the interface connecting the host to the network also keep an interface state

• The interface state will build up when socket records are changed and it keeps only one record for each multicast group

IGMP Protocol Applied to Host: Interface State

• The interface state needs to keep an interface timer for the whole state and one timer for each record

• The only problem in combining records is the list of resources

• If a record with the same multicast group has 2 or more different lists of resources, the following rules need to be followed to combine the list of resources

IGMP Protocol Applied to Host: Interface State

• 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:– a. Apply the set intersection operation on all

the address lists with exclusive filters– b. Apply the set difference operation on the

result of part a and all the address lists with inclusive filters

IGMP Protocol Applied to Host: Interface State

• 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 operation on all the address lists

Each time there is a change in any socket record, the interface

statewill change using the

above-mentioned rules.

We use the two rules described above to create the interface state for the host in the table. 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.

ExampleExample

b. Multicast group: 228.24.21.4 has two include lists. The result is an include list as calculated below

Interface state from the example

IGMP Protocol Applied to Host: 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 records

IGMP Protocol Applied to Host: Receiving Query Messages

• 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:

• 1. If the received query is a general query, the host reset the interface timer to the calculated delay value. This means if there is any previous delayed response, it is cancelled

IGMP Protocol Applied to Host: Receiving Query Messages

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

• 3. 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 sources is recorded for the delayed response

IGMP Protocol Applied to Host: 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

• 1. If the expired timer is the interface timer set after a general query received, then the host sends one membership report that contains one Current-State-Record for each group in the interface state

• 2. If the expired timer is the group timer set after a group-specific query received, then the host sends one membership report that contains only one Current-State-Record for that particular group if, and only if, the group is still active

IGMP Protocol Applied to Host: Timer Expiration (cont.)

• 2. If the expired timer is the group timer set after a group-and-source-specific query received, then the host sends one membership report that contains only one Current-State-Record for that particular group if, and only if, the group is still active. The type of the single record contained in the report and the source list depends on the filter mode of the group.