Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 IP Multicast for Entertainment Video Cisco Days – Raleigh, NC.

Similar presentations


Presentation on theme: "© 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 IP Multicast for Entertainment Video Cisco Days – Raleigh, NC."— Presentation transcript:

1 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 IP Multicast for Entertainment Video Cisco Days – Raleigh, NC

2 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 2 Agenda  Video System Elements  Edge Reliant System Design (Example Topology)  Multicast Overview  Multicast Design Metrics  Managing IP Multicast (CMM & VOS)

3 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 3 Video System Elements  System Elements and Resiliency

4 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 4 Video System Elements MPTS Muxing SPTS Muxing DPI Ad Splicing Transport Network EncryptionQAM Modulation EncodingDigital Content EncryptionTransport Network STB Decoding

5 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 6 Resiliency Options

7 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 10 Video Edge Dependency Ultimately Drives 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 11 Edge Reliant Systems  Migrating to Efficient IP Multicast Systems Design

12 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 12 Distribution Options  Layer-2 and Layer-3 networks have distinct scalability differences

13 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 14 Single Source Example Single Router, Single Ring/Link Transport SVI 10 SVI 20 Statistical Multiplexers Static-group Output result is identical multicast groups - edge must support duplicate addressing scheme. (Works for promiscuous receivers.) 802.1q Trunk VLAN path terminates at the “last hop” in the ring so that no loop exists. Source devices feed a unique multicast to a single router, using “isolated” Layer-2 trunks for redundant distribution to remote locations

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

16 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 17 Single Source Example Dual Router, Single Ring Transport OSPF 10 OSPF 20 Statistical Multiplexers Static Groups Output result is identical multicast groups - edge must support duplicate addressing scheme. (Works for promiscuous receivers.) Source devices feed a unique multicast propagated between two routers using two separate OSPF routing instances. Remote routers see both instances for resiliency. Static Groups This link supports routing of all source multicasts

18 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 19 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 paths Note: 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/.. HFC STBs

20 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 20 Dual Multicast Topologies for High Availability Resiliency  Topology sharing of links:  Particular useful in rings.  Two topologies also useful for unicast (eg: VoD load splitting)  Requires unidirectionally “weighted” link metric to force opposing reachability Redundant Encoder/Multiplexer Rcvr IGP costs different in each Topology Unicast traffic flows in the opposite directions Small metric Large metric Multicast traffic flow Unicast traffic flow Large Small metric Multicast traffic flow Unicast traffic flow

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

22 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 22 Phased Resilient Network Implementation Example  Build the Foundation and Grow As Needed

23 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 23 Edge Reliant Design – Phase 1 Leverage Logical Network Subsets Library VoD Propagation Mux CATV RGB Simulcast Source Streaming VoD Server QAM

24 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 24 Library VoD Propagation Streaming VoD Server QAM Edge Reliant Design – Phase 2 Introduce Node Resiliency CATV RGB Mux Simulcast Source

25 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 25 Library VoD Propagation Streaming VoD Server QAM Edge Reliant Design – Phase 3 Introduce physical layer resiliancy CATV RGB Mux Simulcast Source Primary Simulcast Secondary Simulcast Primary VoD Prop Secondary VoD Prop CATV OSPF weighted low

26 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 26 Edge Reliant – Phase 4 Introduce Non-stop Forwarding Network Nodes Library VoD Prop Streaming VoD Server QAM Mux Simulcast Source A CATV RGB Primary Simulcast Secondary Simulcast Primary VoD Prop Secondary VoD Prop OSPF weighted low Simulcast Source B CRS-1 7600

27 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 28 Dual-Homed Edge Devices

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

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

31 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 31 Multicast Overview  Highlighting the Fundamentals

32 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 32 Raleigh ??? Columbia ??? Broadcast Multiple Unicasts Raleigh ??? Columbia ??? Three copies of the same packet are transmitted The entire network receives one packet even if there are only a few receivers Business Drivers IP Multicast Business Drivers The Problem: Inefficient Multipoint Techniques

