Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer | Worldwide [change] Log In |Register |About Cisco Guest

Search

Solutions Products & Services Ordering Support Training & Events Partner Central

Hierarchical Navigation

• HOME
  • SOLUTIONS
    • SERVICE PROVIDER
      • MOBILE OPERATORS
        • SERVICE EXCHANGE FRAMEWORK FOR MOBILE OPERATORS
          • IMS/A-IMS
            • WHITE PAPERS
              • IP NGN Requirements for Scalable and Reliable Broadcast IPTV Services

Feedback: Help us help you Please rate this document.
  Excellent
  Good
  Average
  Fair
  Poor
This document solved my problem.
  Yes
  No
  Just Browsing
Suggestions to improve this document.

(512 character limit)

If you have provided a suggestion, please enter your full name and e-mail address. This information is optional and allows us to contact you if necessary.

Name: E-mail:

IMS/A-IMS

IP NGN Requirements for Scalable and Reliable Broadcast IPTV Services

Downloads IP NGN Requirements for Scalable and Reliable Broadcast IPTV Services

White Paper

---

IP Next-Generation Network Requirements for Scalable and Reliable Broadcast IPTV Services

---

The Cisco® CRS-1 Carrier Routing System delivers scalable and reliable multicast for broadcast IPTV services in next-generation core networks.

For service providers, the ability to offer broadcast IPTV services with high availability and reliability is imperative to remain competitive in an increasingly crowded industry. Meeting customer expectations for a high-quality IPTV service requires a network architecture and routing system that can handle the challenges of delivering broadcast video to millions of users simultaneously while also handling video on demand (VoD) as needed. The Cisco IP Next-Generation Network (IP NGN) architecture and the Cisco CRS-1 Carrier Routing System meet these requirements through a unique combination of outstanding platform scalability and reliability and efficient multicast for video distribution across the network. Together, these solutions from Cisco Systems® allow service providers to deliver entertainment-grade video services over an IP NGN.

CHALLENGES FOR DELIVERING ENTERTAINMENT-GRADE VIDEO ON IP NETWORKS

Service providers are moving decisively to deploy a variety of video-based services over IP infrastructure to maximize average revenue per user and to remain competitive. IP enables added flexibility and lowers cost for both broadcasters and service providers as they increasingly move to offer bundled triple-play services (video, voice and data) over a converged infrastructure. Video over the Internet has also evolved in many forms over the last few years from the latest TV shows being available for download to users posting their own created content on social community Websites. However, this type of video, normally referred to as over the top video, should be distinguished from true entertainment-grade video, which can typically be displayed on large screens to provide sufficient quality of experience for the viewer-usually in real time. Delivering entertainment-grade video over IP, often referred to as IPTV, which includes both IP-based broadcast and VoD services, poses significant challenges as service providers scale their networks and delivery systems to manage millions of subscribers, withstand periods of peak demand, and provide a superior quality of experience for viewers while balancing network capacity and efficient capital investment. This paper primarily focuses on requirements and solutions for scalable broadcast IPTV services for service providers.

MEETING HIGH USER EXPECTATIONS FOR VIDEO QUALITY

Entertainment-grade broadcast video―whether standard-definition television (SDTV) or high-definition television (HDTV)―have high user expectations for service level. Similar to the dial-tone of the traditional public switched telephone network (PSTN), viewers have come to expect broadcast video on their televisions to "simply work". Viewers do not want to suffer quality losses or disruptions in programming, meaning that the provider must protect the quality of broadcast video service from outages or degradation. Continued poor quality or repeated outages for video services, especially broadcast, will mean lost customers for the service provider. IP based network video is inherently very intolerant of packet loss because it is often highly compressed using encoding mechanisms such as MPEG-2 and MPEG-4, and because these video codecs typically do not recover from packet loss at the network layer, losing even a single packet of IP-encapsulated video can produce a visible degradation of video quality. Video codecs typically receive an MPEG-2 or MPEG-4 stream that is composed of three types of frames: the I, P, and B frames.

• The I frames are intra frames that contain information to describe the entire frame within a video stream. They are similar to standalone images that can be used to recreate the entire information for a picture within the stream.

