High-quality and resilient
           IPTV multicast architecture
      Technical White Paper

An overview of ResIP mult...
2/20   High-quality and resilient IPTV multicast architecture – Technical White Paper

                  Executive summ...

                                        This document focuses on:

       The ResIP design for IPTV        • Netw...
4/20   High-quality and resilient IPTV multicast architecture – Technical White Paper

                     1. Introduc...

          2. Meeting end user
       expectations for IPTV

       User expectations already      Introduction of...
6/20   High-quality and resilient IPTV multicast architecture – Technical White Paper

                     3. Network ...

       Influence of video-on-demand services
       VoD produces high bandwidth constraints on the network as uni...
8/20   High-quality and resilient IPTV multicast architecture – Technical White Paper


          4. Access network

       TR-101 differentiates between two different approaches fo...
10/20   High-quality and resilient IPTV multicast architecture – Technical White Paper


        However, some of this information is dynamic in nature (e.g. DSL sync
        rate) and cannot come from...
12/20   High-quality and resilient IPTV multicast architecture – Technical White Paper

           5. Core network

                                                    Multicast       Register messages
             Active       ...
14/20   High-quality and resilient IPTV multicast architecture – Technical White Paper

15/20   High Quality and Resilient IPTV Multicast Architecture – Technical White Paper

16/20   High-quality and resilient IPTV multicast architecture – Technical White Paper

                     6. Conclus...

           7. About Nokia Siemens
        and Juniper Networks
        Nokia Siemens N...
18/20   High-quality and resilient IPTV multicast architecture – Technical White Paper


                 8. Abbreviations

        ATM      Asynchronous Transfer Mode            MPLS-TE   MPLS Traffi...
Nokia Siemens Networks Corporation
P.O. Box 1
02022 Nokia Siemens Networks

Visiting address:
Karaportti 3, Espoo,...
Upcoming SlideShare
Loading in …5

High Quality and Resilient IPTV Multicast Architecture


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

