IP Multicast for Entertainment Video

1. IP Multicast for Entertainment Video Cisco Days – Raleigh, NC

2. Agenda • Video System Elements • Edge Reliant System Design (Example Topology) • Multicast Overview • Multicast Design Metrics • Managing IP Multicast (CMM & VOS)

3. VideoSystem Elements • System Elements and Resiliency

4. Encoding MPTS Muxing SPTS Muxing Encryption Encryption Transport Network DPI Ad Splicing Transport Network QAM Modulation STB Decoding Digital Content Video System Elements

5. Design Dependencies The design efficiency of the entertainment network is largely dependent on the IP Multicast capabilities of the components in the system. We should consider those capabilities categorically: • Video Sources (single or redundant) • Digital Simulcast (MPTS) • Switched Digital (SPTS) • DPI (Both MPEG-2 Transport Types) • Edge Receivers (network intelligent or not) • QAM Modulators • Decoders • Nodes and Links (functionality required is based on source/edge) • Transport Equipment • Routers and Interfaces • Forwarding Protocols

6. Resiliency Options

7. Single Video Source Leveraging a single video source into a High-Availability design requires some method of replication that may not establish uniqueness of the video streams. • Non-Optimal • Optical splitting will create duplicate traffic that uses the same multicast addresses • Forced multicast forwarding into transport paths increases video flow replication and transport demand • Optimal • Sophisticated source devices that replicate video traffic as uniquely addressable source streams • Intelligent Edge devices dynamically select video traffic to minimize bandwidth and replication

8. Secondary/Backup Video Source • Layer-2 forwarding using VLAN’s with Any Source Multicast (ASM), or classic multicast • Layer-3 forwarding of adjacent system content using ASM multicast IP addressing • Layer-3 forwarding of adjacent system content using Anycast multicast IP addressing

9. Video Edge Considerations • IGMP support (or the lack of it) is the largest factor driving network design • Non-IGMP compliant devices create design constraints that impact bandwidth demand and network device efficiencies

10. Video Edge Dependency UltimatelyDrives Topology Decisions An Evolving Distribution Network : • L2  IGMPv2/SSM Mapping  End-2-End IGMPv3/SSM • Variations in consistency between Edge Gear products’ support of IGMP vs Promiscuity constrain your design options • Promiscuous devices have the ability to receive single source duplication that uses identical IPmc addressing (like Anycast) • But - limits scalability in a VLAN (to 1 GE) • IGMP Snooping is required to protect video edge devices from oversubscription • Requires VLAN isolation for promiscuous devices which factors up the multicast replication at the edge router and the increases transport bandwidth • IGMP capable devices allow the total network to scale better

11. Edge ReliantSystems • Migrating to Efficient IP Multicast Systems Design

12. Distribution Options • Layer-2 and Layer-3 networks have distinct scalability differences

13. Layer-2 Multicast Fundamentals • Layer-2 Networks propagating Multicast in a broadcast fashion • Resiliency is achieved through explicit packet duplication • Video Edge equipment vendors have different multicast capabilities today, which may impose a “transport tax” in the form of multiple VLAN’s for different applications • 802.1q P2P links to create segregated traffic • One VLAN for each 1G of redundant traffic – approx. 240 channel ceiling

14. Single Source ExampleSingle Router, Single Ring/Link Transport Source devices feed a unique multicast to a single router, using “isolated” Layer-2 trunks for redundant distribution to remote locations 802.1q Trunk SVI 10 Static-group Output result is identical multicast groups - edge must support duplicate addressing scheme. (Works for promiscuous receivers.) Statistical Multiplexers Static-group 802.1q Trunk SVI 20 VLAN path terminates at the “last hop” in the ring so that no loop exists.

15. Single Source ExampleDual Routers, Single Ring Transport Source devices feed a unique multicast shared between two routers, with redundant distribution to remote locations using “isolated” Layer-2 trunks SVI 10 802.1q Trunk Static-group Output result is identical multicast groups - edge must support duplicate addressing scheme. (Works for promiscuous receivers.) This link supports bridging of all source multicasts Statistical Multiplexers Static-group SVI 20 802.1q Trunk VLAN path terminates at the “last hop” in the ring so that no loop exists.

16. Layer-3 IP Multicast Fundamentals • Layer-3 networks propagate IP Multicast using dynamic traffic selection • Intra-Regional Backup and/or Redundancy of video sources leverage the bandwidth efficiency of IP Multicast • Edge network segments have greater flexibility, when supporting multi-vendor implementations using Layer-3 addressing and forwarding

17. Single Source ExampleDual Router, Single Ring Transport Source devices feed a unique multicast propagated between two routers using two separate OSPF routing instances. Remote routers see both instances for resiliency. OSPF 10 Static Groups Output result is identical multicast groups - edge must support duplicate addressing scheme. (Works for promiscuous receivers.) This link supports routing of all source multicasts Statistical Multiplexers OSPF 20 Static Groups

