1. Multicast Routing

2. Unicast: one source to one destination Multicast: one source to many destinations Two main functions: –Efficient data distribution –Logical naming of a group

3. Unicast Src

4. Unicast Src

5. Unicast Src

6. Unicast Src

7. Unicast Src

8. Unicast Src

9. Multicast Src

10. Multicast Src

11. Multicast Src

12. Multicast Src

13. Multicast Src

14. Multicast Src

15. Multicast state Router: –learn of the existence of multicast groups (advertisement) –identify links with group members –establish state to route packets replicate packets on appropriate interfaces

16. Logical naming Application level multicast: mailing lists Single address maps to logically related set of destinations Convenience Scaling: single name/address as group grows, changes

17. Multicast groups Members are the intended receivers Senders may or may not be members Destination address is class D IP address –globally known portion of address space Hosts may belong to many groups Hosts may send to many groups Support dynamic creation of groups, dynamic membership, dynamic sources

18. Scope Groups can have different scope LAN (local scope) Campus/admin scoping TTL scoping must be used with caution Concept of scope important to multipoint protocols and applications (later…)

19. Example applications Broadcast audio/video Push-based systems Software distribution Web-cache updates Teleconferencing (audio, video, shared whiteboard, text editor) Multi-player games

20. ..more applications Server/service location Distributed applications Sensor networks?

21. Other parts of the architecture Multicast address allocation (later) Assume address is advertised Avoid collisions as much as possible –Mcast address must be unique in space and time Use randomization Can’t have highly used address space Multiple multicast groups per conference…different app streams, different layers…more later

22. Some concepts Application level multicast Network level multicast Aside: active networks

23. Application-level multicast (another way) Src

24. ..application-level multicast Src

25. Components of the IP Multicast Architecture hosts routers service model host-to-router protocol (IGMP) multicast routing protocols (various)

26. IP Multicast Service Model (RFC-1112) each group identified by a single IP address groups may be of any size members of groups may be located anywhere in the Internet members of groups can join and leave at will senders need not be members

27. Service model Group membership not known explicitly Analogy: –each multicast address is like a radio frequency, on which anyone can transmit, and to which anyone can tune-in.

28. IP Multicast Addresses Class D IP addresses: in “dotted decimal” notation: 224.0.0.0 — 239.255.255.255 two administrative categories: –“well-known” multicast addresses, assigned by IANA –“transient” multicast addresses, assigned and reclaimed dynamically, e.g., by “sdr” program 1110group ID

29. IP Multicast Service — Sending uses normal IP-Send operation, with an IP multicast address specified as the destination must provide sending application a way to: –specify outgoing network interface, if >1 available –specify IP time-to-live (TTL) on outgoing packet –enable/disable loopback if the sending host is a member of the destination group on the outgoing interface

30. IP Multicast Service — Receiving two new operations: Join-IP-Multicast-Group( group-address, interface ) Leave-IP-Multicast-Group( group-address, interface ) receive multicast packets for joined groups via normal IP-Receive operation

31. Multicast Scope Control: (1) TTL Expanding-ring Search to reach or find a nearby subset of a group s 1 2 3

32. Multicast Scope Control: (2) Administrative TTL Boundaries to keep multicast traffic within an administrative domain, e.g., for privacy or resource reasons an administrative domain TTL threshold set on interfaces to these links, greater than the diameter of the admin. domain the rest of the Internet

33. Multicast Scope Control: (3) Administratively-scoped Addresses an administrative domain address boundary set on interfaces to these links the rest of the Internet –RFC 1112 –uses address range 239.0.0.0 — 239.255.255.255 –supports overlapping (not just nested) domains

34. The MBone MBone = Multicast Backbone an “interconnected” set of multicast- capable routers, providing the IP multicast service in the Internet can be thought of as a virtual network, overlaid on the Internet

35. Components of the MBone square/circle: thick square/circle: solid line: dashed line: thick line: host/router MBone router physical link tunnel part of MBone RR R H R H

