Multicast: Protocol and Implementation

Welcome to Week 12 Multicast: Protocol and 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 & 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 Multicast: Protocol & Implementation

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 Multicast: 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 Multicast: Protocol & Implementation

Using replicated unicast Rx Rx R Rx 1 3 9 S Rx R 1 Rx 2 R 2 R Rx Rx Rx Rx

Using multicast • 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 • [ Multicast: Protocol & Implementation

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 Multicast: 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 Multicast: Protocol & Implementation

Taxonomy of Multicast protocols Multicast routing Source based Tree Core based Tree PIM PIM-DM PIM-SM MOSPF DVMRP CBT Multicast: Protocol & Implementation

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

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 Multicast: 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 Multicast: Protocol & Implementation

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

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

Multicast Packets Prune Messages PIM-DM - pruning back Source Receiver Multicast: Protocol & Implementation

Multicast Packets PIM-DM - after pruning Source (S, G) State still exists in every router in the network, even after pruning back! Receiver Multicast: 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 Multicast: 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 Multicast: Protocol & Implementation

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

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

Source Traffic Flow Source Tree branch (S, G) Register (unicast) (S, G) Register-Stop (unicast) PIM-SM - sender registration stop RP (S, G) traffic begins arriving at the RP via the SST. 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’. Receiver Multicast: Protocol & Implementation

Source Traffic Flow Source Tree branch PIM-SM – ‘native’ multicast flow via RP RP Source traffic flows nativelyalong (part of) SST to RP. From RP, traffic flows downthe Shared Tree to Receivers. Shared Tree Receiver Multicast: Protocol & Implementation

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

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

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

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

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

PIM-SSM • 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 Multicast: 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 Multicast: 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 Multicast: 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? Multicast: 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 Multicast: 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. Multicast: 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’.) Multicast: Protocol & Implementation

Review topics for private study (1): PIM-SM • What is the purpose of the shared tree (RPT) in PIM-SM? • Which trees by-pass it? • Is a ‘by-pass’ tree always built? • Do all sources/receivers always use same RP? • Why does designated router (DR) initially tunnel data from sender S to RP? • How does it tunnel it, i.e., in what kind of (IP) packets? • What other function do these encapsulating packets perform? • What is the sequence of events which enables the DR to stop tunnelling S’s multicast data to the RP? • 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? Multicast: Protocol & Implementation

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

Multicast: Protocol and Implementation