18. Dual Logical IPmc Topologies on Single Network for High Availability Resiliency • Can provide different subsets of the network for different classes of traffic • Can share links to reduce cost • Can share nodes to reduce cost • Vs. Virtual Routers or similar “virtual network”: • No need for subnet encapsulation for multiple topologies • Vs. RSVP-TE P2MP • Easier DIffserv type approach (not fixed on per flow/tree)

19. STBs HFC Dual Multicast Topologies for HA Resiliency • Send traffic twice to different multicast groups(eg: green = 232.1.8.1, red = 232.1.8.2) • Use logical path separation in network to pass red/green across different pathsNote: dual topologies just one solution • Receivers receive both copies. • No single network failure will cause any service interruption • Same bandwidth allocation needed as in traditional SONET rings, but solution even better: 0 loss instead of 50 msec. Redundant Encoder/Multiplexer Redundant Decoder / Ad-Inserter/..

20. Unicast traffic flow Large Multicast traffic flow Unicast traffic flow Multicast traffic flow Small metric Dual Multicast Topologies for High Availability Resiliency Rcvr Rcvr • Topology sharing of links: • Particular useful in rings. • Two topologies also useful forunicast (eg: VoD load splitting) • Requires unidirectionally “weighted” link metric to force opposing reachability IGP costs different in each Topology Unicast traffic flows inthe opposite directions Rcvr Rcvr Redundant Encoder/Multiplexer Rcvr Small metric Rcvr Largemetric

21. Dual Source Example Dual Router, Single Physical Transport Multiple unique sources feed two routers which support two separate OSPF forwarding instances. Remote routers see both instances for resiliency. OSPF 10 Static or IGMPvX Output result is unique multicast groups and unique source IP addresses. (Works for promiscuous receivers.) Primary Source This link supports routing of all source multicasts OSPF 20 Static or IGMPvX Backup Source IGMPv3 and SSM function nicely in this design if supported by the Edge Device.

22. Phased Resilient NetworkImplementation Example • Build the Foundation and Grow As Needed

23. Simulcast Source RGB CATV Mux Edge Reliant Design – Phase 1Leverage Logical Network Subsets QAM Library VoD Propagation Streaming VoD Server QAM QAM

24. Simulcast Source RGB Mux Edge Reliant Design – Phase 2Introduce Node Resiliency QAM Library VoD Propagation Streaming VoD Server QAM QAM CATV

25. Edge Reliant Design – Phase 3Introduce physical layer resiliancy Library VoD Propagation Streaming VoD Server CATV QAM Simulcast Source OSPF weighted low QAM Primary Simulcast Secondary Simulcast Primary VoD Prop Secondary VoD Prop RGB CATV Mux

26. Edge Reliant – Phase 4Introduce Non-stop Forwarding Network Nodes 7600 Simulcast Source B Streaming VoD Server Library VoD Prop CATV QAM CRS-1 Simulcast Source A OSPF weighted low QAM Primary Simulcast Secondary Simulcast Primary VoD Prop Secondary VoD Prop RGB CATV Mux