36. a method for sending multicast packets through multicast-ignorant routers IP multicast packet is encapsulated in a unicast packet addressed to far end of tunnel: a tunnel acts like a virtual point-to-point link each end of tunnel is manually configured with unicast address of the other end MBone Tunnels IP header, dest = unicast IP header, dest = multicast transport header and data…

37. IGMP End system to router protocol is IGMP Member or process starts an application with mcast address IGMP process informed of joined mcast group When local router sends IGMP query, host sends IGMP report One router on LAN is IGMP querier Hosts listen to responses and suppress duplicates

38. Multicast Routing: IGMP

39. Components of the IP Multicast Architecture hosts routers service model host-to-router protocol (IGMP) multicast routing protocols (various)

40. Internet Group Management Protocol(IGMP) the protocol by which hosts report their multicast group memberships to neighboring routers version 1, the current Internet Standard, is specified in RFC-1112 operates over broadcast LANs and point-to-point links occupies similar position and role as ICMP in the TCP/IP protocol stack

41. Relevant Protocol Layers Within a Host IP Service Interface Link-Layer Service Interface Upper-Layer Protocol Modules IP Module Link-Layer Modules (e.g., Ethernet) IP to link-layer address mapping (e.g., ARP) ICMPIGMP

42. Link-layer Transmission/reception transmission: an IP multicast packet is transmitted as a link-layer multicast, on those links that support multicast the link-layer destination address is determined by an algorithm specific to the type of link (next slide) reception: the necessary steps are taken to receive desired multicasts on a particular link, such as modifying address reception filters on LAN interfaces multicast routers must be able to receive all IP multicasts on a link, without knowing in advance which groups will be sent to

43. for Ethernet and other LANs using 802 addresses: for point-to-point links: no mapping needed Mapping to Link-layer Multicast Addresses LAN multicast address

44. IGMP Version 1 Message Format Version1 Type1 = Membership Query 2 = Membership Report Checksumstandard IP-style checksum of the IGMP Message Group Addressgroup being reported (zero in Queries) Vers.TypeReservedChecksum Group Address

45. How IGMP Works on each link, one router is elected the “querier” querier periodically sends a Membership Query message to the all-systems group (224.0.0.1), with TTL = 1 on receipt, hosts start random timers (between 0 and 10 seconds) for each multicast group to which they belong Qrouters: hosts:

46. How IGMP Works (Cont.) when a host’s timer for group G expires, it sends a Membership Report to group G, with TTL = 1 other members of G hear the report and stop their timers routers hear all reports, and time out non- responding groups Q GGGG

47. How IGMP Works (Cont.) note that, in normal case, only one report message per group present is sent in response to a query (routers need not know who all the members are, only that members exist) query interval is typically 60—90 seconds when a host first joins a group, it sends one or two immediate reports, instead of waiting for a query

48. IGMP Version 2 changes from version 1: –new message and procedures to reduce “leave latency” –standard querier election method specified –version and type fields merged into a single field backward-compatible with version 1 soon to appear as a Proposed Standard RFC widely implemented already

49. Multicast Routing

50. Multicast service model makes it hard to locate receivers –anonymity –dynamic join/leave Options so far (not very efficient) –flood data packets to entire network, or –tell routers about all possible groups and receivers so they can create routes (trees)

51. Early Routing Techniques Flood and prune –begin by flooding traffic to entire network –prune branches with no receivers –unwanted state where there are no receivers Link-state multicast protocols –Routers advertise groups for which they have receivers to entire network –compute trees on demand –unwanted state where there are no senders

52. Rendezvous Options Broadcast initial packets from each source to entire network; non-members prune –examples: DVMRP, PIM-DM Broadcast membership advertisement from each receiver to entire network –example: MOSPF Specify “meeting place” to which sources send initial packets, and receivers join; requires mapping between multicast group address and “meeting place” –examples: CBT, PIM-SM

