1. Ahmed Helmy - UF1 Protocol Design Concept: Soft State vs. Hard State Soft State: –A state is refreshed periodically, and if it is not refreshed it times out and is removed. –Example: –in PIM-SM a state is created by the receipt of a Join message. –A Join message is not acknowledged, but is sent periodically (every minute approx.)

2. Ahmed Helmy - UF2 –A router maintains an entry timer for every state created. –When a router receives a Join it restarts (or refreshes) that timer. –When a router does not receive a Join for approx. 3 x Join refresh period (approx 3 min.s) it times out the timer and the entry is removed.

3. Ahmed Helmy - UF3 Hard state A state in a router is created once, and it remains until another message is sent to remove it. Usually uses an acknowledged message, Simple example: –DVMRP uses a graft message to create a state.

4. Ahmed Helmy - UF4 The graft message is acknowledged. When a router receives a graft, it creates the state, and the state remains until a prune is sent to remove the forwarding state in that router.

5. Ahmed Helmy - UF5 Advantages and disadvantages For soft state: Since, in general, it is not acknowledged, it may lead to 'join latency'. For example, if a receiver joins the group and the join is lost, it has to wait until the next refresh period to send another join.

6. Ahmed Helmy - UF6 In hard state: Since, in general, it is acknowledged, it incurs less join latency (since the ack timer is probably 3 seconds while the refresh timer is approx 1 min.). The main advantage for soft state (vs. hard state) is its robustness to failures.

7. Ahmed Helmy - UF7 Crash scenarios: If A sends a graft message, it gets acknowledged, and B creates state –A crashes and loses state –State will remain permanently in B Packets will keep on getting to A unless/until a prune is sent

8. Ahmed Helmy - UF8 If router B crashes and comes back up again, there is no way to recreate the state in B (because A already got ack for its graft). So DVMRP uses periodic broadcast to take care of this situation. In PIM-SM, the soft state (periodic refresh) mechanisms take care of the above crash scenarios.

9. Ahmed Helmy - UF9 Host ABC 1. IGMP Host- Membership Query 2. IGMP Host- Membership Report for G 3. Create (*,G) entry: Multicast address=G RP-address=C,WC=1,RP=1 outgoing interface list={1} incoming interface=2 4. Send Join/Prune message to B: Multicast address=G Join={C,WC,RP} Prune=Null 5. Create (*,G) entry: Multicast address=G RP-address=C,WC=1,RP=1 outgoing interface list={1} incoming interface=3 6. Send Join/Prune message to C: Multicast address=G Join={C,WC,RP} Prune=Null D 7. Create (*,G) entry: Multicast address=G RP-address=C,WC=1,RP=1 outgoing interface list={1} incoming interface=Null 121 2 31... Receiver LANPIM DR/IGMP Querier for LAN Rendezvous Point (RP) for group G Receivers Joining the Shared Tree

