Introduction to Multicast Routing Protocols

Shortest Path Trees Optimal Routing: Shortest Path Trees The process of intradomain routing attempts to find the shortest path between a router and another destinations resulting in shortest path tree (SPT) The root of the tree is the source and the leafs are the potential destinations However, the number of trees and the formation of the trees in unicasting and multicast routing are different

Shortest Path Trees in Unicast In unicast routing, when a router receives a packet to forward, it needs to find the shortest path to the destination of the packet The next-hop entry in the routing table corresponding to the destination is the start of the shortest path tree Each line of the routing table is a shortest path; the whole routing table is a shortest path Each router needs only one shortest path tree to forward a packet; however, each router has its own shortest path tree

Unicast Routing (cont.)

Shortest Path Trees in Multicast In a 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 If we have n groups, we may need n shortest path trees Two approaches have been used to solve the problem: source based trees and group-shared trees

Concept of Multicast Routing The concept of multicast routing can be described from the broadcast routing in the network The broadcast routing algorithm can be based on different strategies such as uncontrolled flooding and controlled flooding

Uncontrolled Flooding A router receives a broadcast packet and sends it out from every interface except the one from which it was received However, uncontrolled flooding create loops which means a packet that has left the router may come back again from another interface or the same interface and be forwarded again If a router is connected to more than two other routers, it will create and forward multiple copies of the broadcast packet, each of which will create multiple copies of itself at other routers with more than two neighbors, and so on  Broadcast Storm

Controlled Flooding The key to avoiding a broadcast storm is for a router to choose when to flood a packet and when not to flood a packet In sequence-number-controlled flooding, a source puts its address and sequence number into a broadcast packet Each router maintains a list of the source address and sequence number of each broadcast packet it has already received, duplicated, and forwarded

Controlled Flooding (cont.) When a router receives a broadcast packet, it first checks whether the packet is in the list If so, the packet is dropped; if not, the packet is duplicated and forwarded to all the neighbors (The Gnutella protocol uses this strategy to broadcast queries in its overlay network at the application layer level)

Reverse Path Forwarding (RPF) RPF is another controlled flooding strategy In RPF, a router forwards only the copy arrived on the link that is on its own shortest path back to the source of packet To find this copy, A router consults its unicast routing table as though it wants to send a packet to the source address Since the routing table tells the router the next hop router address, if the packet has just come from the address defined it means the packet has traveled the shortest path from the source

Reverse Path Forwarding (RPF) (cont.)

Spanning-Tree Broadcast While sequence-number-controlled flooding and RPF avoid broadcast storms, they don’t completely avoid the transmission of redundant broadcast packets The solution is spanning tree—a tree that contains each and every node in a graph When a source node wants to send a broadcast packet, it sends the packet out on all of the incident links that belong to the spanning tree

Spanning-Tree Broadcast (cont.) A node receiving the packet then forwards the packet to all its neighbors in the spanning tree

Construction of a Spanning Tree The main complexity associated with the spanning-tree approach is the creation and maintenance of it One simple algorithm is using center-based approach in which a center node is defined and routers then send unicast tree-join message addressed to the center node A tree-join message is forwarded using unicast routing until it either arrives at a router that already belongs to the spanning tree or arrives at the center

Construction of a Spanning Tree (cont.) In either case, the path that the tree-join message has followed defines the branch of the spanning tree between the edge router that initiated the tree-join message and the center One can think of this new path as being grafted onto the existing spanning tree

Construction of a Spanning Tree (cont.)

Multicast Routing Algorithm As mentioned that two approaches have been used to solve the problem: source based trees and group-shared trees, both of which we have studied in the context of broadcast routing The two approaches differ according to whether a single group-shared tree is used to distribute the traffic for all senders in the group, or whether a source-specific routing tree is constructed for each individual sender

Group-Shared Tree In this approach, instead of each router having m shortest path trees, only one designated router called the center core or rendezvous router takes the responsibility of distributing multicast traffic as a center-based approach The core has m shortest path trees in its routing table but the rest of the routers in the domain have none If a router receives a multicast packet, it encapsulates the packet in a unicast packet and sends it to the core The core router removes the multicast packet from its capsule, and consults its routing table to route the packet

Group-Shared Tree