High Quality and Resilient IPTV Multicast Architecture

  1. 1. High-quality and resilient IPTV multicast architecture Technical White Paper An overview of ResIP multicast architecture design guidelines
  2. 2. 2/20 High-quality and resilient IPTV multicast architecture – Technical White Paper Executive summary Profit from emerging broad- Nokia Siemens Networks and Juniper Networks have joined together to develop band services for residential and implement carrier-grade end-to-end Next Generation Network (NGN) solutions with best-in-class QoS, reliability, management, and security. customers. The Resilient IP (ResIP) Certified solutions are the product of more than three years of joint solution development work focused on validating, optimizing, and certifying IP solutions for voice, video, and data applications – end-to-end. Tested and verified engineer- Nokia Siemens Networks and Juniper cooperate to provide a complete, optimized ing excellence to provide ResIP Certified IPTV solution. The ResIP Lab combines best-of-breed products with design know-how to provide solutions that minimize technical deployment best-in-class IPTV solutions. risks, ensure interoperability and scale. The end result is a quicker time to market and an assured user experience for IPTV services. Contents 2 Executive summary 4 Introduction 5 Meeting end user expectations for IPTV 6 Network aspects 9 Access network architecture 12 Core network design concepts 16 Conclusion 17 About Nokia Siemens Networks and Juniper Networks 19 Abbreviations
  3. 3. 3/20 This document focuses on: The ResIP design for IPTV • Network aspects, which are influenced by the introduction of IPTV services services for efficient deploy- regarding required bandwidth, reliability, network responsiveness, and QoS. ments and reliability. • Different access network architectures are described, focusing on the currently discussed VLAN models. • The Layer 2 control mechanism and how this tool improves dynamic QoS concepts are described. • Protocol Independent Multicast – Sparse Mode (PIM-SM), Protocol Independent Multicast – Source Specific Multicast (PIM-SSM) or Point-to-Point MPLS LSPs can be used for distributing the IPTV content through the IP backbone. Leverage expertise from two Service providers can tailor the ResIP Certified solutions and engineering work industry leaders. to their specific network environment. Nokia Siemens Networks and Juniper Networks offer professional network planning and implementation services to help carriers customize their IPTV solution.
  4. 4. 4/20 High-quality and resilient IPTV multicast architecture – Technical White Paper 1. Introduction Nokia Siemens Networks Telecom operators around the world are facing the challenge of declining voice and Juniper Networks revenues due to increased competition and the mass proliferation of mobile communications. In addition, cable TV operators are adding voice services to demonstrate combined voice their traditional cable offering, and are thus entering into the domain of telecom- and video expertise in the munication carriers. joint ResIP Lab. Studies have shown that end customers will pay for an attractive service bundle comprising voice, video, and data, and prefer to have a single bill from a trusted operator for all their service needs. Under these conditions, it has become manda- tory for the incumbent fixed line carriers to reposition themselves in the changed competitive landscape. There is a strong need to migrate from simple infrastruc- ture provider to a one-stop service provider. The new business model for the carriers will be driven by the expectations of end users for multimedia services. The operator’s network must be able to support the multimedia services requirements, i.e. the need to have voice, data, video on de- mand (VoD), and TV broadcast services. The success of service bundling is dependent on satisfying the expectations of the end user. Early movers on the IPTV market have faced the risk of suffering from technical barriers and challenges. In several cases, technical issues have led to stalled projects, incomplete service offerings, and unexpected quality degradation of the services. This in turn has affected the acceptance of the triple-play services and resulted in negative impact on margins and increased customer churn. Innovative online Nokia Siemens Networks and Juniper Networks partner to develop complete entertainment and solutions to help service providers to successfully introduce and grow triple-play services. Expertise from both companies have been brought together in the ResIP communication via TV. Lab to validate, optimize, and certify IP solutions that service providers can use to deliver VoIP trunking, triple-play, and now IPTV services with an assured quality of experience.
  5. 5. 5/20 2. Meeting end user expectations for IPTV User expectations already Introduction of new services always involve a number of commercial and technical settled by existing risks. The success of services is dependent on meeting the requirements and ex- pectations of end users. TV services have been available for a long time over distribution technologies. legacy infrastructures including terrestrial broadcast, cable networks, and satellite. End users have come to expect a level of service regarding availability, latency, and quality. Therefore, it is vital to keep the technical risks to a minimum and to meet user expectations and needs. To make the IPTV services a success, it is required to establish IP networks that guarantee the quality of service (QoS) even under adverse network conditions. End user requirements are driving the need for: • assured quality of service in real time including fast interactive responsiveness and minimum number of visual and acoustic defects • a broad portfolio of video service offerings such as broadcast TV, VoD, personal video recording, or time-shift TV and the availability of premium content • high availability, i.e. no single point of failure and fast recovery mechanisms for sub-second failover times • easy and convenient handling ResIP Certified IPTV In addition to the end user’s expectation, service providers need to reduce costs solution provides carriers (from both the equipment point of view and the operational point of view) and increase revenues. Network operators must: with industry-leading broad- band video programs. • optimize the utilization of network resources in both unicast and multicast environments • minimize operational efforts through advanced management tools and zero- touch provisioning recommendations • be quicker to market with new services • be flexible and maintain investment protection to address a broad range of access types, network architectures, aggregation technologies, and existing protocol environments
  6. 6. 6/20 High-quality and resilient IPTV multicast architecture – Technical White Paper 3. Network aspects The introduction of IPTV services, including both broadcast TV and on-demand services, onto today’s broadband IP networks changes several aspects of these networks. 3.1. Bandwidth dimensioning IPTV and VoD services require high bandwidth capacities and predictable per- formance, placing additional requirements on the network. Depending on the compression and coding technology, the following transmission rates should be considered: • MPEG-2-coded SD VoD video streams or IPTV stream per one TV channel: 3.5-5 Mbit/s • H.264-coded (MPEG-4 part 10) SD VoD video streams or IPTV stream per one TV channel: up to 2 Mbit/s • HD signals will need 8-12 Mbit/s coded with H.264 IPTV and video services have different influences on available network resources. Several factors have to be considered before the implementation of an IPTV service including: Influence of broadcast TV (IPTV) services Key elements of the ResIP The total number of IPTV channels streamed online determines the total band- Certified IPTV solution are width requirements. The total transmission rate of the IPTV content measured in Mbit/s equals the sum of all concurrent streams. Each IPTV channel is sent only the design guidelines and once from the video headend to the network, independent of the number of po- the proof-of-concept. tential TV broadcast receivers. The distribution to all subscribers is achieved by multicast implementations in the core and the access networks. For example, if 30 IPTV channels are broadcast and each channel is encoded by H.264 codec providing a gross bit rate of 2 Mbit/s (incl. Ethernet overhead), 60 Mbit/s bandwidth is required for the IPTV service. The calculated 60 Mbit/s IPTV traffic will be trans- mitted via the network operator’s IP core network to the DSLAMs independent of the number of end customers. This amount of traffic does not affect the throughput of the IP core network dramatically. In the core network, typically all offered IPTV channels are distributed without considering the current usage of every channel. However, in the access network, bandwidth can be reduced by supporting IGMP (Internet Group Multicast Protocol) snooping in the aggregation switches and edge routers. IGMP snooping can pas- sively snoop on IGMP Query, Report and Leave (IGMP version 2) packets trans- ferred between IP multicast routers/switches and IP multicast hosts to learn the IP multicast group membership. It checks IGMP packets passing through it, picks out the group registration information, and configures multicasting accordingly. Without IGMP snooping, multicast traffic is treated in the same manner as broad- cast traffic, that is, it is forwarded to all ports. With IGMP snooping, multicast traffic of a group is only forwarded to ports that have members of that group. IGMP snooping with proxy reporting can help reduce the IGMP Membership Report messages. Statistics in existing IPTV installations have shown that about 50% of all offered channels are requested by at least one user per DSLAM. This number depends on the ratio of free TV and pay TV channels or the quality of the electronic program guide (EPG).
  7. 7. 7/20 Influence of video-on-demand services VoD produces high bandwidth constraints on the network as unicast frames are used for streaming video signals to the end user. VoD is therefore highly resource consuming. Total transmission rate equals the sum of all concurrent video streams. For example, a VoD service planned for 10,000 IPTV subscribers must be ca- pable of handling VoD requests for 10% of IPTV subscribers. A realistic average number that is commonly used for budgetary calculations is 10%. Thus, 1,000 simultaneously transmitted movies encoded in H.264 format at 2 Mbit/s gross bit rate will produce 2 Gbit/s traffic. The IP core network must be capable of handling the additional traffic load. 3.2. Reliability Reliability is one of the key requirements for networks delivering IPTV services. Avoidance of any single point of failure and subsecond restoration times is a key fundamental of all ResIP design concepts. This includes both the IP core network and the access/aggregation network. The IP core network can be based on either the Interior Gateway Protocol (IGP) like IS-IS or OSPF or on an MPLS backbone. The access and aggregation network is Ethernet-based with redundant intercon- nection of the video headend equipment to the IP core network. An example for a resilient multicast network design is shown in Figure 1. This network design assumes that the multicast replication is achieved in the DSLAM, and that that and the multicast traffic is distributed from the redundant IP edge via a multicast VLAN to the DSLAMs. Usually there is only one IPTV edge location in the network. In some situations, geographic redundancy is required and there are two IPTV edge locations. However, there are usually multiple IP edges, one for each regional access and aggregation network. For the access and ag- gregation network, two options are generally possible. First, the topology can be built as a tree structure, using Rapid Spanning Tree Protocol (RSTP) or Multiple STP (MSTP) to resolve redundant paths. Secondly, ring topologies are emerging to improve reliability. The innovative Nokia Siemens Networks Ethernet Ring Protection (ERP) provides very fast switch-over times in case of ring failures. IP edge IPTV edge G1 G1 G2 G1+G2 Resilient IP core aggregation G1 G2 G2 G1+G2 Figure 1: Redundant multicast network design
  8. 8. 8/20 High-quality and resilient IPTV multicast architecture – Technical White Paper 3.3. Quality of service IPTV is a real-time service that has very stringent QoS requirements, specifically packet loss and delay. A small amount of delay does not directly affect the quality of experience of IPTV. However, a delay longer than 1 second may result in a less than satisfying end user experience if a neighbor with traditional TV service is able to watch a goal in an important soccer game several seconds in advance. Packet loss will likely cause visible artifacts due to the high compression rates of MPEG encoded TV signals. In order to have less than one visible artifact per movie on the TV screen, the packet loss rate must be lower than 10-6. As quality of service is a comprehensive subject in the network design, a separate document will highlight the ResIP QoS recommendations for IPTV. 3.4. Network responsiveness One prominent aspects of a good user experience for IPTV services includes fast channel change (also known as zapping). Channel change delay, i.e. the time between pushing the remote control button and the first video frame being rendered on the viewing device, is mainly influenced by the following: • processing of the remote control request • IGMP control processing (set-top box (STB), residential gateway, network) • data plane protocol stack processing, including DSL interleaving delay, de- cryption, FEC, etc. • STB jitter buffer delay • Buffer for video encoding • MPEG decoder delay for resynchronizing with the new program Experience, knowledge and The latency of IGMP processing in the network (e.g. the residential gateway, leadership – ResIP Certified DSLAM and BSR) also directly adds to the overall zapping delay. IPTV solution. The required size of the jitter buffer depends on the jitter of the media stream re- ceived by the STB. The jitter generated by a well-engineered high bandwidth IP network is less than 50 ms. The video source itself should also produce low jitter streams. MPEG decoder delay usually makes up the largest part of the overall delay budget, because the decoder must usually wait for an I-frame to resynch. Also, additional decoding delay results due to the use of B-frames which are encoded using past and future I- and P-frames. This delay depends on the compression rate, the encoding algorithm and the number of B- and P-frames between two I-frames (GOP). This results in a tradeoff between channel change delay and compression rate. High compression rates imply a large GOP with extensive use of B-frames, and therefore result in a large encoding/decoding delay. To improve the responsiveness from a user’s perspective, the STB immediately shows a dialogue box with the program name, time, channel, etc. upon receiving a zapping request for another channel via the remote control. This ensures that end users will never view a black screen while waiting. The DSL Forum has recently finished the specification (TR-101) for the fundamen- tal architecture for Ethernet-based DSL aggregation networks, which also includes definitions for the delivery of multicast services.
  9. 9. 9/20 4. Access network architecture TR-101 differentiates between two different approaches for connecting broadband DSL users to the aggregation network, first the so-called 1:1 (also known as VLAN per subscriber) and secondly the N:1 (also known as VLAN per service) mode. 4.1. VLAN per subscriber The 1:1 approach, shown in Figure 2, puts the subscriber at the center of the con- sideration. It provides simple connectivity to the IP network for delivery of multiple services. Introducing a new service does not require a new VLAN configuration. This option uses stacked VLANs due to scalability concerns. The inner VLAN tag identifies the subscriber’s port at the DSLAM. The outer VLAN tag identifies the DSLAM, and can be added by the DSLAM or by the next aggregation switch. In most cases, this approach is used with a single edge model, i.e. all services are provided by a single IP edge router, the broadband service router (BSR). Besides the subscriber VLANs, a special multicast VLAN is used. The multicast VLAN is a service VLAN, which is single-tagged only. The multicast VLAN is used for distributing the multicast traffic from the IP edge to the DSLAMs, and for trans- porting IGMP messages between the multicast router (M- or E-series) and the multicast hosts (i.e. the STBs). This multicast VLAN can be terminated at the BSR, but as an option could also be terminated at any other IP edge router. Both the DSLAM and the aggregation switches support IGMP for a dynamic optimization of the multicast distribution. xDSL IP DSLAM 1 2 3 4 K Port 3 1 1 VLAN DSLAM-x DSLAM-x 3 3 Ethernet VLAN Ethernet VLAN TV K K xDSL IP DSLAM switch switch BSR 1 1 1 2 Port 3 DSLAM-y DSLAM-y 3 3 3 4 VLAN VLAN VLAN L L L TV 1 1 3 DSLAM-z 3 DSLAM-z Port 3 VLAN VLAN VLAN M M xDSL IP DSLAM TV TV TV 1 2 3 4 M Port- tag IPTV headend Figure 2: Reference architecture for VLAN per subscriber
  10. 10. 10/20 High-quality and resilient IPTV multicast architecture – Technical White Paper IP DSLAM HSI 1 HSI-X 2 VoD/TV 3 VoD-X VoIP 4 TV K IP edge VoIP-X TV Ethernet Ethernet IP DSLAM switch switch BRAS 1 HSI-Y HSI 2 VoD-Y GE/10GE HSI- VoD/TV 3 VoIP 4 TV X,Y,Z L VoIP-Y IP edge VoD- X,Y,Z IP DSLAM HSI-Z IP edge TV 1 HSI headend 2 VoD-Z VoD/TV 3 VoIP- 4 TV VoIP M X,Y,Z VoIP-Z Figure 3: Reference architecture for VLAN per service 4.2. VLAN per service The alternative is based on service-specific VLANs in the aggregation network. The basic goal is to optimize the delivery of different services through the ac- cess and aggregation network and to use optimized edge routers to the IP core (multiple edge). It includes not only the multicast VLAN, which in Figure 2 is considered as always being a service VLAN, but also specific VLANs for data services or voice services. This approach is shown in Figure 3. In most cases, this is linked to the usage of service-specific PVCs or VLANs on the DSL link. The residential gateway must forward the Ethernet frames on the appropriate PVC or VLAN service. The two described options are the basic models. It is, of course, possible to mix both approaches in one network, e.g. having all service VLANs connected to a single edge router, or having multiple C-VLANs per subscriber connected to service-specific edge routers. 4.3. Layer 2 control VLAN per subscriber and VLAN per service can both be enhanced by the use of a Layer 2 control mechanism. The DSL Forum’s TR-059 defined queuing and scheduling mechanisms to avoid congestion in the access network while dealing with multiple flows with distinct QoS requirements, commonly called hierarchical scheduling. A mandatory requirement for hierarchical scheduling is that the BSR must have knowledge about the access network, the various links being used, and their respective rates.
  11. 11. 11/20 However, some of this information is dynamic in nature (e.g. DSL sync rate) and cannot come from a provisioning or inventory management OSS system. Instead, a Layer 2 control mechanism can provide this dynamic information from the DSLAM to the BSR when a DSL line resynchronizes. This infor- mation is available in the BSR independent of any active user session, un- like other proposed mechanisms using an extended DHCP relay agent or PPPoE intermediate agent. In addition to QoS support, Layer 2 control can also be used to close the functional gap for end-to-end connectivity tests between the BSR and the CPE. Traditionally, ATM’s F4/F5 loopback tests have been used for oper- ation and troubleshooting. Since Ethernet is getting a more important role as a Layer aggregation network, it must test and troubleshoot connectivity in the case of a mixed Ethernet and ATM access network (including the local loop). While Ethernet OAM standards (e.g. IEEE 802.1ag) are still work in progress (especially in a mixed Ethernet and ATM scenario), Layer 2 control has successfully been used to close this gap and to test the connectivity between the BSR and the CPE including the local loop. 4.4. Multicast replication Multicast replication is one of the essential components in efficient delivery of IPTV broadcast services. Depending on the network topology and ser- vice subscription rates, generally all network elements including DSLAMs, aggregation switches and IP edge routers perform multicast replication, as it is shown in Figure 4. In VDSL networks where the short range of VDSL results in low number of subscribers per DSLAM, the last multicast replica- tion point can also be the first aggregation switch instead of the DSLAM itself. xDSL IP DSLAM Multicast 1 replication 2 3 4 K Multicast and shaping/subscr. TV Ethernet Ethernet xDSL IP DSLAM switch switch 1 2 3 4 L BSR xDSL IP DSLAM 1 2 3 L2C (RAM, OAM) 4 M IPTV headend Figure 4: Layer 2 control and multicast replication
  12. 12. 12/20 High-quality and resilient IPTV multicast architecture – Technical White Paper 5. Core network design concepts Optimized for scale. This paper addresses three different mechanisms for distributing multicast traffic throughout the IP backbone. Two of them, PIM SSM and PIM SM, are based on IGP only, and the third, P2MP LSPs, are based on the MPLS multicast distribution concept. 5.1. PIM SSM The PIM SSM mode, shown in Figure 5, requires the edge router to know about the IP address S of the multicast source providing the multicast group G. The router will issue a PIM Join request directly towards the corresponding source. This Join request will be forwarded along the shortest path (in terms of the IGP) to the multicast source until it reaches a router which is already aware of the multi- cast group G. The existing SPT is then extended down to the requesting edge router. In general, there are two ways the edge router can determine the IP ad- dress S of the corresponding multicast source: a) The receiver uses IGMPv3 to signal its request for a certain multicast group address G and explicitly includes the multicast source address S in every IGMP Join message (IGMP v1/2 does not provide that functionality). b) By configuration, the edge router knows about a mapping G > S. Whenever either an IGMPv1/2 Join message or an IGMPv3 Join message without ex- plicitly specifying the IP address of the multicast source occurs, the edge router uses this mapping to identify the right multicast source for multicast group address G. Static SSM mapping Multicast (IMGPv1/2 > IGMPv3) Active traffic for Group G Multicast Receiver 3 Receiver DR Receiver DR Standby IGMP v1/2 Multicast Receiver 2 Receiver DR Multicast Receiver 1 Figure 5: PIM SSM scenario with static SSM mapping at the edge
  13. 13. 13/20 Multicast Register messages Active traffic for Group G Multicast Receiver 3 SPTs for (S,G) Receiver DR Receiver DR Standby Multicast Receiver 2 Receiver DR RPT for (*,G) but not for (S,G) Multicast Receiver 1 Figure 6: PIM SM scenario 5.2. PIM SM In this PIM mode, shown in Figure 6, the edge router does not need to know which multicast source can provide the multicast data for a certain group address G. The routers do need to know whom to ask to get the information about the multicast source for G: the instance to ask is another router called “Rendezvous Point” (RP). This kind of multicast distribution is used in the IP backbone when the range of po- tential multicast group addresses is quite large, the multicast source IP addresses are not really known from the beginning, or the multicast source IP addresses are subject to change quite often during the time. There are a couple of options for how to choose an RP. The preferred option is the so-called “Anycast RP.” In this option, each potential RP router is equipped with two loopback addresses, a primary and a secondary one. The secondary loopback address does not need to be unique throughout the network. The Anycast RP concept is to define the RP via the secondary IP address and assure that each such secondary IP address occurs at least twice in the network. Any time an edge router has to contact the RP, it will automatically be led to the nearest router (in terms of IGP metrics) with a cer- tain secondary loopback address. This assures that the time in which a new multi- cast group cannot be joined when an RP fails is the time the IGP needs to converge. Moreover, RP load balancing is achieved automatically.
  14. 14. 14/20 High-quality and resilient IPTV multicast architecture – Technical White Paper Multicast traffic for Active Group G is mapped into P2MP LSF Multicast Receiver 3 Receiver DR Receiver DR Standby Multicast Receiver 2 Multicast traffic Receiver DR for Group G P2MP LSP Multicast Receiver 1 Figure 7: Point-to-Multipoint LSP scenario. 5.3. P2MP LSPs The MPLS solution is less dynamic than the PIM solutions. The basic assumption is that the edge routers always have active multicast receivers attached to them. All these edge routers are LSP egress routers of certain P2MP LSPs. On the other hand, the ingress point of each P2MP LSP is a border router which connects directly to a multicast source (in most cases via a redundant Layer 2 network). At this in- gress point the received multicast data traffic from the multicast source is by con- figuration mapped into the corresponding P2MP LSPs. When the multicast data traffic is sent by the source, then the multicast traffic is switched along the P2MP LSP and replicated wherever necessary. At each P2MP LSP egress point, the multicast data traffic is now available and will be sent further down to the subscriber when a PIM or IGMP request is received. Since the P2MP LSPs are set up via RSVP, the full Traffic Engineering capabilities are available for P2MP LSPs when the LSP is set up similarly to the common point to point LSPs. During operation Fast Reroute can also be used to protect against failures.
  15. 15. 15/17 15/20 High Quality and Resilient IPTV Multicast Architecture – Technical White Paper 6. Conclusion 5.4. Summary PIM SM is recommended in the IP backbone when the range of potential multicast group addresses is quite large, the multicast source IP addresses are not really known from the beginning, or the multicast source IP addresses are subject to change quite often during the time. Therefore the typical multicast applications to use PIM SM are voice, video conferencing (if realized by multicast at all), or gam- ing. The ResIP recommendation is to use PIM SSM or P2MP LSPs for IPTV services. Combining the multicast features with an intelligent implementation in the equip- ment (i.e. routers and switches), a subsecond failover time can be achieved for physical and also Layer 3 failures. A number of failure types need to be looked at. This includes e.g. a link failure in the core, a failure of a router, or a failure of the multicast source itself. A concept has been developed to assure a subsecond fail- over time for all these failure cases (this includes the failure detection as well as the failure recovery).
  16. 16. 16/20 High-quality and resilient IPTV multicast architecture – Technical White Paper 6. Conclusion The Nokia Siemens Networks and Juniper Networks ResIP Certified IPTV solution has been certified in the ResIP Lab. It is based on mechanisms drawn from the Nokia Siemens Networks SURPASS Home Entertainment solution, the Nokia Siemens Networks SURPASS Carrier Ethernet, the Juniper Networks M- and T-series routing platform, and the Juniper Networks E-series Broadband Services Routers. The solution reduces operational costs through a well-designed sub- scriber management using Zero Touch Provisioning. Engineering rules and design User expectations of high-quality services delivered over a broadband network will guidelines are available for be no different from what is expected of today’s legacy video broadcast systems. Continuous service availability will be taken for granted, and QoS should not be service providers who want to compromised, even when a failure occurs in the network. Video services put strict take advantage of the ResIP demands on packet loss and delay; to some extent, these requirements are even engineering excellence. higher than for voice. Nokia Siemens Networks and Juniper Networks have developed a QoS design that identifies various traffic types, and manages each according to its specific requirements across multiple links and network elements. The Nokia Siemens Networks and Juniper Networks ResIP Certified IPTV solution also addresses critical aspects of network security. The solution applies common security policies across the entire network to secure voice and video services from network-based attacks and to protect against DoS attacks. Nokia Siemens Networks SURPASS Integration Solutions offers tailor-made support for the effective and SURPASS Integration Solutions fast integration of new products and applications in today’s complex and hetero- geneous multi-vendor networks, and allows network operators to participate in the support customers for fast and ResIP outcomes. riskless integration of new ser- vices on multi-vendor networks. Our approach is based on an in-depth understanding of your needs, priorities, and requirements, thus enabling us to develop an optimized solution. We analyze your business requirements and customize products and applications to your specific needs. Prior to implementing the solution, we perform comprehensive tests such as performance and conformance testing, interoperability checks, and technical verification in a reference system to ensure proven end-to-end functionality. Integration projects carried out by Nokia Siemens Networks result in faster revenue generation, while keeping expenditure to a minimum by delivering the right quality, at the right cost, and at the right time, and should you wish to see how our standard solution would meet your demands, we can carry out a trial on site or at one of our Nokia Siemens Networks Integration Laboratories. Learn more! For more information about SURPASS Carrier-Grade IP Solutions and the ResIP PoC Lab visit www.resip.net. For more about Juniper Networks routers, visit www.juniper.net.
  17. 17. 17/20 7. About Nokia Siemens Networks and Juniper Networks Nokia Siemens Networks is: The solution-based expertise and experience Nokia Siemens Networks has gained in worldwide installations of voice and packet networks has resulted in a range of unrivalled offerings. Nokia Siemens Networks is a strong and reliable • A Juniper Networks Author- partner that offers a stable relationship for conducting successful business in the ized Education Center highly competitive carrier market. Our experience and know-how can also be to enable operators’ engi- demonstrated with regard to our customer base, strategic partners, and in the neers; availability of more than one hundred certified IP experts worldwide. This global presence and a strong service organization support carriers 24 hours a day, 7 days a week. • An official partner in the Juniper Networks Content Nokia Siemens Networks works together with preferred partner companies, all at and Applications Alliance the leading edge in their segment, including Juniper Networks, with its leading IP product portfolio for BSR solutions, edge and core networks, and security to develop revenue genera- technologies. ting solutions for operators; Juniper Networks has been helping its customers build the largest, most reliable, • The first Juniper partner to and most profitable IP networks in the world for nearly ten years. This blend of world-class offerings and partnerships and our global presence and expertise offer have achieved the status the best possible guarantee that Nokia Siemens Networks Next Generation of Juniper Networks Author- Network solutions are truly carrier-grade. ized Global Support Pro- vider, which offers the full Nokia Siemens Networks and Juniper Networks have collaborated to develop an end-to-end IP architecture for next generation networks that supports voice, video, range of support services and data solutions as SURPASS Home Entertainment and SURPASS from installation to optimi- VoIP@Home. zation worldwide. This architecture enables service providers to offer an assured experience based on customer and application requirements. ResIP Certified Solutions that have already undergone stringent testing are available to service pro- viders for immediate deployment.
  18. 18. 18/20 High-quality and resilient IPTV multicast architecture – Technical White Paper Nokia Siemens Networks and Juniper Networks are working together to solve the toughest challenges service providers are currently facing. ResIP is designed to help service providers through these tough times of decreasing voice revenue and declining customer base. It includes a well-defined program to develop, test, and certify all technology for the next generation architecture and solutions. The result- ing benefits to service providers is a fully tested and complete network architecture that allow multiple certified solutions to be deployed for new revenue opportunities. • Nokia Siemens Networks is one of the largest players in the global telecom- munications industry. Nokia Siemens Networks is the only provider in the market that offers its customers a full-range portfolio, from devices for end users to com- plex network infrastructures for enterprises and carriers, as well as related ser- vices. Nokia Siemens Networks Communications is the world’s innovation leader in convergent technologies, products, and services for wireless, fixed, and enter- prise networks. • Juniper Networks is the leader in enabling secure and assured communications over a single IP network. The company’s purpose-built, high-performance IP platforms enable customers to support many different services and applications at scale. Service providers, enterprises, governments, and research and educa- tion institutions worldwide rely on Juniper Networks to deliver products for build- ing networks that are tailored to the specific needs of their users, services, and applications. Juniper Networks’ portfolio of proven networking and security so- lutions supports the complex scale, security, and performance requirements of the world’s most demanding networks.
  19. 19. 19/20 8. Abbreviations ATM Asynchronous Transfer Mode MPLS-TE MPLS Traffic Engineering BSR Broadband Services Router OAM Operation and Maintenance C-VLAN Customer VLAN OAM&P Operation and Maintenance & CPE Customer Premises Equipment Provisioning DHCP Dynamic Host Configuration Protocol PIM-SM Protocol Independent Multicast DR Designated Router Sparse Mode DSL Digital Subscriber Line PIM-SSM Protocol Independent Multicast DSLAM Digital Subscriber Line Access Source-Specific Mode Multiplexer PoC Proof-of-Concept EPG Electronic Program Guide PPP Point-to-Point Protocol ERP Ethernet Ring Protection PPPoE PPP over Ethernet FEC Forward Error Correction P2MP Point-to-Multipoint FTTH Fiber to the Home PVC Permanent Virtual Circuit GOP Group of Pictures QoS Quality of Service HDTV High-Definition Television RAM Rate Adaptive Mode HSI High-Speed Internet ResIP Resilient IP IEEE Institute of Electrical and RP Rendevouz Point Electronics Engineers RSTP Rapid Spanning Tree Protocol IGMP Internet Group Management Protocol RSVP Resource Reservation Protocol IGP Interior Gateway Protocol S-VLAN Service VLAN IP Internet Protocol SDTV Standard-Definition Television IPoE Internet Protocol over Ethernet SPT Shortest Path First IPTV Internet Protocol Television STB Set-Top Box IS-IS Intermediate System to Intermediate STP Spanning Tree Protocol System VLAN Virtual LAN L2C Layer 2 Control LSP Label Switched Path Mbit/s Megabit per Second MPEG Motion Pictures Expert Group MPLS Multiprotocol Label Switching
  20. 20. Nokia Siemens Networks Corporation P.O. Box 1 02022 Nokia Siemens Networks Finland Visiting address: Karaportti 3, Espoo, Finland Switchboard +358-71-400-4000 (Finland) Switchboard +49-89-515-901 (Germany) The contents of this document are copyright © 2008 Nokia Siemens Networks. All rights reserved. A license is hereby granted to download and print a copy of this document for personal use only. No other license to any other intellectual prop- erty rights is granted herein. Unless expressly permitted herein, reproduction, transfer, distribution, or storage of part, or all, of the contents in any form without the prior written permission of Nokia Siemens Networks is prohibited. The content of this document is provided “AS IS”, without warranties of any kind with regards to its accuracy or reliability, and specifically excluding all implied warranties, for exam- ple of merchantability, fitness for purpose, title, and non-infringement. In no event shall Nokia Siemens Networks be liable for any special, indirect, or consequential dam- ages, or any damages whatsoever resulting from loss of use, data, or profits, arising out of, or in connection with, the use of the document. Nokia Siemens Networks reserves the right to revise the document or withdraw it at any time without prior notice. Nokia Siemens Networks and the Wave logo are registered trademarks of Nokia Siemens Networks. Nokia Siemens Networks product names are either trademarks or registered trademarks of Nokia Siemens Networks. Other product and company names mentioned herein may be trademarks or trade names of their respective owners. Order No. C401-00114-WP-200803-1-EN www.nokiasiemensnetworks.com