33 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 33 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 Multicast Group Multicast Group Business Drivers IP Multicast Business Drivers The Solution: Multicast

34 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 34 Business Drivers IP Multicast Business Drivers Multicast Transfers at 512 kbps Files Size 100 Servers 1000 Servers 5000 Servers 1 MB 16 Seconds 100 MB 26 Minutes 300 MB 78 Minutes 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 Distribution Times Point-to-point vs. Multicast

35 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 35 Multicast Design Metrics  Protocols That Are Critical For Success

36 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 38 Step 2 – Multicast Routing Protocols Protocol 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 41 Protocol Independent Multicast How Multicast Moves Over IP Networks  Multicast Routing, IGMP Evolution, and the Impact on Your Network

42 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 43 Classic Multicast Any-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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 46 Multicast Routing: PIM-SM Multicast Domain Multicast Routing: PIM-SM Segment B Multicast Source Y Segment A Multicast Source X ISP B DR RP DR PIM-SM ISP A 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 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 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 50 IGMP Managing Multicast Propagation  IGMP Evolution, and the Impact on Your Network

51 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 51 IGMP Versions Version 1, specified in [RFC-1112], was the first widely-deployed version and the first version to become an Internet Standard. Version 2, specified in [RFC-2236], added support for "low leave latency", that is, a reduction in the time it takes for a multicast router to learn that there are no longer any members of a particular group present on an attached network. Version 3 adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address.

52 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 52 IGMP v1 - Behavior LAN 2 Group member router LAN 3 Group member router Group member LAN 1 router IGMP query IGMP query IGMP report IGMP report IGMP routing update 30 sec IGMP routing update

53 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 53 IGMP v1 - Pruning router Group Member Group Member Group Member IGMP query

54 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 54 IGMP v2 - enhancements IGMP v2 introduces a procedure for the election of the router querier for each LAN. In the version 1 this was done by different routing policies. Group-Specific Query – Added to permit queries form a router to a specific group and not to all-host address in the subnet (224.0.0.1). Leave-Group – for a reduction in the time it takes for a multicast router to learn that there are no longer any members of a particular group present on an attached network. Sent to all-routers (224.0.0.2) When a router receives the Leave-Group message, it uses the Group- Specific Query to verify if the sender was the last one in the group.

55 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 55 IGMP v2 - Pruning router Group Member Group Member Group Member IGMP Leave Specific Group query

56 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 56 IGMP v3 - features  MUST be interoperable with v1 and v2  Source-filtering Only from a source All but a source

57 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 57 IGMP v3 - The protocol (for group members) Action on Reception of a Query Therefore, the system must be able to maintain the following state: A timer per interface for scheduling responses to General Queries. A per-group and interface timer for scheduling responses to Group- Specific and Group-and-Source- Specific Queries. A per-group and interface list of sources to be reported in the response to a Group-and-Source- Specific Query. router IGMP query IGMP report Wait for random interval

58 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 58 IGMP v3 - The protocol (for multicast routers) Conditions for IGMP Queries Periodic request for membership Multicast routers send General Queries periodically to request group membership information from an attached network. These queries are used to build and refresh the group membership state of systems on attached networks. Systems respond to these queries by reporting their group membership state (and their desired set of sources) with Current-State Group Records in IGMPv3 Membership Reports. router IGMP Request

59 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 59 IP Multicast Video Channel Relationships  Channel Identities Change During Delivery

60 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 60 IPmc Flow Relationships  Video Transport Systems generally contain components that manipulate source video streams for a number of reasons… Statistical Multiplexing (building MPEG-2 MPTS’s) Digital Program Insertion (ad-insertion) Encryption or DRM  IPmc group addressing will change as video programs flow from their original sources through these components to consumers.  Awareness of those flow relationships are critical for successful service management.