53. Shared vs Source-based Trees Source-based trees –separate shortest path tree for each sender Shared trees: –single tree shared by all members –data flows on same tree regardless of sender

54. Multicast Tree Taxonomy Multicast routing can build different types of distribution trees separate tree rooted at each data source (DVMRP, MOSPF, PIM-DM, PIM-SM) shared tree rooted at group core/rendezvous point (CBT, PIM-SM)

55. A Shared Tree RP

56. Source-based Trees

57. Shared v.s. Source-Based trees Source-based trees –shortest path trees - low delay, better load distribution –more state at routers (per-source state) –efficient for in dense-area multicast Shared trees –higher delay (bounded by factor of 2), traffic concentration –per-group state at routers –efficient for sparse-area multicast

58. Protocol Taxonomy DVMRP - source-based trees MOSPF - source-based trees PIM - shared and source-based trees

59. Distance-vector Multicast Routing Protocol (DVMRP)

60. DVMRP consists of two major components: – a conventional distance-vector routing protocol (like RIP) – a protocol for determining how to forward multicast packets, based on the routing table Distance-vector Multicast Routing Protocol

61. Multicast Forwarding A DVMRP router forwards a packet if –the packet arrived from the link used to reach the source of the packet (Reverse path forwarding - RPF) similar (but not quite the same) to flooding each packet once –if downstream links have not pruned the tree

62. Example Topology gg s g

63. Phase 1: Flood Using Truncated Broadcast gg s g

64. Phase 2: Prune gg s prune (s,g) g

65. graft (s,g) Phase 3: Graft gg s g g report (g)

66. Phase 4: Steady State gg s g g

67. Multicast Routing: MOSPF

68. Multicast OSPF (MOSPF) Add-on to OSPF (Open Shortest-Path First, a link-state, intra-domain routing protocol) Multicast-capable routers flag link state routing advertisements Each router indicates groups for which there are directly-connected members

69. MOSPF (Cont.) Link-state advertisements augmented with multicast group addresses to which local members have joined Link-state routing algorithm augmented to compute shortest-path distribution tree from any source to any set of destinations

70. S1 R1 R2 X Y Z Link state: Each router floods link state advertisement Multicast: add membership information to “link state” Each router computes multicast tree for each active source, builds forwarding entry with outgoing interface list.

71. S1 R1 R2 X Y Z has network map, including membership at X and Y Z computes shortest path tree from S1 to X and Y Z builds multicast entry with one outgoing interface W, Q, R, each build multicast entries Z W Q R

72. R1 R2 X Y Z W Q R S1 Link state advertisement with new topology may require re-computation of tree and forwarding entry

73. R1 R2 X Y Z W Q R S1 T R3 Link state advertisement (T) with new membership (R3) may require incremental computation and addition of interface to outgoing interface list (Z)

74. Impact on Route Computation Can’t pre-compute all source multicast trees Compute on demand when first packet from a source S to a group G arrives Forward packet onto outgoing interfaces that correspond to local portion of the tree

75. Cores, Centers, and Rendezvous Points

76. Rendezvous With source-based trees senders and receivers meet by: –flooding and pruning –LS distribution of group and receiver state How do we solve the problem with shared trees? –establish a meeting place: center, core or rendezvous point

77. Using a Core to Construct a Tree Core

78. Data Flow When Sender Is Near Core Core S

79. Data Flow When Sender Away From Core Core S

80. Observations Core placement affects efficiency Finding the optimal core location is an NP- hard problem - use heuristics For dynamic groups core location may have to be calculated frequently Need multiple cores for robustness

81. Problems to Be Solved How to perform group address to core address mapping (especially with multiple cores) How to chose the location of the core to maintain efficient distribution trees How to construct the tree given the core address

82. Multicast Routing: PIM http://netweb.usc.edu/pim/

83. Advanced Multicast Routing Introduction limitations of previous approaches for wide- area, internet-wide multicast Protocol Independent Multicast (PIM) how multicast distribution trees are built rendezvous point mechanisms packet formats and processing interoperability