Source-Based Tree In the source-based tree approach, a multicast routing tree is constructed for each source in the multicast group In practice, an RPF algorithm (with source node x) is used to construct a multicast forwarding tree for multicast originating at source x However, the RPF broadcast algorithm requires a bit of modifying for use in multicast by introducing pruning and grafting

Reverse Path Forwarding: example S: source R1 R4 LEGEND router with attached group member R2 router with no attached group member R5 datagram will be forwarded R3 Notes: 3.3 Network Layer: Multicast Routing Algorithms 3-14 R6 R7 datagram will not be forwarded

Pruning in PRF In pruning, a multicast router that receives multicast packets and has no attached node joined to that group will send a prune message to its upstream router If a router receives prune message from each of its downstream routers, then it can stop sending multicast packets for this group through that interface If this router receives prune messages from all down stream routers, it in turn sends a prune message to its upstream router

Reverse Path Forwarding: pruning forwarding tree contains subtrees with no multicast group members no need to forward datagrams down subtree “prune” msgs sent upstream by router with no downstream group members LEGEND S: source R1 router with attached group member R4 router with no attached group member R2 Notes: 3.3 Network Layer: Multicast Routing Algorithms 3-15 P P R5 prune message P links with multicast forwarding R3 R6 R7

Grafting in RPF What if a leaf router has sent a prune message but later on realizes that one of its node is again interested in receiving the multicast packet It can send a graft message which forces the upstream router to resume sending the multicast message

Multicast Routing Protocols in the Internet During the last few decades, several multicast routing protocols in the Internet have emerged Some of these protocols are extensions of unicast routing protocols; some are totally new

Multicast Link State Routing Multicast link state routing is a direct extension of unicast routing and uses a source-based tree approach Each router advertises every group which has any loyal member on the link and the information about the group comes from IGMP When a router receives all advertisements, it creates n (n is the number of groups) topologies, from which n shortest path trees are made using Dijkstra’s algorithm

Multicast Link State Routing (cont.) The only problem with this protocol is the time and space needed to create and save the many shortest path trees The solution is to create the trees only when needed and the result can be cached in case there are additional packets for that destinations

Multicast Open Shortest Path First (MOSPF) MOSPF protocol is an extension of the OSPF protocol that uses multicast link state routing to create source-based trees The protocol requires a new link state update packet to associate the unicast address of a host with the group address This packet is called the group- membership LSA MOSPF is a data-driven protocol; the first time an MOSPF router sees a datagram with a given source and group address

Distance Vector Multicast Routing (DVMRP) DVMRP implements source-based trees with RPF, pruning, and grafting DVMRP uses a distance vector algorithm that allows each router to compute the outgoing link (next hop) that is on its shortest path back to each possible source The information is then used in the RPF algorithm as discussed In addition to computing next-hop information, DVMRP also computes a list of dependent downstream routers for pruning purposes

Distance Vector Multicast Routing (DVMRP) (cont.) A DVMRP prune message contains a prune lifetime (a default value is two hours) that indicates how long a pruned branch will remain pruned before being automatically restored DVMRP graft messages are sent by a router to its upstream neighbor to force a previously pruned branch to be added back on to the multicast tree

Core-Based Tree (CBT) Protocol The CBT protocol is a group-shared protocol that uses a core as the root of the tree The autonomous system is divided into regions an a core (center router or rendezvous router) is chosen for each region There is a procedure in this protocol Selecting the Rendezvous Router Formation of the Tree Sending Multicast Packets

Formation of the Tree After the rendezvous point is selected, every router is informed of the unicast address of the selected router Each router then sends a unicast join message to show that it wants to join the group This message passes through all routes that are located between the sender and the rendezvous router Each intermediate router extracts the necessary information from the message, such as the unicast address of the sender and the interface, and forwards the message to the next router in the path When the rendezvous router has received all join messages from every member of the group, the tree is formed

Formation of the Tree (cont.) Now every router knows its upstream router (the router that leads to the root) and the downstream router (the router that leads to the leaf) If a router wants to leave the group, it sends a leave message to its upstream router The upstream router removes the links to that router from the tree and forwards the message to its upstream router, and so on

Sending Multicast Packets After formation of the tree, any source can send a multicast packet to all members of the group It simply sends the packet to the rendezvous router, using the unicast address of the rendezvous router; the rendezvous router distributes the packet to all members of the group

Summary to CBT In CBT, a packet is sent from the source to members of the group following this procedure: 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 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