• The P frames are predictive frames; they rely on information from a previous I or P frame to rcreate themselves as a full picture.

• The B frames are bidirectional, needing information from both the previous frames and following frames in the sequence to draw themselves fully. The previous and following frames can be only I or P frames.

The MPEG decoder or encoder uses a sequence of I frames, followed by P- or B frames within a stream, to form a group of pictures (GOP). The GOP is the number of frames between successive I frames, as shown by Figure 1. In SDTV broadcasts, the GOP typically varies from 12 frames in a 25-frames-per-second (fps) PAL signal to 15 frames in a 30-fps NTSC signal, meaning an I-frame is sent approximately every half second.

Figure 1. GOP Sequence in an MPEG Video Stream

The GOP sequence of encoding allows an MPEG stream to greatly reduce the bandwidth requirements of raw video to rates that are more manageable for today‘s networks. However, the interdependency of the P and B frames on the I frame also creates a requirement for highly reliable network transmission. The loss of an I frame can lead to introduction of significant visual artifacts such as pixilation, macroblocking, or even loss of picture frame, degrading the subscriber‘s viewing experience. Most service provider networks today support some type of high-availability mechanisms in the network¹ to provide protection in the event of a node or link failure. Yet tests² have shown that loss of even a single IP packet containing the I frame within the GOP in a single program transport stream (SPTS) can lead to significant degradation of the viewing experience.

Figure 2. Impact of IP Packet Loss on the Viewing Experience for an MPEG Stream

As shown in Figure 2, a single lost packet can result in up to one second of viewing degradation, with subsequent packet loss of up to 1000 packets for up to four seconds of degradation. Industry norms have defined the acceptable video quality of experience to be no more than one visible degradation per two-hour program. The corresponding network quality of service (QoS) for this measure is an allowed packet loss rate of approximately one packet in one million (10). For service providers delivering IPTV, this 10 maximum loss is considered a baseline requirement in the market.

OPTIMIZING THE INFRASTRUCTURE FOR BROADCAST VIDEO

Whether a traditional telephone company, a cable company, or a new network operator, most providers are redesigning their networks to build IP-based NGNs. These providers have realized that an IP NGN is required to handle the availability, the reliability, as well as the tremendous resource consumption of video while still supporting voice and data services with flexibility and control. Given that IP network video has far more stringent jitter and loss requirements than typical IP voice services, this can be especially challenging when combined with the dynamic nature of best-effort Internet traffic, which may also include over the top video, in networks today. Furthermore, the service provider‘s network infrastructure must continue to also support existing voice and business VPN services. Hence an IP NGN must also provide some mechanism for service isolation and separation while still providing the ubiquity and flexibility of a common IP foundation. For a more detailed discussion on IP NGN requirements, refer to the Cisco white paper "Building the Carrier-Class IP Next Generation Network". Telephone companies are adding infrastructure to deliver video over existing telephone lines or through new deployments of fiber links to homes and other consumer locations. Cable operators already have a video infrastructure in place. However, this infrastructure in certain areas lacks the full flexibility that IP can provide, for both broadcast and VoD services. As these operators move to offer more flexible content and expanded channel line-ups, the current network infrastructure must also meet these new requirements efficiently. The challenge for all these providers is to design their networks in a way that delivers a superior user experience and facilitates scalability at the lowest possible cost. A more detailed discussion about delivering IPTV and other video services over an IP NGN is presented in the Cisco white paper "Optimizing Video Transport in Your IP Triple Play Network."

DELIVERING BROADCAST VIDEO SERVICES EFFICIENTLY