10. Ahmed Helmy - UF10 Host A CX D 1. Data packets for G 2. Create (S,G) entry incoming interface=1 3. Encapsulate Data packets in Register messages and unicast to RP(C) 4. Initiate (S,G) packet counter 5. If (*,G) state exists then decapsulate Registers and forward packets to oiflist (*,G) 6. If Register data rate > Threshold then create (S,G) entry: outgoing list=oiflist (*,G)-{2} incoming interface=2 RP=0,SPT=0 7. Send Join/Prune message to X: Multicast address=G Join={S}, Prune=Null 8. Create (S,G) entry: outgoing list={1} incoming interface=2 9. Send Join/Prune message to D: Multicast address=G Join={S},Prune=Null 10. Update (S,G) entry: add 2 to outgoing interface list 11. When receive (S,G) native packets set SPT bit for (S,G) entry, & trigger Register-Stop message to D 12. When receiver Register-Stop stop encapsulating packets Receiver Source LAN(B) DR for LAN(B) 1 2 1 2 1 2 Rendezvous Point (RP for group G 1 2 Host Sending to the Group

11. Ahmed Helmy - UF11 Host ABC 1. Receive S’s packets on shared RP tree Initiate packet count If data rate > Threshold then: Create (S,G) entry: outgoing interface list={1} incoming interface=2 RP=0,WC=0,SPT=0 2. Send Join/Prune message to B: Multicast address=G Join={S} Prune=Null 3. Create (S,G) entry: outgoing interface list={1} incoming interface=2 RP=0,WC=0,SPT=0 6. After receiving packets from D: Set (S,G)’s SPT-bit=1 and, send Join/Prune message to C: Multicast address=G Join=Null Prune={S,RP-bit} D 7. Create (S,G) entry: oif list=oif(*,G)-{1} RP-bit=1 12 1 2 31 Receiver LANPIM DR/IGMP Querier for LAN Rendezvous Point (RP) for group G 4. Send Join/Prune message to D: Multicast address=G Join={S} Prune=Null 5. Add interface 2 to the outgoing interface list of (S,G) entry 2 12 Host Source (S) First Hop Router for S Switching to the Shortest Path Tree

12. Ahmed Helmy - UF12 The RP Bootstrap Problem Which router to use as RP for a group? –A set of well-connected routers are configured as Candidate-RPs for group(s) per domain –A manageable number of RPs is chosen –RPs advertise candidacy for group-prefix (not per group), for scalability –Periodic advertisement of candidacy to capture dynamics and unreachability Who maintains/updates/distributes this info?

13. Ahmed Helmy - UF13 RP Bootstrap Design Rationale Host model: –hosts need only “logical” multicast group address to send or receive RP address is network (not logical) address Routers should map group address to RP address and adapt to unreachability/change of RP

14. Ahmed Helmy - UF14 RP Bootstrap Design Rationale No “on-demand” retrieval of RP info to avoid start-up phase can’t join or send until DR gets RP address “bursty source” problem: packets are lost 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, periodic liveness tracking distribute RP-list throughout the domain

15. Ahmed Helmy - UF15 Choosing RPs: The Bootstrap Mechanism PIMv2 has a Bootstrap router election procedure –The Bootstrap router receives Candidate-RP messages from potential RPs –Bootstrap router sends Bootstrap messages which contain a list of reachable Candidate-RPs –All PIM routers receive these Bootstrap messages –DRs obtain group-to-RP mapping (when hosts join or send to the group) through a hash algorithm

16. Ahmed Helmy - UF16 RP Bootstrap Mechanism RP location need not be optimized, but consistent RP mapping and adaptation to failures is criticial –all routers (within PIM domain) 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 domain

17. Ahmed Helmy - UF17 RP Booststrap Mechanism Each candidate RP indicates liveness to the Bootstrap Router in the PIM domain Bootstrap Router distributes set of reachable candidate RPs to all PIM routers in domain. Each PIM router uses the same hash function and set of RPs to map a particular multicast group address to that group’s RP.

18. Ahmed Helmy - UF18 Dynamic Bootstrap Router Election Simple bridge-like spanning-tree election algorithm A set of well-connected routers are configured as Candidate Bootstrap Routers (C-BSRs) per domain C-BSRs originate PIM hop-by-hop Bootstrap messages with IP address and preference value. Bootstrap messages are exchanged by all PIM routers within domain (flooded with RPF check) Most preferred (or highest numbered) reachable C-BSR is elected

19. Ahmed Helmy - UF19 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

20. Ahmed Helmy - UF20 Adaptation to RP Unreachability When Candidate RP fails/unreachable –Bootstrap Router times it out –Bootstrap message distributed with updated RP set –Routers hash affected groups to different RP

21. Ahmed Helmy - UF21 References RFC 2362/2117 http://catarina.usc.edu/pim

22. Ahmed Helmy - UF22 Multicast and the Internet Initially there was the MBONE Short-term inter-domain solution based on PIM-SM, MBGP and MSDP Longer-term architecture BGMP

23. Ahmed Helmy - UF23 The Internet's Multicast Backbone (MBONE) The MBONE is an interconnect of subnets and routers that support IP-multicast. The goal of the MBONE was: –initially: to construct an IP multicast test-bed –as it became popular: gradual deployment of multicast applications without waiting for the ubiquitous Internet multicast deployment

24. Ahmed Helmy - UF24 The MBONE is rapidly growing –40 subnets in 4 countries in ‘92 –> 2800 subnets in over 25 countries in April ‘96 The MBONE is a virtual network layered on top of a subset of the Internet. It is composed of islands of multicast-capable routers connected to other islands by virtual point-to-point links called “tunnels.”

25. Ahmed Helmy - UF25 -Tunnels allow multicast traffic to pass through the non-multicast-capable parts of the Internet. -Multicast packets are encapsulated as IP-in- IP, so they look like normal unicast packets to intermediate routers. -Encapsulation is added on entry to a tunnel and stripped off on exit from a tunnel. Tunneling

26. Ahmed Helmy - UF26 Multicast islands connected through tunnels

27. Ahmed Helmy - UF27 The MBONE and the Internet have different topologies, so: –multicast routers execute a separate routing protocol to forward multicast packets. -Much of the MBONE routers run DVMRP -Portions of the MBONE run: -MOSPF -Protocol-Independent Multicast (PIM)

28. Ahmed Helmy - UF28

29. Ahmed Helmy - UF29 MBONE Limitations “Mbone currently using DVMRP, which was never intended for, and is ill-suited to, this task –known problems of DV with large networks –broadcast & prune approach ‘undesirable’ for interdomain routing”, S. Deering. Suggested solution: –Use sparse-mode concepts –Use 2-level hierarchy (as in unicast)

30. Ahmed Helmy - UF30 Recent Deployment Use PIM-SM as intra-domain multicast routing protocol Use MBGP (Multicast BGP) to distribute inter-domain multicast routes Use MSDP (Multicast Source Discovery Protocol) between RPs in different domains

31. Ahmed Helmy - UF31 MBGP BGP (RFC 1771) used for unicast routing to: –aggregate and abstract routes for scalability –provide inter-domain routing policies BGP4+ (RFC 2283) can carry multicast routes –multicast routers need only know - internal topology and - paths to reach other domains –provides topology info for multicast routes that may be different than unicast routes

32. Ahmed Helmy - UF32 Problem Connecting PIM-SM domains Domain A (PIM-SM)Domain B (PIM-SM) RP A RP B S R Sources register with RP in their domain and receivers join towards the RP in their domain No way for receiver in domain B to know about sources in domain A and vice versa

33. Ahmed Helmy - UF33 MSDP To tie PIM-SM trees in different domains –every RP has MSDP peers (RPs in other domains) –when a source registers to the RP it conveys this info to its MSDP peers through TCP and SA messages –this info is RPF-flooded to other domains –an RP with members in its domain joins towards src

34. RP1 Source S Last hop router sends (S,G) Register to RP1 RP1 Creates State RP2 Receiver R (S,G) Joins towards RP2 AS 2 AS 1 Normal SM 34Ahmed Helmy - UF

35. Peering RP1 Source S RP2 Receiver R MSDP Peering o Between RPs o Over TCP 35Ahmed Helmy - UF

36. Sending SA Msgs RP1 Source S Last hop router sends (S,G) Register to RP1 RP1 Creates State RP2 Receiver R RP1 Sends (S,G) SA message (S,G) Joins towards RP2 MSDP Peering 36Ahmed Helmy - UF

37. Joining the Source Tree RP1 Source S Last hop router sends (S,G) Register to RP1 RP1 Creates State RP2 Receiver R RP2 Joins (S,G) Source Tree (S,G) Joins towards RP2 (S,G) Joins 37Ahmed Helmy - UF

38. Forwarding Packets RP1 Source S RP2 Receiver R 38Ahmed Helmy - UF

39. 39 Limitations Short-term solution that doesn’t scale well!

40. Ahmed Helmy - UF40 New Developments in Inter- Domain Multicast Routing BGMP (Border Gateway Multicast Protocol): –PIM-SM-like inter-domain multicast routing protocol –builds bi-directional shared trees of domains –each tree has a ‘root domain’ (like an RP) MASC (Multicast Address Set Claim): –mechanism to associate addresses with root domains MBGP: –extends BGP to convey ‘address-range to root’ mapping to border routers

41. Ahmed Helmy - UF41 BGMP Bi-directional shared trees rooted at domains Border routers send joins and data toward root domain for mcast address in packet Mapping of multicast address to root domain obtained from BGP4+ MRIB Source specific branches only where “needed”

42. Ahmed Helmy - UF42 ISP 1 Sender/Rcvr Group Initiator BGMP tree AS1

43. Ahmed Helmy - UF43 BGMP Reference For more references: –Sigcomm ‘99 [Kumar et al.] –The PIM project: http://www.cise.ufl.edu/~helmy/projects.html#pim