84. Efficient Point-to-multipoint Distribution for Global Internets Context wide-area internet heterogeneous bandwidth and ownership Preserve IP Multicast model based on Deering’s thesis simple end-system model (IGMP) scalability based on receiver-initiated joining to closest point on existing distribution tree no receiver-specific state in routers

85. Multicast Distribution Tree Example S1 R1 R2R3 R4 R5 Source-specific forwarding entry: incoming: 1 outgoing: 2, 3 1 2 multicast distrib. tree links to rest of network 3

86. Broadcast-and-prune (DVMRP) Simple, data-driven broadcast first packets throughout network routers with no downstream members send prune messages and store prune state Does not scale well as a long-term, general solution for internet-wide multicast broadcast and prune has excessive bandwidth and state overhead for sparse groups in the wide area

87. Broadcast-and-prune Overhead S1 R1 R2 multicast distrib. tree broadcast-and-prune overhead

88. Protocol Independent Multicast (PIM) Protocol Independent Multicast — Dense Mode (referred to as PIM-DM) similar to DVMRP (broadcast-and-prune), but without unicast routing protocol exchange — uses existing unicast protocol for RPF check Protocol Independent Multicast – Sparse Mode (also referred to as PIM, or PIM-SM)

89. PIM Terminology incoming interface (iif): interface from which multicast packet is accepted and forwarded outgoing interface list (oif list): interfaces out which multicast packets are forwarded Rendezvous Point (RP): used in PIM as alternative to broadcast Designated Router (DR): one router per multi-access LAN elected to track group membership, and then Join/Prune accordingly

90. PIM Terminology (Cont.) Shared tree: reverse-shortest-path tree rooted at RP Source-specific tree: reverse-shortest-path tree rooted at source. Also referred to as Shortest Path Tree (SPT) Entry: Multicast forwarding state for a particular source-specific or Shared tree Reverse-path forwarding (RPF) check: checks if a packet arrived on the interface used to reach the source of the packet

91. PIM Protocol Overview Basic protocol steps –routers with local members Join toward Rendezvous Point (RP) to join Shared Tree –routers with local sources encapsulate data in Register messages to RP –routers with local members may initiate data-driven switch to source-specific shortest path trees Soft state: periodic state-driven refreshes, time-out idle state See PIM v.2 Specification (RFC2362)

92. RP R1 R2 R3 R4 Join message toward RP Shared tree after R1,R2,R3 join PIM Example: Build Shared Tree (*, G)

93. Data Encapsulated in Register RP R1 R2 R3 R4 S1unicast encapsulated data packet to RP in Register RP decapsulates, forwards down shared tree (*, G)

94. RP May Ask High-rate Src to Join RP R1 R2 R3 R4 S1 (S1, G)

95. Another Example RP R1 R2 R3 R4 S1 (*, G)

96. Packets Sent on Longest Match RP R1 R2 R3 R4 S1 (S1, G), (*, G) (*, G) (S1, G) (S1, G), (*, G) S2 (S2, G)

97. Build Source-specific Distribution Tree RP R1 R2 R3 R4 Join messages toward S1 RP distribution tree Build source-specific tree for high data rate source S1 (S1, G) (*,G) (S1, G) (S1, G), (*,G) (S1, G) (*,G) (*, G)

98. Forward Packets on “Longest- match” Entry RP R1 R2 R3 R4 R5 S1 Source (S1)-specific distribution tree Shared tree Source-specific entry is “longer match” for source S1 than is Shared tree entry that can be used by any source (S1, G) (*,G) (S1, G) (S1, G), (*,G) (S1, G) (*,G) (*, G)

99. Prune S1 off Shared Tree to Avoid Duplicates RP R1 R2 R3 R4 R5 S1 S1 distribution tree Shared tree Prune S1 off shared tree where iif of S1 and RP entries differ

100. RP sends Register-Stop to S1 when packets received natively RP R1 R2 R3 R4 R5 S1 S1 distribution tree Shared tree RP unicasts Register-Stop to S1