Individual bandwidth requirements per household are expected to dramatically increase, reaching approximately 1.1 terabits(Tb) per month³ by 2010 in the U.S alone. This bandwidth growth will be driven by the adoption of HDTV, personal video recorders (PVRs), and other video-based applications over the network. For comparison, 20 of these homes would generate more traffic than the whole Internet backbone in 1995. As a result, estimates over the next five years alone project that global monthly IP traffic will rise to 11 exabytes,⁴ with a compound annual growth rate (CAGR) of more than 56 percent globally, led largely by video applications. Because broadcast video is streamed from a single source to multiple receivers (subscribers), these streams can create a tremendous traffic load on network infrastructure that has not been optimized for its efficient distribution. With customized channel line-ups in each region and with hundreds of channels or more⁵ in each line-up, the ability to scale delivery of broadcast video to millions of users is a crucial requirement for service providers. The bandwidth required for each broadcast streams can vary between 1 to 19.39⁶ Mbps, depending on the picture resolution, encoding, and compression rates used. Hence the distribution of all channels to all possible locations statically may not be the best use of the network capacity; it would be much more efficient to have some dynamic capability that distributed the necessary channels to the various market regions as they require them. This setup would enable optimal bandwidth use in the network as viewer patterns fluctuate. Clearly IP networks have to be architected to be able to handle this dynamism both efficiently and cost-effectively while supporting the massive scale that is necessary end to end. To summarize, service providers need a network architecture that can deliver the following:

• Emerging large-scale IP broadcast video services with the availability and reliability that delivers an entertainment-grade experience, which will be the foundation of customer retention

• Capability to recover from network failures quickly and in a way that is transparent to end customers

• Multiple services across a common network infrastructure with separation of those services for enhanced availability, reliability, and manageability

• Support for efficient and more dynamic distribution of broadcast video over IP for increased flexibility and reduced costs

THE SOLUTION: A NETWORK DESIGNED FOR HIGHLY AVAILABLE AND SCALABLE BROADCAST VIDEO SERVICES

To address the challenges of delivering entertainment-grade video programming, the service provider‘s network must support high availability and scalability. Video support must be deployed in the core, distribution, and access layers of the network. Networks architected for video delivery are typically broken into three functional areas: super headend (SHE), video hub office (VHO), and video switching office (VSO) (Figure 3). Cable operators may have a similar structure but use different terminology for these functional areas in the network.

• Super headend (SHE): The super headend receives satellite feeds of scheduled and live programs from broadcasters. The super headend may also receive assets for on-demand services by means of satellite, store VoD for special on-demand content, and incorporate back-end systems such as the subscriber database. New video architectures typically identify two national super headends, for redundancy against solar interference, which usually reside within the core of the transport network, with one headend serving as primary and the other as backup. Although most new video networks are built with this architecture, many current video providers also have satellite receiving stations in each region, resulting in higher overall operational costs. With an IP NGN, video providers have an opportunity to nationally consolidate many receiving stations into a primary and back-up location. The super headend would then deliver channel line-ups, VoD assets, and niche programming to the regions over the IP NGN.

• Video hub office (VHO): VHOs often contain real-time encoders for local television stations and PEG channels (public, education, and government), VoD servers as well as the network routers that connect the distribution and core networks. Service providers typically maintain a few dozen regional VHOs, predominantly in metropolitan areas, that serve 100,000 to 500,000 homes. VHOs may also provide connectivity for business services such as Layer 3 and Layer 2 VPNs.

• Central office and video switching office (VSO): Central offices and VSOs house aggregation routers and DSLAMs that aggregate traffic from subscriber homes.

Figure 3. IP NGN Architecture for the Streamlined Delivery of Video Services Across Network Layers and Locations

Cisco helps service providers achieve streamlined service delivery through the ServiceFlex design, an integral part of the Cisco IP NGN architecture. Cisco‘s ServiceFlex design delivers video, voice, and data services while ensuring IP intelligence is maintained throughout the network, from the core to the distribution and aggregation layers. ServiceFlex employs flexible and proven Layer 3 native IP and IP Multicast mechanisms, which deliver proven scalability, resiliency, and are used in the world‘s largest video distribution networks, enabling service providers to deliver scalable broadcast IPTV services while creating a robust foundation for future video services and applications.

IP MULTICAST FOR THE DELIVERY OF SCALABLE BROADCAST VIDEO SERVICES

