3/14/2016Multicast: Protocol & Implementation Nasir Faruk (I am grateful to Jonathan Couzens, JANET(UK), and Cisco for the originals from which the PIM-SM diagrams were derived.) Multicast: Protocol and Implementation Welcome to Week 12

3/14/2016Multicast: Protocol & Implementation IP Multicast: topics Flash back ! Isuues associated with multicast –sparse & dense mode –group membership Single-domain multicast –RPF, RPB & RPM recap –PIM-DM –PIM-SM Inter-domain or multi-domain multicast –MSDP

Issues for multicast I Identifying group members –Neither unicast nor broadcast are adequate –Achieved with special addressing scheme for active participants Tracking current group membership –Uses a dynamic membership protocol –Not required for fixed groups Efficient distribution mechanism –To avoid multiple copies of same information traversing same part of network –Network must be multicast-aware –Capable of packet replication and controlled flooding Multicast routing scheme to maintain fault-tolerant distribution topology 3/14/2016Multicast: Protocol & Implementation

Issues for multicast II Scaling –how to deal with large numbers of users (100s, 1,000s, …)? –affects network and end stations –reliable unicast protocols need acknowledgements from receiver to sender reliable multicast cannot operate in the same way Timing –a much more complex set of issues in group communication since there are more than two views of time –group aspects are primarily end host application concerns, not network 3/14/2016Multicast: Protocol & Implementation

Using replicated unicast S Rx R R R R