101. Join/prune Message Creation Each PIM router generates periodic Join/Prune messages based on active state entries Join/Prune message sent to neighbor N includes all currently joined and pruned sources, or RPs, reached via N –If source-specific entry has non-null oif list, and N is RPF neighbor for source, Join list includes source – If source-specific entry has null oif list, and N is RPF neighbor for source, Prune list includes source – If source-specific entry has different iif than active RP-tree entry, and N is RPF neighbor for RP, Prune list includes source (with special flag set)

102. Join/prune Message Processing Each PIM router updates timers, adds or deletes from oif list, or generates new forwarding entry altogether based on incoming Join/Prune messages Similar actions used for all types of trees/entries: source-specific (S,G), Shared tree (*,G), and aggregated Shared tree (*,*,RP) Each router uses the hash algorithm to determine the correct RP for a group

103. Register Message Creation and Processing When locally-originated data packet arrives for which no source-specific forwarding entry exists, DR creates entry and initializes it with the Register-bit set; DR encapsulates data packet in Register message and unicasts it to the RP When locally-originated data packet arrives for which there is a source-specific forwarding entry with Register bit set, DR encapsulates data packet in Register message and unicasts it to the RP RP decapsulates Register packet and forwards it according to longest match

104. Multi-access LAN Example Source Receiver1Receiver2 Router X has better path to Source Two issues: (1) X and Y both forward Source’s packets to LAN (2) Z and W both generate periodic Joins X Y is Designated Router Z W RP

105. Operation Over Multi-access LANs Designated Router (DR) election Assert messages used to elect single forwarder in presence of parallel paths upstream of LAN –metric based on unicast routing metrics and metric preference values Join/Prune message generation suppressed by other downstream router(s) on the LAN (Joiner- bit) in presence of multiple downstream branches

106. Adaptation to Changes Unicast routing –incoming interface updated –Join/Prune messages redirected; RPF check fails on old iif –delay proportional to unicast routing convergence RP unreachability or failure –RP mapping updated based on periodic refreshes –some added timer-driven delay

107. RP Mechanism RP location need not be optimized, but consistent RP mapping and adaptation to failures is CRITICAL –all routers (within PIM region) must associate a single active RP with a multicast group Routers use algorithmic mapping of Group address to RP from manageably- small set of RPs known throughout region

108. RP Mechanisms — Overview Each candidate RP indicates liveness to Bootstrap Router in the PIM region Bootstrap Router distributes set of reachable candidate RPs to all PIM routers in region Each PIM router uses the same hash function and set of RPs to map a particular multicast group address to that group’s RP

109. Primary Design Features Keep multicast host interface simple: end-systems only need “logical” multicast address to send or receive RP address is network level address—not logical address end-systems should require only multicast address to send and receive routers should map multicast address to RP address and adapt to unreachability/change of RP

110. Primary Design Features (Cont.) No “on-demand” retrieval of RP information—avoids start-up phase can’t join or send until DR gets RP address “bursty source” problem (if Primary RP unreachable) until DR identifies active RP global distribution of explicit group to RP mapping and reachability not scalable Use a priori status distribution like unicast routing—track liveness continuously, not on demand small set of RPs known throughout region

111. Bootstrap Router Bootstrap Router function –construct set of RPs (RP set) based on Candidate RP advertisements –periodically distribute RP set in Bootstrap messages to all routers in region Bootstrap messages propagated/flooded hop- by-hop to all routers in PIM region –messages sent periodically and triggered when RP set changes Bootstrap Router should be well-connected for stability, and dynamically elected for robustness

112. Bootstrap Router Election Simple bridge-like spanning-tree election algorithm Candidate Bootstrap Routers originate PIM hop-by-hop Bootstrap messages with IP address and configurable preference value Bootstrap messages exchanged by all PIM routers within region Most preferred (or highest numbered) reachable Candidate Bootstrap Router elected Sent periodically and triggered

113. All Routers Use Hash Function to Map Group Address to RP Hash function –input: group address G and address of each candidate RP in RP set (with optional Mask) –output: Value computed per candidate RP in RP set –RP with highest value is the RP for G Desirable characteristics –minimize remapping when RP reachability changes — remap only those that lost RP –load spreading of groups across RPs

114. Hash Function For each candidate RP address RPi, whose Group-prefix covers G, compute a value: value((G&M), RPi) = [ 1103515245 x ( ( 1103515245 x (G&M) + 12345) XOR RPi ) + 12345 ] mod 2 31 standard C equivalent: srand(G&M); srand(rand() ^RPi); value = rand(); hash-mask, M, allows small number of consecutive groups to hash to same RP

115. Adaptation to RP (Un)Reachability Simplified adaptation to RP (un)reachability When Candidate RP fails/unreachable –Bootstrap Router times it out –Bootstrap message distributed with updated RP set –Routers hash affected groups to different RP No “bursty source” problem; RP liveness known a priori from RP set (like unicast routing)

116. Scaling Multicast Routing Dense-mode protocols –Don’t scale because of occasional data message flooding PIM and tree-based protocols –Don’t scale because of bootstrap flooding Inter-domain multicast –Multicast Source Distribution Protocol (MSDP) –Source-Specific Multicast (SSM)

117. MSDP Ties multiple PIM-SM domains together Intended to be an intermediate solution –Since it too has scaling problems –Currently deployed in the Internet and has been operational Basic idea: –Flood announcements for sources to every AS –AS border routers that have local receivers join towards the source

118. MSDP Peerings Each AS border router that is usually configured to be an RP –Maintains an MSDP peering with a neighboring router Peerings are congruent with BGP peerings –Also, MSDP uses BGP information to flood source announcements and send joins

119. MSDP Source-active Messages Suppose a source A in domain D sends to group G RP, which is also a BR, gets PIM register from source A RP sends Source-Active MSDP message to its peers –Contains source A and group G Source-Active messages forwarded –In peer-RPF fashion Message from non peer-RPF neighbors discarded –Recall Deering RPF Similar poison-reverse optimizations apply Use BGP information for this

120. MSDP Joins RP that has a non-null (*,G) entry for group G –Sends an MSDP join towards source A Join forwarded hop-by-hop along MSDP peers towards domain containing A –Use BGP information to determine the next hop Other optimizations: –Source-Active messages can contain encapsulated data

121. MSDP and the Ramen Worm DOS attack possible on multicast Ramen worm sent packets with random multicast destination addresses Causes a flood of Source-Active Messages –Bringing down a lot of the multicast infrastructure!

122. Changing the Service Model What we’ve discussed so far –Any source multicast Problems: –How do you charge users? –How do you manage the bandwidth allocation? –How can you ensure secure communication? –All of these are still research topics Other problems –Multicast state aggregation Is there a simpler alternative we can deploy now?

123. Single Source Multicast (SSM) ISP acceptance will be higher –If the multicast service model restricted the senders –If there was a way to figure out how many receivers there were They can then have a viable billing and accounting model Simplest such scheme –Single-source per multicast group –Receivers can still join and leave at will

124. SSM Groups A group in SSM is denoted by (S,G) –S is the source’s address –G is the group identifier Address allocation –Aside: we haven’t talked about multicast address allocation –But this immediately solves the multicast address allocation problem! Unlike for any source multicast, G doesn’t have to be globally unique

125. SSM Details Receiver specifies that it wants to join source S on group G –But this is already being designed in IGMP v3! Routers send source-specific joins towards S –But PIM-SM already does this! Only source S allowed to send traffic to group G –Routers silently drop other traffic if there is no state Note that we don’t need a special inter-domain multicast routing protocol!

126. SSM Status Currently being standardized and is partially deployed So, if 90% of multicast applications can use SSM, and the rest need MSDP –Do we need anything more for Internet multicast?