1. 1 © 2000, Cisco Systems, Inc. Source-Specific Multicast (SSM ) for application developers

2. 2 © 2000, Cisco Systems, Inc. Agenda Review current IP Multicast –model, issues, current solution Introduce SSM – model, terminology, relationship to IGMPv3 Example of operations – Current vs. SSM Review SSM – Co-existence, advantages How to use SSM in applications Issues

3. 3 © 2000, Cisco Systems, Inc. Internet Standard Multicast (ISM) ISM service model (RFC1112): – Sources simply send traffic to a host-group G, They do not know who the receivers are. sendto(sock, packet, …, G,…) – Receivers join a host-group G setsockopt(sock,…, IP_ADD_MEMBERSHIP,(G, iface), …) – Receive traffic from all sources sending to G. Recvfrom(sock, &packet, … &source, …) –Receivers not need to know who the sources are. (but may learn once they receive the packets of course).

4. 4 © 2000, Cisco Systems, Inc. ISM, IGMPv3 and SSM ISM: Powerful, proven model – Self-configuring, resilient distributed applications – Resource discovery mechanisms – Very easy for applications What is New ? IGMPv3: model extension, source filtering, enables SSM. SSM solves ISM issues for Internet Broadcast apps. SSM extends IP Multicast, does not replace ISM.

5. 5 © 2000, Cisco Systems, Inc. Issues with ISM – Address allocation and management One application per group address – Denial of Service Attacks How to avoid unwanted sources traffic ? – Easy of scalability of service provisioning Shared-Tree - Interdomain complexity (BGMP,..), no gain for few-sources apps. Source-Tree - Source discovery management complexity

6. 6 © 2000, Cisco Systems, Inc. Exploiting existing solutions Internet standard Multicast solution: PIM-SM + MSDP – Source discovery with RPs and MSDP – Receiver initiated source-trees SSM: Move resource discovery into applications: – Without the issues from the previous slide – Utilising existing PIM-SM/MSDP deployments – Co-existing with the ISM and it’s applications.

7. 7 © 2000, Cisco Systems, Inc. Source Specific Multicast Service Model – Sources simply send traffic to a host-group G, No change over Internet Standard Multicast service. sendto(sock, packet, …, G,…) – Receivers subscribe to (S,G) channel(s) setsockopt(sock,…, IP_ADD_SOURCE_MEMBERSHIP, (S, G, iface), …) – Receive traffic from “channel” S sending to G. recvfrom(sock, &packet, … &source, …) –Receiver need to know the sources before receiving!

8. 8 © 2000, Cisco Systems, Inc. SSM and IGMPv3 IGMPv3 – INCLUDE{sourcelist, G} receive traffic for G only from sources in sourcelist. – EXCLUDE{sourcelist, G} receive traffic for G except from sources in sourcelist SSM: Only INCLUDE type memberships supported. IGMPv1, IGMPv2 and IGMPv3 EXCLUDE memberships are ignored in SSM by routers. »Traffic from unknown sources not forwarded

9. 9 © 2000, Cisco Systems, Inc. SSM versus ISM SSM does not support unmodified Applications! No way to request reception of traffic from unknown sources Existing receiver applications will not work with SSM ! New terminology: A group G alone has no meaning of it’s own in SSM. It is like the trailing digits in a telephone number ! Service Model: RFC1112 Source-Specific Network Abstraction: group channel Identifier: G S,G Receiver Operations: join, leave subscribe, unsubscribe

10. 10 © 2000, Cisco Systems, Inc. ISM traffic delivery example RP

11. 11 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP

12. 12 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP First-hop routers send register messages to the RP register

13. 13 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP RP has no receivers joined, so it sends back register-stop messages, but remembers that the sources are active register stop (S1,G) (S2,G)

14. 14 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP R1 Join to G R2 Join to G R3 Join to G Receivers start to join to the group (S1,G) (S2,G)

15. 15 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP R1 Join to G R2 Join to G R3 Join to G And the last-hop DRs will then send (*,G) PIM-JOIN packets towards the RP (*,G) Join (*,G) (S1,G) (S2,G)

16. 16 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP (S1,G) (S2,G) R1 Join to G R2 Join to G R3 Join to G This will establish traffic delivery from the RP towards the receivers on the RPT, except that there is no traffic yet (*,G)

17. 17 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP R1 Join to G R2 Join to G R3 Join to G But the RP knows about two sources for G and thus sends (Si,G) PIM-JOINS to them to receive their traffic. (S1,G) Join (S2,G) Join (*,G) (S1,G) (S2,G)

18. 18 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP (*,G) R1 Join to G R2 Join to G R3 Join to G The RP will receive the traffic from sources S1 and S2 on the shortest path (*,G) (S1,G) (S2,G)

19. 19 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP (*,G) R1 Join to G R2 Join to G R3 Join to G And sends it down on the RPT towards the receivers (*,G) (S1,G) (S2,G)

20. 20 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP R1 Join to G R2 Join to G R3 Join to G (S1,G) Join Once the last-hop routers receive traffic from new sources, they will join to the SPT for these sources (shown only for S1 from one router) (S1,G) Join (S1,G), (S2,G)

21. 21 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP R1 Join to G R2 Join to G R3 Join to G Because the input interface is different in this case, the router sends up (S1,G,Rpbit) Prune, once traffic arrives on the SPT (S1,G,RPbit) Prune (S1,G), (S2,G)

22. 22 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G RP R1 Join to G R2 Join to G R3 Join to G And finally, traffic forwarding is on the SPTs (S1,G), (S2,G)