Traditional IP communications allow a host to send packets to one receiver (unicast transmissions) or to all receivers (broadcast transmissions). IP Multicast provides another option by allowing a host to send packets to a defined group of receivers, as defined by a multicast group. A mechanism known as anycast further allows the reuses of IP addresses across multiple devices in order to provide enhanced redundancy. This mechanism can be used in conjunction with multicast to ensure that the source of a multicast stream is not a single point of failure. This scenario is achieved by having two multicast sources configured with identical source and destination IP addresses but residing at different locations in the network, allowing the network to determine the optimal one to use at a given point in time. For efficient delivery of video services, IP Multicast used in conjunction with anycast mechanisms thereby provides source redundancy of multicast streams in the Cisco ServiceFlex design. IP Multicast is a mature, proven bandwidth-conserving technology specifically designed to reduce network traffic by delivering a single video stream to potentially millions of recipients simultaneously (Figure 4). By replacing separate streams for each recipient with a single stream for all, IP Multicast reduces the burden on intermediate routers and reduces overall network traffic. Within the network, routers are responsible for replicating and distributing the multicast content to all eligible recipients. A more detailed look at multicast technology is presented in the Cisco white paper "IP Multicast Technical Overview."

Figure 4. IP Multicast Technology Reduces Network Load by Efficiently Delivering a Single Video Stream to Many Recipients Simultaneously

THE CISCO CRS-1: MEETING SERVICE PROVIDER REQUIREMENTS FOR A BROADCAST VIDEO SOLUTION

To solve the varied challenges of delivering broadcast video over an IP network, service providers need a routing system that can form the foundation of their IP NGN, and deliver on the following:

• Scale to handle terabit traffic levels

• Support robust and scalable multicast replication in hardware

• Support resilient routing of broadcast video feeds, with minimal service disruption at all times across the network

• Provide continuous operation of the routing platform when router components or software processes potentially fail

• Allow service separation, for each service to be isolated and eliminate the effects of one service on another

In the core of an IP NGN, the Cisco CRS-1 is the platform of choice for meeting these requirements. The Cisco CRS-1 allows service providers to build a highly scalable, available, and flexible converged network infrastructure. The platform runs Cisco IOS® XR Software, which is a unique self-healing and self-defending operating system designed for always-on operation, while scaling system capacity from 320 Gbps up to 92 Tbps. For delivery of video services, the Cisco CRS-1 offers the advantages of network and platform scalability, multicast scalability, network resilience, platform redundancy, and secure service separation.

NETWORK AND PLATFORM SCALABILITY

Service providers typically have deployed two single-chassis routers at each network node for resiliency, with interconnects between them. However, as video traffic demands grow, and with single-chassis routers offering inadequate capacity, service providers have added more routers and more interconnect links, which increases complexity and cost. The primary advantage of a scalable multichassis design is that providers can avoid the use of expensive, high-speed interconnect links between multiple routers in a point of presence (POP) as this connectivity is provided by the multichassis fabric. As a result, overall system capacity and ports can be freed for customer-facing bandwidth and applications. Analysis has shown more than 40 percent cumulative CapEx and OpEx saving over a period of 5 years for multichassis systems compared with equivalent capacity single-chassis units.⁷ With the rapid increase in video traffic, providers will experience a greater need to deploy multichassis systems to achieve economical scalability for both the number of interfaces and total bandwidth that must be supported across their core networks. To accommodate this growth in an operationally cost-effective and non-disruptive manner, a primary requirement is a system with a switch fabric architecture that supports in-service scaling from a single chassis to a large number of multichassis units. The Cisco CRS-1 can be deployed as a single-shelf or multishelf system that is built by interconnecting multiple line-card shelves using up to eight fabric shelves (92 Tbps). The Cisco CRS-1 is also upgradable between single and multishelf while in operation with no service disruption to customer traffic. The innovative Cisco CRS-1 system fabric, based on three-stage Benes topology, allows multichassis scalability from 2 to 72 line-card shelves, each line card shelf supporting 16 slots at 40 Gbps. The Cisco CRS-1 line-card shelves hence can support up to 9216 ports of 10 Gigabit Ethernet and 1152 ports of OC-768c/STM-256 Packet over SONET/SDH (PoS) in the system‘s maximum configuration. As the data-plane-forwarding component of a routing system is scaled to terabit capacities, the corresponding control-plane processing must scale in a comparable manner. Multiple-terabit routing systems with single-point-of-control processing present a bottleneck to the overall scalability of those systems and their applications and a potential single point of failure. A more distributed design, in both software and hardware, is needed to allow control-plane scaling for demanding video applications. The processing capabilities of a single, central route processor would be inadequate or undesirable for overall service resiliency of such a large system. The Cisco CRS-1 supports the use of multiple distributed route processors (DRPs) in addition to the standard active and standby route processors (RPs) across a multishelf configuration. This design eliminates the limitation of a single primary route processor per routing system. In the Cisco CRS-1, the DRPs are composed of two dual-processor symmetric multiprocessing (SMP) complexes per module. The DRPs use the distributed control-plane scaling aspects of the Cisco IOS XR operating system for applications such as Border Gateway Protocol (BGP), Label Distribution Protocol (LDP), Protocol Independent Multicast (PIM), and Internet Group Management Protocol (IGMP). Use of such a distributed control-plane mechanism in the Cisco CRS-1 provides support for a large number of routes, peers, and hosts for any protocol, such as multicast routing, independent of other routing system applications-an important consideration for a scalable broadcast video service.