61 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 61 IPmc Flow Relationship Hierarchy Example Off-net backup Source xPTS Encoder Source SPTS or PES Digital Source MPTS DPI device Statistical Mux or Sat Demux Edge Receiver QAM / RF Mod 1 st Stage IPmc 2 nd Stage Pre-Ad or No Ad IPmc 3 rd Stage Post-Ad IPmc DS MPTS / SDV SPTS DS or SDV MPTS DS SPTS/PES SDV SPTS DS & SDV SPTS or DS MPTS SDV sources from Encoder, Offnet or Satellite Demux DS Sources from Satellite, Mux or Offnet Ad Insertion can occur in either service Edge QAM ingests for Digital STB RF Mod ingests for Decode to Analog SDV SPTS External Encryption DS & SDV SPTS or DS MPTS DS MPTS / SDV SPTS 4th Stage Post Encrypt IPmc SDV SPTS

62 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 62 Geographic Relationships QAM, Decoder Encryption Ad Insertion Mux-Demux Encoders SourcesTransportEdge

63 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 63 Possible IPmc Flow Stages Mux / Demux Ad Insertion Encryption Ad Insertion Encryption Edge QAM Encoders Satellite Receivers Multi- function devices Zone 3Zone 2Zone 1

64 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 64 Control Multicasts (Out-Of-Band)  Emergency Alert Service (EAS)  BootLoaders (best way?)  Conditional Management  Hub-Specific Programming  NAT’d Multicasts

65 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 65 Video Program Path Changes Over Time SD Source Set Top HD Source PC Mobile DPI P-Key DRM Program Migration

66 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 66 Managing IP Multicast  Cisco Multicast Manager  Video Operations Solution

67 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 67 The issue How do you proactively or reactively monitor or diagnose a specific video service or video stream(s) given the following:  4 Different Video Service Types (TWC single market example) Broadcast Simulcast VoD Switched  Mapped into two different MPEG Multiplex Streams MPTS SPTS  Which map into two different IP address service paths Unicast Multicast  Which map across one of three different major GE network architectures Resilient Rings GE Optical Muxponded Backhaul Transport network aggregates to 10G (aka muxponded), across GE IP Switched Backhaul IP Switch aggregates to 10G, backhauled across a 10G transport network)  Across massive geography (TWC nationwide example) 2 NOCs 7 RDCs 41 Head Ends 20 hubs average per Head End 850 Hubs  And are applied in massive scale (TWC example) Broadcast (80 channels = <500Mb multicast *per hub* average) Simulcast (80 channels = <500Mb multicast *per hub* average) VoD (1-12 streams per channel = 5Gb unicast *per hub* average) Switched (80 analog + 120 digital channels = 1.5G multicast *per hub* average)

68 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 68 Case In Point HSD10GE Shared Commercial10GE Shared VoD10GE Rings Existing7609Router 7609Edge Router CRS-1Core Router Simulcast Ring-A -B

69 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 69 Headend Network Home Problems Caused by: IP packet jitter – rate overruns and underruns Dropped IP packets Good Video Poor Video blocky effect, locking effect, freeze frame, frame skipping… IP Packet Jitter IP Packet Delay Dropped IP Packets Network Impact on Quality

70 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 70 Popular Perceptions  The only thing an IP network can do to affect the quality of IPTV is loss The perceptual quality of the video is the same at the STB as it is at the headend if there is no loss within the network.  Cumulative IP jitter may impact video quality, depending on the receiver buffer size, and it is a leading indicator of loss  Network latency does not impact video quality per se, although it can cause a shift in view time

71 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 71 Media Delivery Index (MDI) An indicator of cumulative jitter and packet loss MDI = Delay Factor : Media Loss Rate  Delay Factor (DF) = The amount of buffer required to transport the jittered packets in the network without loss per sample period DF is proportional to the delay introduced in the system due to the network buffering.  Media Loss Rate (MLR) = The total media packets lost per sample period.

72 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 72  MDI Measurement Delay factor is Good Media Loss is Good For 3.5MB/s Expected delay DF: 2.81  MDI Measurement Delay factor is not good Media Loss is not good Expected DF was 2.81 Network Media Delivery Index An Example

73 © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 73


Download ppt "© 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 IP Multicast for Entertainment Video Cisco Days – Raleigh, NC."

Similar presentations


Ads by Google