23. 23 © 2000, Cisco Systems, Inc. ISM traffic delivery example S1 Send to G S2 Send to G R1 Join to G R2 Join to G R3 Join to G If S1/R1 and S2/R3 were independent applications, their traffic would disturb each other RP

24. 24 © 2000, Cisco Systems, Inc. SSM traffic delivery example Now we reuse G for two independent applications with SSM

25. 25 © 2000, Cisco Systems, Inc. SSM traffic delivery example S1 Send to G S2 Send to G Sources send to SSM group G, no registering happens there

26. 26 © 2000, Cisco Systems, Inc. SSM traffic delivery example S1 Send to G S2 Send to G Incompatible receiver joins, last-hop router has to ignore the request as there is no RP in SSM! R2 Join to G

27. 27 © 2000, Cisco Systems, Inc. SSM traffic delivery example S1 Send to G S2 Send to G SSM-enabled receivers subscribe to channels on the same group but for different sources R2 Join to G R1 Subscribe (S1,G) channel R3 Subscribe (S2,G) channel

28. 28 © 2000, Cisco Systems, Inc. SSM traffic delivery example S1 Send to G S2 Send to G R1 Subscribe (S1,G) channel R2 Join to G R3 Subscribe (S2,G) channel Now we reuse G for two independent applications with SSM (S1,G) Join (S2,G) Join

29. 29 © 2000, Cisco Systems, Inc. SSM traffic delivery example S1 Send to G S2 Send to G R1 Subscribe (S1,G) R2 Join to G R3 Subscribe (S2,G) And traffic flows down the shortest-paths, but legacy receivers will not get their traffic.

30. 30 © 2000, Cisco Systems, Inc. SSM and ISM co-existence SSM used only in “SSM-Range”: – 232.0.0.0 … 232.255.255.255 (Globally assigned by IANA) Existing application may not use SSM-Range. Global use of SSM-Range needed to guarantee conflict free address-reuse

31. 31 © 2000, Cisco Systems, Inc. Advantages of SSM No address management in SSM-Range – All (Si,G) channels indendent of each other. – ~2^24 channels / source. – Group address has only host-local significance. No traffic from unwanted sources Network benefits: Easily deployed – Support only needed in last-hop router. – Rest of the network may use PIM-SM (+access config). Simpler management than ISM

32. 32 © 2000, Cisco Systems, Inc. Applications for SSM Attractive for Internet-wide broadcast-style applications: – Well known sources, very static – Primary targets for DoS attacks – Current problems with address availability Impossible for SSM: – Resource discovery style applications Not useful with SSM: – Everything that should use “shared-tree” forwarding (Many Sources, frequently changing sources) Others: – How difficult is source-discovery for an application ? – How useful is it to do it for the benefits of SSM ?

33. 33 © 2000, Cisco Systems, Inc. Traffic delivery example ISM + IGMPv3 (1) S1 Send to G S2 Send to G R1 INCLUDE ({S1},G) R2 EXCLUDE ({}, G} R3 INCLUDE ({S2},G) Wishful thinking ? No, this is possible, but more complex in the network than SSM, also... RP

34. 34 © 2000, Cisco Systems, Inc. Traffic delivery example ISM + IGMPv3 (2) S1 Send to G S2 Send to G …closer to reality. No guarantee that independent applications traffic will always stay separate if not using SSM R1 INCLUDE ({S1},G) R2 EXCLUDE ({}, G} R3 INCLUDE ({S2},G) RP

35. 35 © 2000, Cisco Systems, Inc. How to support ISM + SSM (1) Typical broadcast receiver application get address information from SDP style session information system. – Add support for source addresses. – Use IGMPv3 API. – If session info contains source address(es): Use IGMPv3 INCLUDE membership API call(s). Will work with ISM and SSM. – If session is does not contain source addresses: Use simple group-join (I.e.: IGMPv3 EXCLUDE({},G) ). Must use addresses not within the SSM-range.

36. 36 © 2000, Cisco Systems, Inc. How to support SSM + ISM (2) Self sustained applications (no session information): – Need to implement “source discovery” to support SSM: – Web-based applications could rely on a Webserver based servlet as an application-RP. Applications that use INCLUDE style memberships will always work outside of the SSM-Range. – May receive complete group traffic though ! – Need address management outside SSM-range !

37. 37 © 2000, Cisco Systems, Inc. Deployment issues To use SSM, IGMPv3 must be supported in: – The last-hop router – The receiver host OS – The application Availability ? Bootstrap solutions (from Cisco): – IGMP v3lite: User-level IGMPv3 API (SSM-subset) (Windows *, …). – URD: Make existing applications SSM-capable through appropriate web-based control. No changes on the receiver host required. Not meant as a replacement to IGMPv3, but as SSM enablers. Useful until user deploys full IGMPv3 (/Applications).

38. 38 © 2000, Cisco Systems, Inc. References draft-holbrook-ssm-00.txt- SSM model draft-bhaskar-pim-ss-00.txt- PIM-SM mods. for PIM-SS draft-ietf-idmr-igmp-v3-04.txt- IGMPv3 draft-ietf-idmr-msf-api-00.txt- IGMPv3 API draft-ietf-pim-v2-sm-01.txt- PIM-SM draft-shepherd-ssm232-00.txt- Using PIM-SM with SSM-Range ftp://ftpeng.cisco.com/ipmulticast.html for further information on SSM

39. 39 © 2000, Cisco Systems, Inc. Thank You