MULTICAST SCALABILITY

Multicast implementations in single-chassis and multichassis routing systems vary in design, which can affect overall performance, service scalability, and the experience of the IPTV viewer. The two predominant designs differ at the point within the routing system architecture where packet replication for multicast is actually performed: within the line card or within the switch fabric.

Replication Within the Line Card

In the line-card-based replication approach, when a Join (2) message (a request to participate in a IPTV multicast stream or group) as shown in Figure 5a (on the left) arrives at the platform, the receiving line card makes a request to the line card (normally through the central route processor) containing the inbound stream and obtains a copy of the data as indicated by (3). In certain line-card-based replication designs, subsequent Join messages send requests to the last-joined neighboring line card for additional copies of the data, rather than to the initial line card that contains the source stream, once a certain limit (2, 3, and 5 in this example) has been reached (6). The line-card replication design creates a tree-like structure internally within the routing system to distribute the multicast traffic to the receivers. This line-card replication approach has several major disadvantages. First, because replication is performed at the ingress and egress line cards, the single multicast stream⁸ traverses the switch fabric numerous times as the number of neighbors increases, thereby consuming fabric capacity unnecessarily in the routing system. Second, because the line cards themselves perform the multicast replication, the forwarding performance of unicast traffic on these line cards can be adversely affected, and the forwarding performance of multicast traffic is always a fraction of the overall unicast forwarding performance because of the suboptimal design of the replication architecture. Finally, when a Prune (2) message (a request to exit a multicast stream) arrives at one of the line cards participating in the replication, such as when the last user of a downstream IPTV session leaves, that node is removed from the multicast tree structure, halting all downstream replication from that line card to other neighbors (4 and 5), shown on the right in Figure 5b. This action forces a reconvergence of the multicast tree within the routing system, which imposes serious degradation on those continuing downstream IPTV multicast sessions on the exiting node-and potentially outright session loss.

Figure 5. Non-optimal Line-Card Replication Design for Multicast

These intrinsic limitations for multicast in line-card-based replication designs create network-level and service-level scalability limitations for service providers wanting to deploy IPTV services over an IP or MPLS⁹ based core network requires to scale to millions of simultaneous users. To efficiently offer these services, they need the scalable and flexible core architecture provided by the Cisco IP NGN together with the Cisco CRS-1.

Replication Within the Switch Fabric