27. 7609 Design Strengths • Converged Services on redundant 7600’s • Service Separation through dedicated interfaces, simplified operational requirements • Efficient distribution of multicast traffic via IP routing • Deterministic traffic path based on known routing cost • Multiple redundancy options available per service • Predictable and manageable scaling per service • Wide range of L2 & L3 VPN commercial services available • Utilizes a best practice design and features widely deployed in the field today (experience to draw upon.

28. Dual-Homed Edge Devices

29. Time Warner San Antonio – “DVT” (10GEx4) HUB 6300 HUB 6200 HUB 6700 HUB 6600 HUB 5200 HUB 6400 HUB 6100 HUB 6800 HUB 6500 HUB 5100 HUB 5300 HUB 1400 HE/HUB 6000 HE/HUB 5000 HUB 1300 HUB 3000 (THUB) HUB 1000 (THUB) HUB 2000 (THUB) HUB 3100 HUB 2200 HUB 2100 HUB 2500 HUB 1100 HUB 1200 HUB 2300 HUB 3400 HSD DVT METROE C&C HUB 2400 HUB 2300 HUB 2200

30. Catalyst 4948 Catalyst 4948 GQAM 7600 7600 7600 7600 7600 7600 7600 7600 7600 7600 HUB 2200 HUB 2100 Catalyst 4948-GE BMR1200 Multicast Sources San Antonio – Hardware Installed Real Time Encoders BroadBus DFC Based 6704 links at all THUB Locations BroadBus BMR1200 Ad, Splice and Clamping HE/HUB 6000 HE/HUB 5000 CFC Based Line Cards for 10GE and 1GE output to Sub-Rings HUB 3000 (THUB) HUB 1000 (THUB) HUB 2000 (THUB) RGB1 RGB2 BME50 RF Plant Analog/ Digital RF SuperTrunk to DHUBs BME50 HUB 2300 Simulcast / SDV GE Path VOD 10GE Path 10GEx4 Transport Links

31. MulticastOverview • Highlighting the Fundamentals

32. IP Multicast Business Drivers The Problem: Inefficient Multipoint Techniques Broadcast Multiple Unicasts Raleigh Raleigh ??? ??? Columbia Columbia ??? ??? ??? ??? Three copies of the same packet are transmitted The entire network receives one packet even if there are only a few receivers

33. IP MulticastBusiness Drivers The Solution: Multicast Multicast Group • Multicast Transmission: Source sends a single multicast packet addressed to a multicast group number. • Intelligent networking devices then dynamically build efficient paths and deliver packets to all recipients who have joined that multicast group. • Introduces a new class of IP addresses: Class D = 224.0.0.0 239.255.255.255

34. IP MulticastBusiness Drivers Distribution Times Point-to-point vs. Multicast Point-to-Point Transfers at 512 kbps Files Size 100 Servers 1000 Servers 5000 Servers 1 MB 25 Minutes 4.3 Hours 22 Hours 100 MB 43 Hours 434 Hours 2170 Hours 300 MB 130 Hours 1302 Hours 6510 Hours Multicast Transfers at 512 kbps Files Size 100 Servers 1000 Servers 5000 Servers 1 MB 16 Seconds 16 Seconds 16 Seconds 100 MB 26 Minutes 26 Minutes 26 Minutes 300 MB 78 Minutes 78 Minutes 78 Minutes

35. MulticastDesignMetrics • Protocols That Are Critical For Success

36. Key IP Multicast Protocols • Protocol Independent Multicast (PIM) • Defines the method of propagation of multicast traffic • Internet Group Management Protocol (IGMP) • Defines how receivers and sources establish and discontinue membership relationships • Internet Gateway Protocol (IGP) • Used by PIM to ensure that optimal paths are used to deliver services, and prevent routing loops

37. Step 1 – Enabling IPmc in the Network Node • IP Multicast traffic support is not usually enabled by default on most Layer-3 network devices. • There are commands for global support on the router, and at the interface level (or SVI) that: • Enable multicast traffic on the platform… • Configure the appropriate multicast routing protocols and multicast client support settings based on the receiving devices downstream from the node. NOTE: Most applications require a configuration tuning to bring performance and security in alignment with network policies.

38. Step 2 – Multicast Routing ProtocolsProtocol Independent Multicast (PIM) • PIM is the industry standard family of routing protocols used to establish a logical “domain” of IPmc peers • Network Nodes become PIM peers when connected interfaces are configured with a similar PIM protocol mode • PIM peers share information about IPmc traffic sources, and direct traffic to active receivers (IPmc requestors) according to the PIM mode • PIM operational modes are dense, sparse or sparse-dense • Dense mode floods (pushes) all IPmc traffic into domain interfaces until pruning stops the flooding. • Sparse mode forwards (pulls) an IPmc group into domain interfaces only if requested. • Sparse-mode requires devices called a “Rendezvous Point” to coordinate source device awareness in the PIM domain • The Layer-3 routing protocol(IGP) of the network is used to establish the path which the IPmc traffic will take between the IPmc source and requestor • There is a potential for a non-synchronized condition where PIM tries to build a IPmc tree through an ideal IGP path that may not be PIM enabled (uRPF). Be sure to enable your shortest path for PIM • NOTE: The mode you select is dependent on the default behavior you require for your application and its resiliency requirements

39. Step 2 (cont.) – Sparse vs. Dense Perspective While browsing the CISCO-IPMROUTE-MIB.my file I happened across a succinct description, that offered another view when comparing sparse mode to dense mode: • “In sparse-mode, packets are forwarded only out interfaces that have been joined. In dense-mode, they are forwarded out all interfaces that have not been pruned."

40. Step 3 – Internet Group Management Protocol IGMP “Joining” is the common term used to describe a host system that requests to become a member of an IPmc group – it is said that the host will “join a group” The membership request is dynamic when the host uses the IGMP protocol to make the request IGMPv1 and IGMPv2 are said to be non-source-specific requests as they only able to request membership by the IPmc group identity - commonly called a (*,G) request, or join • dense or sparse mode are commonly used IGMPv3 specifies the exact source IP address and IPmc group address – commonly called an (S,G) request, or join • Source Specific Multicast (SSM) implementations require IGMPv3 support on the requestor or by proxy at the first hop router via SSM-Mapping • SSM uses sparse-dense mode only, and does not require rendezvous point configuration in the PIM domain

41. Protocol Independent MulticastHow Multicast Moves Over IP Networks • Multicast Routing, IGMP Evolution, and the Impact on Your Network

42. What is PIM? Protocol Independent Multicast (PIM): • A Multicast routing protocol that define the rules used to forward multicast traffic throughout the IP network. • Network nodes (interfaces or links) are explicitly configured as participants in PIM • There are multiple PIM operating modes, each with specific operational benefits • PIM is dependent upon the underlying unicast routing protocols for specific reachability. • A multicast enabled network is commonly referred to as a “PIM domain”.

43. Classic MulticastAny-Source Multicast (ASM) ASM: Classic IP Multicast service (rfc1112, ~1990) • Sources send IP multicast packets to a IP multicast group • Receivers “join an IP multicast group” • Network node will deliver packets sent by any source to an IP multicast group to all receivers that have joined the IP multicast group.

44. ASM Multicast Routing Modes Dense Mode (DM): A traffic “push” mode that actively attempts to send multicast data to all potential receivers in the PIM domain (flooding), and relies upon their self-pruning (removal from group) to achieve desired distribution. Sparse Mode (SM) RFC 2362: A traffic “pull” mode that relies upon an explicit joining method (IGMP) before attempting to send multicast data to requestors of a multicast group. Source Specific Multicast: A mode used where receivers have the ability to directly request multicast groups from a specific source.

45. SM Multicast Components Rendezvous Point (RP): The multicast router that is the root of the PIM-SM shared multicast distribution tree. This router knows about all the multicast sources in the PIM domain. Designated Router (DR): The router in a PIM-SM tree that forwards Join/Prune messages upstream to the RP in response to IGMP membership info it receives from IGMP hosts. Shared Tree: Efficiently built (temporary) distribution path from the central RP to all DRs who have directly attached members of a particular multicast group. Ensures that there are no unnecessary duplication of the multicast data within network, but may result in sub-optimal routing between source and receivers. Source Tree: A multicast distribution path that directly connects the sources and receivers DRs (or the RP) to obtain the shortest path through the network. Results in most efficient routing of data between source and receivers, but may result in unnecessary data duplication throughout network if built by anyone other then the RP.

46. Segment A Segment B RP Multicast Source Y Multicast Source X DR RP ISP B ISP A DR PIM-SM DR Multicast Domain Multicast Routing: PIM-SM Protocol Independent Multicast • Dense mode • -Uses “push” model • -Traffic flooded throughout network • -Pruned back where it is unwanted • -Flood-and-prune behavior (every 3 minutes) • Sparse mode • -Uses “pull” model • -Traffic sent only to where it is requested • -Explicit join behavior

47. SSM and Anycast • SSM: Source Specific Multicast (~2000) • Source(s) still send IP multicast to IP multicast group address – but refered to as an “(S,G) channel” • Receivers subscribe to (S,G) channel by indicating to the network not only IP multicast group it wants but also the specific source • Network will deliver packets on a per-channel basis only • Anycast “Redundant IP address” for source-redundancy: • Primary target for SSM: “Single-Source” TV/Audio/Data ”broadcast” applications • Using a single IP address on multiple sources for redundancy, the network dynamically announces closest source via Unicast Routing. But why SSM, is ASM not good enough or better ? • ASM is simpler to deploy – no RP’s or DR’s needed resulting in simpler configurations

48. Reasons To Use SSM • Complexity of protocol operations required for SM • PIM-SM (Shared trees, shortest path trees, RPT/SPT switchover)/MSDP, RP announcement (AutoRP/BSR), RP placement, RP redundancy • Operating PIM-SM over core networks complicated • Bandwidth reservation (RSVP, per group ? Per source ?), Link/Node Protection with PIM-SM are all more complex • Scalability, Speed of protocol operations (convergence) • Operations for both SPT and RPT needed – and their interaction • DoS attacks by unwanted sources • Receivers can ignore packets, but network resources can only be protected by extensive network source access control == network level application control. • Address Allocation • Try to get “global scope” IPv4 multicast address (GLOB, …)

49. IP Multicast Routing Summary • SSM is a key enhancement to IP multicast • Better (manageable / scalable) multicast service delivery • SSM may not replace ASM in all applications • Many-source applications • Source-discovery with IP multicast • ASM and SSM can coexist • Recent means of improvement / simplification of ASM • Easier protocols for ASM • Bidir-PIM (intradomain only today) • Easier RP-redundancy (PIM-Anycast-RP, Prioritycast) • IPv6 multicast (address allocation, embedded-RP)

50. IGMPManaging Multicast Propagation • IGMP Evolution, and the Impact on Your Network