Protocol Independent Multicast (PIM) PIM is the name given to two independent multicast routing protocols: PIM, Dense Mode (PIM-DM) and PIM, Sparse Mode (PIM-SM)

PIM-DM PIM-DM is used when there is a possibility that each router is involved in multicasting (dense mode) In this environment, the use of a protocol that broadcasts the packet is justified because almost all routers are involved in the process PIM-DM is a source-based tree routing protocol that uses RPF and pruning/grafting strategies for multicasting Its operation is like DVMRP; however, it does not depend on a specific unicating protocol

PIM-SM PIM-SM is used when there is a slight possibility that each router is involved in multicasting (sparse mode) In this environment, the use of a protocol that broadcasts the packet is not justified; a protocol such as CBT that uses a group-shared tree is more appropriate PIM-SM is a group-shared tree routing protocol that has a rendezvous point (RP) as the source of the tree Its operation is like CBT; however, it is simpler because it does not require acknowledgement from a join message In addition, it creates a backup set of RPs for each region to cover RP failures

PIM-SM (cont.) One of the characteristics of PIM-SM is that it can switch from a group-shared tree strategy to a source-based tree strategy when necessary This can happen if there is a dense area of activity far from the RP. That area can be more efficiently handled with a source-based tree strategy instead of a group-shared tree strategy

How to Evaluate a Multicast Routing Protocol? Scalability. What is the amount of state required in the routers by a multicast routing protocol? How does the amount of state change as the number of groups, or number of senders in a group, change? Reliance on underlying routing. To what extent does a multicast protocol rely on information maintained by an underlying unicast routing protocol? We have seen solutions that range from reliance on one specific underlying unicast routing protocol (MOSPF), to a solution that is completely independent (PIM), to a solution that implements much of the same distance vector functionality (DVMRP)

How to Evaluate a Multicast Routing Protocol? (cont.) Excess (un-needed) traffic received. We have seen solutions where a router receives data only if it has an attached node in the multicast group (MOSPF, PIM-SM) to solution where the default is for a router to receive all traffic for all multicast groups (DVMRP, PIM-DM) Traffic concentration. The group-shared tree approach tends to concentrate traffic on a smaller number of links (those in the single tree), whereas source-specific trees tend to distribute multicast traffic more evenly

Delivery of Multicast Packets at Data Link Layer Most LANs support physical multicast addressing and Ethernet is one of them An Ethernet physical address is 48 bits long. If the first 25 bits in an Ethernet address are 00000001 00000000 01011110 0, this identifies a physical multicast address for the TCP/IP protocol The remaining 23 bits can be used to define a group by which the multicast router extracts the lease significant 23 bits of a multicast IP address and inserts them into multicast Ethernet address

Mapping class D to Ethernet physical address

LAN Switches with Multicast Packets Switches that cannot understand multicast addresses will broadcast traffic sent to a multicast group to all the members of a LAN; in this case the system's network card (and operating system) has to filter the packets sent to multicast groups they are not subscribed to There are switches that listen to multicast traffic and maintain a state table of which network systems are subscribed to a given multicast group This table is then used to forward traffic destined to a given group only to a limited set of hosts (ports); this is done through the use of IGMP snooping

LAN Switches with Multicast Packets (cont.) Additionally, some switches with layer 3 capabilities can act as an IGMP querier In networks where there is no router present (or enabled) to act as a multicast router a switch might be used to generate the needed IGMP messages to get users to subscribe to multicast traffic

WLAN with Multicast Packets An 802.11 wireless local area network will handle multicast traffic differently, depending on the configuration of 802.11 power-save mode, DTIM (Delivery Traffic Indication Message), and beacon interval settings If power-save mode is disabled, then access points will deliver multicast traffic after each beacon (default interval = 100ms, but it can be adjusted)

WLAN with Multicasting (cont.) If power-save mode is enabled, the access point will deliver multicast traffic after each DTIM, which by default is every 1,2, or 3 beacon intervals in most access points As a result, the DTIM and beacon interval settings should be adjusted for optimum performance when implementing multicast in wireless networks

Network with No Multicast Support Most WANs do not support physical multicast address, thus to send a multicast packet through these networks, a process called tunneling is used In tunneling, the multicast packet is encapsulated in a unicast packet and sent through the network, where it emerges from the other side as a multicast packet