The service-intelligent, three-stage, self-routed Benes topology in the switch-fabric architecture of the Cisco CRS-1 implements line-rate multicast replication within the fabric (Figure 6). This implementation eliminates the complexity and burden of systemwide multicast replication from the forwarding engines (FEs) on the line cards, which is the mechanism used in many other fabric routing systems. The fabric topology is also service-aware through the use of separate hardware sets of priority queues for multicast traffic, unicast traffic, and control messages. The separate queues help ensure that cells¹⁰ across the fabric have bounded jitter and latency characteristics, particularly important when encoded video and VoIP services are mixed with best-effort data applications at multiple-gigabit speeds. The self-routing, fully non-blocking fabric of the Cisco CRS-1 also allows lossless transport in the event of a component failure by supporting a 1:N redundancy mechanism between the eight separate fabric planes. This capability provides a level of resiliency and self-healing that facilitates the correct distribution of traffic flows while still maintaining the service intelligence required for efficient and scalable multicast distribution. The Benes topology switch fabric of the Cisco CRS-1 consists of three stages, as shown in Figure 6. Stage 1 (S1) accepts cells from the ingress line card and distributes them across all Stage 2 (S2) fabric cards. Stage 2 performs multicast replication based on fabric group identifiers¹¹ (FGIDs), delivering the cells to the appropriate Stage 3 (S3) fabric card through multiple priority queues for both unicast and multicast traffic. This queuing implementation accelerates traffic as it exits Stage 2. Stage 3 replicates streams based on FGIDs to the appropriate egress line card, which subsequently reassembles the packets and delivers them to the appropriate interface or subinterface. A prune or failure at any of the endpoints does not produce an undesirable, systemwide effect, unlike line-card-based replication mechanisms, and does not affect the experience of any other IPTV viewer across the system. Additionally, because the replication is performed by the fabric, fabric capacity is used efficiently to maximize overall system scalability, and multiple fabric traversals for the same multicast streams are eliminated. This efficiency is crucial because the Cisco CRS-1 architecture has been designed to scale to 1152 possible line cards across 72 line-card shelves, to support a truly scalable multicast implementation at the foundation of the Cisco IP NGN.

Figure 6. Service-Intelligent Switch-Fabric Architecture of the Cisco CRS-1 Supporting Fabric-Based Multicast Replication

NETWORK-LEVEL RESILIENCY FOR BROADCAST VIDEO

Consumer expectations regarding the quality of broadcast video are increasing, and service providers need to differentiate their video offerings based on quality and overall reliability. Broadcast video requires the fastest service restoration times and guaranteed delivery because outages have the potential to affect wide audiences-potentially in the millions. Meeting these expectations requires a high degree of resilience across the network infrastructure. To successfully meet these challenges and transport video reliably, service providers must consider a network architecture that maintains the user‘s viewing experience, even during times of network failure or instability, by going beyond common existing resiliency mechanisms in the industry. Service providers will specifically need to consider a network that supports path diversity to ensure that no single point of failure exists for the delivery of reliable broadcast video.

Path Diversity

The Cisco IP NGN rchitecture with the Cisco ServiceFlex design supports path diversity for delivery of dual-live video streams from either single or dual sources for maximum resiliency. Dual-live refers to the capability for a client to simultaneously receive identical content from either one or two independent sources via different network paths (Figure 7). If errors occur in a video stream, the receiver can switch from one stream or source to the other. The dual-live design utilizing path diversity avoids the disruption that can be caused by network reconvergence time and the resulting loss of I-frames within a broadcast MPEG stream across the network. The end clients for dual-live transmission can be QAMs, DSLAMs, ad splicers, or other devices capable of sourcing redundant feeds. Whether SDTV or HDTV, broadcast video requires significantly less overall bandwidth than VoD when efficient multicast is used, meaning that additional capacity for streaming content from duplicate sources using native IP multicast mechanisms is not excessive and can be supported in networks today. For a dual-live architecture to be effective, the network must support path diversity. The path diversity mechanism ensures that the path between the primary video source and the receiver share no links or nodes in common with the path between the secondary video source and the receiver, so that a link or node outage cannot affect both paths simultaneously. For VoD services, anycast mechanisms can be used to provide source diversity, as such services are typically limited to a smaller number of viewers. For heavily watched broadcast services, path diversity allows the service provider to maintain the maximum subscriber viewing experience even during times of network-level disruption.

Figure 7. Cisco IP NGN with the Cisco ServiceFlex Design Supports Path Diversity That Delivers Dual-Live Video Streams Without the Disruption of Recovery Time from Network Failure

PLATFORM REDUNDANCY FOR BROADCAST VIDEO

The overall reliability and redundancy of the routing platform is also an important factor for highly reliable distribution of broadcast video. Certain platform-level characteristics are imperative for support of broadcast video services in any core network. The Cisco CRS-1 is designed for continuous system operation and can hence recover from element and component failures within the system at every level, without disrupting existing user traffic and services. The Cisco CRS-1 data plane and control plane provide independent scaling and redundancy mechanisms:

• Granular, in-service software upgrades (ISSU) for all applications, drivers, and system and subsystem components

• Hitless route processor switchover with nonstop routing (i.e. Intermediate System to Intermediate System [IS-IS] Protocol), nonstop forwarding (i.e. BGP or Open Shortest Path First [OSPF] Protocol), and fast convergence of control protocol subsystems such as distributed line-card-based Bidirectional Forwarding Detection (BFD) for PIM

• Granular process restart, distribution, and management, as well as interprocess fault tolerance

• Cisco IOS XR Software, a microkernel-based, symmetric multiprocessing (SMP), highly modular operating system that supports distributed applications and infrastructure

• Complete system redundancy at the hardware level for control, forwarding, management, power, and cooling

As service providers consolidate multiple services over an IP NGN architecture, the redundancy aspects of both the data-plane forwarding and control-plane processing allows the support of continuous system operation for the improved service reliability needed for broadcast video.

SERVICE SEPARATION

Some type of service separation is needed to help ensure fairness and operating efficiencies for multiple services across a converged IP NGN infrastructure. This separation helps service providers manage the vast amounts of best-effort Internet traffic while supporting the sensitivity to jitter and latency of video and business services. One type of separation uses DiffServ¹², a protocol that provides QoS for multiple traffic types-and defines and classifies services based on priorities. These priorities are defined within the header of IP packets and determine per-hop behavior (PHB) by intermediate nodes in the network. DiffServ-based QoS is a stateless design that facilitates scalability, performance, interoperability, and flexibility. However, DiffServ typically cannot provide administrative separation at a per-service level, because only a single, end-to-end administrative domain exists for the network. Another, more common approach is separation by topology. Each service is allowed a separate topology that uses separate physical or virtual interfaces and forwarding instances. In the past, service providers typically deployed multiple parallel networks for each service in order to ensure full separation. With IP NGNs, this deployment can be accomplished over a converged network that shares common routing hardware and software instances. Each service usually has limited knowledge about the topology of other services. Many technologies exist at both Layer 2 and Layer 3 to achieve topology-based separation, including VLANs, Virtual Private LAN Services (VPLS), Layer 2 Tunneling Protocol (L2TP) Version 3, MPLS traffic engineering, and Virtual Route Forwarding (VRF). A common mechanism is the use of MPLS traffic engineering, where experimental bit (EXP) class definitions determine traffic engineering tunnel selection for each service. Topology mechanisms provide flexibility for path selection, bandwidth control, and per-service QoS that may be sufficient for some applications. However, the level-of-service separation does not provide the level of granular control needed by some service providers, for example, in MPLS Layer 3 VPNs. Although each VPN service is virtualized using VRF on a router, this virtualization is limited in terms of operational management. For example, a software upgrade will affect all VPN instances and typically cannot be limited to a subset where needed. In addition, software faults and events such as distributed denial-of-service (DDOS) attacks have the potential to affect all services on the system. To overcome these limitations, service providers in some cases have resorted to building service-specific physical networks, each using IP, such as one network for best-effort Internet traffic and a separate network for VPN services. The introduction of broadcast video to the core network poses a similar dilemma for the service provider: How best to gain the expense savings offered by a single IP NGN infrastructure while maintaining the separation requirements of individual services. With the Cisco Service Separation Architecture (SSA) in Cisco IOS XR Software, the Cisco CRS-1 provides the capability to partition the system into multiple secure domain routers (SDRs) through the use of additional DRP modules with dedicated processing memory and management across a single-chassis, or multichassis system. SDRs provide a means to partition a single physical router into multiple, independent routers. SDRs perform all routing system functions in the same manner as a physical router, but share resources such as the switch fabric, power, and cooling with the rest of the system to provide overall cost savings for the service provider. In particular, the Cisco SSA allows complete software independence among SDRs within a single physical routing system, which allows the SDRs to run independent versions of software and sets of applications among them. As a result, any effects on an SDR resulting from a fault or network event are completely self-contained and do not affect other SDRs or services on the system. Cisco SSA also allows complete management separation between SDRs, which allows different administrative groups within a service provider to independently configure, maintain, and manage services among them securely. Cisco SSA on the Cisco CRS-1 offers service providers a much more granular, flexible, and resilient form of service separation than other methods available today. The use of Cisco SSA in the Cisco ServiceFlex Design provides service separation between best-effort Internet traffic, Layer 3 or Layer 2 business VPN services, and broadcast video services, as depicted in Figure 8. This separation allows the delivery of scalable and resilient broadcast video services over a Cisco IP NGN core infrastructure.