Using multicast 3/14/2016Multicast: Protocol & Implementation An immediate scaling problem: -multipoint conference: all senders need to reach all receivers with each stream –audio, video, shared applications (eg, whiteboard, powerpoint, excel) Problems with using replicated unicast (recap.): ─senders will (with large number of receivers) be overloaded ─links near senders will also be overloaded ─delay will increase: sender sends many copies sequentially ─large conferences, TV distribution, etc., will be impossible Solution: eliminate multiple copies of same packet on any link and from sender ensure ‘best’ routes are used: much harder [

Types of Multicast Tree SENDER-BASED (AS PREVIOUS DIAGRAM) ALSO CALLED SOURCE BASED TREE –EACH ROUTER needs to have one shortest path tree for each group –If the number of the group is m, each router need s to have m SPTs, one for each group. –Sender based tree (SBT) is where the tree is routed at the sender –SBT is most economical way of doing isolated multicast in a network –SBT is not static like in the case of spanning tree protocol its changes as the number as host changes so the router has to agile enough. –E.g. I got no people here I don’t need to send any packet here, I got many ppl here I need to send more packet here CORE-BASED (GROUP SHARED TREE) –ONLY THE CORE ROUTER, which has a SPT for each group is involved in multicasting –Instead of each router having m SPTs, only one router (i.e. center/core or RENDEZOUS ROUTER takes responsibility for distributing multicast traffic. –compromise 3/14/2016Multicast: Protocol & Implementation

DM / SM Protocols There are two ways of distributing multicast: Dense Mode: Dense Mode is sending the multicast packet to everyone in the group. Periodically sending to everybody it important when you got a lot of people in a company LAN but it wont woke in th IP internet u got periodic saturation Sparse Mode: –-in spare mode you send when someone sign on –Typified by ‘send on request’ behaviour –group membership (though actually, it’s likely needed anyway). –End-system gets nothing unless it explicitly asks for it –Appropriate when: –only some of hosts want to receive –scope is potentially worldwide 3/14/2016Multicast: Protocol & Implementation

Taxonomy of Multicast protocols 3/14/2016Multicast: Protocol & Implementation Multicast routing Source based Tree Core based Tree MOSPFDVMRP PIM PIM-DM PIM-SM CBT

Reverse Path Forwarding Crucial to understanding wide-area multicasting How a router determines whether to forward a multicast packet and, if so, where to…. Unicast forwarding: recall –works by looking up the destination address in a routing table and forwarding to the associated interface (for next-hop router) Multicast forwarding –look up the source address in the routing table –did the packet arrive on the interface to which a packet would have been sent if that address had been the destination address? this is the ‘RPF check’ –if so, forward it out of all the multicast-enabled interfaces except for the one on which it arrived –if not, drop packet (silently) –Eliminate flooding and looping : Only one copy is forwarded; the other copies are dropped Central idea for PIM: uses unicast routing tables, independently of how these are established and maintained 3/14/2016Multicast: Protocol & Implementation

Concepts and terminology RPF (Reverse Path Forwarding) applied to flooding eliminates loops but still leaves the possibility of a subnet receiving multiple copies of packets: a feature of delivery based on source instead of destination RPB (Reverse Path Broadcast) to cure above problem, for each source, choose a single router to be parent for delivery of multicast packets to a subnet: called designated parent router (DR) still a broadcast procedure, no membership information used: reverse path broadcast DR is that with smallest cost to sender, determined using link-state or poison- reverse with distance-vector (& lowest IP address if ‘tie’); PIM-SM has own election scheme TRPB (Truncated Reverse Path Broadcast) truncation uses membership info to avoid forwarding pkt to subnet with no members RPM (Reverse Path Multicast) to remove receipt of packets on unwanted multicast addresses, pruning may be used; grafting may be used to resume receipt sometimes known as reverse path multicast pruning & grafting require use of a group membership protocol uses group membership info to construct genuine multicast tree 3/14/2016

Multicast: Protocol & Implementation Group membership IGMP is used for hosts to join a group. Join and Report messages are sent to the multicast address of the group which the host wishes to join. –a host does not need to know the address of a multicast router –a host responds to router membership Query messages by setting a random timeout after which it transmits a Report about its membership –a host hears the Reports from other hosts on its subnet: if it hears a Report about its own group in the interval, it does not need to respond to the router until another Query is heard Remember, IGMP is a host-router protocol. Exchange of information between routers is a matter for other (routing) protocols (if any). –IGMP Report and Join are sent with TTL=1: not forwarded by routers –strictly: it is only needed for: sparse-mode protocols receivers: a host may send to any group without being a member –dense-mode protocols assume all hosts receive all groups until told otherwise

3/14/2016Multicast: Protocol & Implementation Protocol-Independent Multicast (PIM) Terminology: –For each multicast flow, a router may need to keep state relating to: (S,G) - source S, sending to group G (*,G) - all sources for group G –Typically, needs to remember whether and where to forward packets Router-to-router protocol Protocol-independent –uses existing - unicast - routing information –independent of underlying – unicast - routing protocol(s) Two flavours (at least!) –Dense-Mode: RFC3973 (January 2005) like a successor to DVMRP –Sparse-Mode: reworked: RFC2362 (August 2006) – standards track Single-source mode Bi-directional-mode

3/14/2016Multicast: Protocol & Implementation PIM Dense-Mode: PIM-DM A dense-mode protocol Flood-and-prune Distribution tree for the traffic rooted at the source

3/14/2016Multicast: Protocol & Implementation PIM-DM - initial flooding Source Receiver Multicast Packets (S, G) State created in every every router in the network!

3/14/2016Multicast: Protocol & Implementation PIM-DM - pruning back Source Receiver Multicast Packets Prune Messages

3/14/2016Multicast: Protocol & Implementation PIM-DM - after pruning Source Receiver Multicast Packets (S, G) State still exists in every every router in the network, even after pruning back!

3/14/2016Multicast: Protocol & Implementation PIM-DM Appropriate if –scope is local, e.g., financial dealing rooms –virtually all want to receive the traffic Not so good if –few want the traffic –global transmission Undesirable! Especially for sites with low-speed access

3/14/2016Multicast: Protocol & Implementation PIM Sparse-Mode: PIM-SM A sparse-mode protocol –traffic only received if explicitly requested –but have to know what to ask for…. as with any sparse-mode, membership-based protocol, need to know which group to listen to: like knowing which radio or TV channel to select To avoid propagation of state throughout all routers, PIM-SM has the concept of a rendezvous point (RP) –indirectly, Receivers JOIN to the RP –and, also indirectly, Senders REGISTER with the RP –actually, member hosts just IGMP join to local last-hop router; it is last- hop router which knows about and communicates with RP –strictly, Designated Router (DR): all rtrs receive join, only DR acts on it Two distribution trees involved: –Shared tree, rooted at the RP RP tree or RPT –Source-specific tree (SST), rooted at the source DR All last-hop routers in domain need to know RP location

3/14/2016Multicast: Protocol & Implementation PIM-SM – (receiver) join Receiver RP (*, G) Join Shared Tree (*, G) State only, created along the new branch of the Shared Tree.

3/14/2016Multicast: Protocol & Implementation PIM-SM - sender registration & SST Receiver RP (S, G) Join Source Shared Tree Source Tree branch (S, G) State only, created along (part of) Source Specific Tree (SST). Traffic Flow (S, G) Register (unicast) Unicast Register includes encapsulated (tunnelled) multicast packet

3/14/2016Multicast: Protocol & Implementation PIM-SM - sender registration stop Receiver RP Source Shared Tree RP sends a Register-Stop back to the first-hop DR (which is unaware Join originated by RP) to stop the Register process, since RP now receiving ‘natively’. (S, G) Register-Stop (unicast) Traffic Flow (S, G) traffic begins arriving at the RP via the SST. (S, G) Register (unicast) Source Tree branch

3/14/2016Multicast: Protocol & Implementation PIM-SM – ‘native’ multicast flow via RP Receiver RP Source Shared Tree Traffic Flow Source traffic flows natively along (part of) SST to RP. From RP, traffic flows down the Shared Tree to Receivers. Source Tree branch

3/14/2016Multicast: Protocol & Implementation PIM-SM - source-specific shortest path tree (SPT) Receiver RP (S, G) Join Source SST / SPT Shared Tree Last-hop DR joins SST. Additional (S, G) State is created along new part of the SST: SPT. Traffic Flow

3/14/2016Multicast: Protocol & Implementation PIM-SM – switchover to SPT: creation and prune to RP Receiver RP Source Source Tree Shared Tree (S, G) RP: Prune by-passed part of Shared Tree Traffic begins flowing down the new branch of the SST: SPT. RPF check triggers dropping of packets from RP & additional (S, G) state creation along the RP Shared Tree to prune off (S, G) traffic. Traffic Flow

3/14/2016Multicast: Protocol & Implementation PIM-SM – use of SPT Receiver RP Source Source Tree Shared Tree (S, G) traffic flow is now flowing to the Receiver via the SPT. Traffic Flow (S, G) traffic flow from RP has been pruned off the Shared Tree and ceases to flow.

3/14/2016Multicast: Protocol & Implementation PIM-SM - source tree switchover Receiver RP Source Source Tree Shared Tree (S, G) traffic flow is no longer needed by the RP so it Prunes the flow of (S, G) traffic. Traffic Flow (S, G) Prune

3/14/2016Multicast: Protocol & Implementation PIM-SM – RPT / SPT switchover completed Receiver RP Source Source Tree Shared Tree (S, G) Traffic flow is now only flowing to the Receiver via the SPT part of SST. Traffic Flow

PIM-SSM 3/14/2016Multicast: Protocol & Implementation Optimized delivery of common applications like IPradio and IPTV are provided by source-specific trees PIM-SM can construct SSTs but not under user control Source-Specific Multicast provides support for user-requested use of an SST for a specific sender –IGMP is augmented to enable a user to request connection to a multicast address and sender using an SST –Minor changes to PIM-SM enable its existing capability to be triggered by such requests, thus extending the service directly to users

3/14/2016Multicast: Protocol & Implementation PIM-SM - RPs & bootstraps Which is the best router to be the RP for a network? –Needs to be ‘well-connected’: in the ‘centre’ of a network? –But note that, if global multicast connectivity required, RP will need efficient path to peer RPs: so, at the edge? –Depends on network configuration and traffic patterns. More than one RP possible –Dedicate one (or more) RP to local groups and place it (them) centrally –Have other(s) for global groups and placed nearer the edge Within a single network, all RPs are part of single network management domain A set of routers designated as candidate RPs Bootstrap router: –knowledge of which RPs are active, updated by regular messages –distributes this to domain routers, including RPs Set of candidate bootstrap routers –one elected: other bootstraps & RPs kept updated

3/14/2016Multicast: Protocol & Implementation IP Multicast: topics ‘Recap’ –Mbone –sparse & dense mode –group membership Single-domain multicast –RPF, RPB & RPM recap –DVMRP –PIM-DM –PIM-SM Inter-domain or multi-domain multicast –MSDP

3/14/2016Multicast: Protocol & Implementation Multidomain Multicasting Domains are management domains Each domain has its own RP(s), known to routers in that domain RP is not generally known outside its own domain So, how does multicast traffic flow between domains? For PIM-SM to work, RPs need to know about membership of a given group It knows about those within its own domain, but how can it know about those in other domains?

3/14/2016Multicast: Protocol & Implementation Multidomain Multicasting Receivers? –RP waits for receiver to join then it establishes the shared tree to it Receivers in another domain? –Always dealt with by the (an) RP in the receiver’s own domain Senders? –RP will send join towards any sender, once RP knows about it Sender router only registers with its own RP RPs need to know about senders in other domains, i.e., need to exchange (S,G) state information –Currently, use Multicast Source Distribution Protocol (MSDP) has experienced problems; not necessarily long-term solution –BGP being extended to exchange routing information for multicast sources as well as the usual interdomain unicast routes Given that all RPs know about all (S, G)s, sender trees can be built. This (BGP and MSDP) remains an active area of work. NB: PIM-SSM works directly in a multi-domain context

3/14/2016Multicast: Protocol & Implementation Multicast protocol refs: books: DVRP, PIM-SM, MSDP Wittman & Zitterbart: Multicast Communication –Chapter 3. Forouzan: Data Communications and Networking (4th ed.) –Sections 21.3 & 21.4: reasonable introduction to IGMP: NB, it is IGMPv2- based: IGMPv3 is published but not yet deployed everywhere. (IGMPv3 has some extra options such as source-specific join and leave/prune.) –Sections 22.4 has a reasonable discussion but much is based on MOSPF, not discussed in this course. PIM-SM is mentioned but not covered. Peterson & Davie: Computer Networks (4th ed.) –Section 4.4: this has been expanded in this edition and includes a brief description of PIM-SSM as well. Stallings: High-Speed Networks (2nd ed.) –Section 16.2: too brief, more detail needed.

3/14/2016Multicast: Protocol & Implementation Multicast protocol refs: IETF docs: DVRP, PIM-SM, MSDP RFC 1075: DVMRP –care: this is quite old (when Mbone was new): mixes Mbone tunnelling with description of routing protocol. RFC 4601: PIM-SM (Section 3 up to 3.3 inclusive.) –This version is fairly recent. It fixes a number of problems associated with overlapping / intersecting trees and the fact that ALL the operations of tree building (registering/joining) and tear-down (register stopping/pruning) are asynchronous, so may occur in any order. It also enhances edge router functionality (not covered in the course). –Where notations differ, this course uses that from this version of PIM-SM. RFC 3618: MSDP (only recently deployed; complicated; only overview needed) Internet drafts (see P00556 ‘supporting material’) –draft-ietf-mboned-intro-multicast-03.txt: ‘Introduction to IP Multicast Routing’ (Beware: this is now old wrt the status of multicast deployment and protocols in use; use only as technical introduction to protocols; uses Mbone to mean, roughly, ‘the multicast-enabled or -connected parts of the Internet’.)

3/14/2016Multicast: Protocol & Implementation Review topics for private study (1): PIM-SM 1.What is the purpose of the shared tree (RPT) in PIM-SM? 2.Which trees by-pass it? 3.Is a ‘by-pass’ tree always built? 4.Do all sources/receivers always use same RP? 5.Why does designated router (DR) initially tunnel data from sender S to RP? 6.How does it tunnel it, i.e., in what kind of (IP) packets? 7.What other function do these encapsulating packets perform? 8.What is the sequence of events which enables the DR to stop tunnelling S’s multicast data to the RP? 9.After (8), assuming the shared RP tree is still in use for S’s data to G, what has been put in place in the intervening routers which enables (S,G) packets forwarded by the DR to reach the RP?

3/14/2016Multicast: Protocol & Implementation Review topics for private study (2) 10.What prevents an IGMP router query from causing the router to be overloaded by host reports in response? Explain. 11.How is the designated router (DR) selected for a subnet? Is it necessarily the same for all groups? 12.Do both senders and receivers have to join a group in a sparse-mode protocol? 13.In RPB (or RPM), what does having a DR achieve for delivery to that subnet?