Figure 8. Cisco ServiceFlex Design Supporting Service Separation Across the Cisco IP NGN Core Infrastructure

CONCLUSION

Broadcast video services and transport are playing an increasingly important role in service provider IP NGNs. Cisco has developed a service optimized IP NGN architecture, for service providers that, together with the Cisco CRS-1:

• Delivers emerging large-scale IP broadcast video services with the availability and reliability that ensures an entertainment-grade experience

• Supports efficient and scalable distribution of these broadcast video services over an IP NGN for increased flexibility and reduced costs through proven IP Multicast technology

• Enables recovery from network failures quickly and in a way that is transparent to end customers through path diversity and anycast mechanisms

• Offers multiple services across a common network infrastructure but still provides separation of those services for enhanced availability, reliability, and manageability

With these solutions, service providers can offer scalable and reliable broadcast IPTV services over an IP NGN that delivers high quality entertainment-grade viewing experience for all their customers.

FOR MORE INFORMATION

Additional information about the concepts discussed in this document can be found in the following documents:

• Building the Carrier-Class IP Next Generation Network white paper, at: http://www.cisco.com/en/US/products/ps5763/products_white_paper0900aecd802e2a52.shtml.

• Optimizing Video Transport on Your IP Triple Play Network white paper, at: http://www.cisco.com/en/US/products/hw/routers/ps368/products_white_paper0900aecd80478c12.shtml.

• IP Multicast Technical Overview white paper, at: http://www.cisco.com/en/US/products/hw/routers/ps368/products_white_paper0900aecd804d5fe6.shtml.

• Integrated Video Admission Control for the Delivery of a Quality Video Experience white paper, at: http://www.cisco.com/en/US/products/hw/routers/ps368/products_white_paper0900aecd804a05bd.shtml.

For more information about the Cisco CRS-1, visit: http://www.cisco.com/go/crs. ¹Multiprotocol Label Switching (MPLS) Fast Reroute(FRR) is one such mechanism, which typically provides low levels of packet loss through failover to a backup path usually within 50ms. ²Tests conducted by Cisco used a single-program transport stream (SPTS) at 3.75 Mbps with a GOP size of 15. ³Cisco estimates, based on each home with one HDTV television, one SDTV television, two PVRs, one VoIP phone, and high-speed data service. ⁴1 exabyte (EB) = 1 x 10 bytes. Source: Cisco estimates, Ovum, Bernstein, and public company data. ⁵Major cable providers in the United States currently offer 300+ channels, while some terrestrial service providers in Japan are looking to offer channel line-ups in excess of 1000+ channels across the country. Most satellite providers also offer in excess of 500+ channels today. ⁶19.39Mbps is the maximum data rate as defined by the Advanced Television Systems Committee (ATSC) for HDTV broadcasts using MPEG-2 transport. ⁷Cisco estimates based on POP bandwidth projections for a large North American service provider. ⁸An MPEG-2 stream is typically about 19.39 Mbps for HDTV and 3.5 Mbps for SDTV. ⁹Note, the same replication mechanism would typically be used regardless of whether the multicast traffic is IP or MPLS based transport as with PTMP-TE. ¹⁰IP packets are divided into fixed-length cells for efficient transport within the Cisco CRS-1 routing system. ¹¹FGIDs determine which destinations get copies at Stage 2 and Stage 3 cards. ¹²Differentiated Services - RFC 2474 Contacts & Feedback | Help | Site Map © 1992-2007 Cisco Systems, Inc. All rights reserved.Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc.