Your SlideShare is downloading. ×
Bridged and routed options for multicast video delivery
Bridged and routed options for multicast video delivery
Bridged and routed options for multicast video delivery
Bridged and routed options for multicast video delivery
Bridged and routed options for multicast video delivery
Bridged and routed options for multicast video delivery
Bridged and routed options for multicast video delivery
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Bridged and routed options for multicast video delivery


Published on

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. w h i t e pa p e r Bridged and routed options for multicast video delivery Introduction Telco carriers are given As a relatively new technology and service, IPTV still lacks a lot of quan- a variety of “options” for titative metrics for measuring performance. This is, in part, because most IPTV deployments are still small in total numbers of subscribers, lacking the implementing IPTV with scaling necessary to adequately measure performance. As a result, a carrier no reference point to the faced with architecting their IPTV system and network has little or no empiri- cal data to guide them to the best approach. And, unlike the DOCSIS stan- specification and design dards for cable systems, Telco carriers are given a variety of ‘options’ within yielding the highest the scope of IP standards for implementing IPTV with no specific reference point to the functional specification and design yielding the highest level or performance. performance. This gray area can often times be capitalized on by equipment vendors to support and promote designs and architectures that allow them to sell the most equipment, rather than best serve the needs of the IPTV service provider. From a technology perspective, IPTV appears a complex system and archi- tecture to implement. It requires a digital IP head end system, middleware, conditional access, on demand streaming video servers, access systems, switches and routers along with IP set tops and terminations end points. It is the integration and interoperation of all these elements that constitutes IPTV service deliver, along with other sub-system such as Emergency Alert, Caller ID/TV and ad insertion. From the perspective of the paying subscriber, though, the quality and performance factors for television viewing boil down to a few basic and simple factors. First, how good is the quality of the picture? Second, how fast do channels change and can I always get the channel I want? Third, how reliable is the service availability? And fourth, how much content or programming do I get? The technical bells and whistles behind the service matter like to the end customer, and their choice to maintain the service or discontinue it will usually most often be predicated on one of these four factors. For the foreseeable future, broadcast television programming is the core service for television viewing. Interactive, on demand ‘push’ based unicast video is growing in use and importance, but unlikely to change the service model near term to where live broadcast television is replaced. Therefore, Z h one Technologies
  • 2. w h i t e pa p e r Bridged and routed options for multicast video delivery multicast video is the main feature has customers using both methods. IGMP, however, is not an ideal of IPTV (and cable) services, with Although the choice is up to each protocol for broadcast video and most operators today offering an customer, the customer needs to channel changing since its purpose average of 150 program channels, understand the performance criteria was not originally intended for this many as high as 200. In IPTV, and impacts of each options in use, but rather adopted for IPTV broadcast video is controlled and order to make the right decision, applications. Its main weakness is delivered using Internet Group and this paper is written to offer that it is a stateless protocol with Multicast Protocol, or IGMP. IGMP some comparisons functionally no means of authentication. The is also responsible for channel between using bridged and rout- router upstream of hosts has no changing with IPTV. The head end ing for IGMP, along with a clear idea of who sends an IGMP join content processor, middleware, understanding of performance as or leave nor does it keep track conditional access system and set networks and subscribers scale. of that status of joins and leaves tops all use IGMP as the trigger for Unlike a number of vendors who being passed by hosts. This poses IP video delivery. IGMP, therefore, support one method, Zhone can several problems for IPTV. First, has the biggest single influence offer a neutral assessment since with no ‘policing’ of joins and as well as impact on IPTV service the ultimate choice rests with the leaves, it is possible to have joins performance and quality. customer since both methods are and leaves get out of balance due supported. to dropped packets and errors. It Within the IP standards adopted for is not uncommon to have a leave IPTV, IGMP may be used in either a IGMP explained message dropped and channels bridged or routed mode for multi- Internet Group Multicast Protocol, (multicast streams) remain active cast of video streams at the access or IGMP, is the method defined in although no longer in use. Imagine end. In a bridged mode, the access standards for broadcast TV chan- a popular channel like ESPN being node performs a Layer 2 snooping nel changing mimicking a cable multicast to a number of subscrib- function, allowing a device, gener- system environment in simple form. ers. Several subscribers decide to ally the network router in the core IGMP is not a new standard, and change channels and the leave network, to perform the Layer 3 is a protocol that has been around request is dropped between the IGMP multicast control and set up/ for some time for use with Internet set top and router. ESPN remains tear down of channels. In a Routed data. IGMP is normally software stream even though no longer being access network, the access node feature set used in a core router, watched. Over a period of time, has its own IGMP proxy function designed to allow a central device rather than being a single instance built-in. Therefore, multicast control to send simultaneous sessions to of ESPN being multicast, there are and channel changing occurs at the subtending hosts within a speci- a number of separate instances access node, and is distributed fied multicast group. Multicast is being streamed concurrently. Joins across the network. Both methods performed through a simple join are less of an issue, when they are are supported fully in standards, or leave message, notifying the occasionally dropped it results in a and both accomplish the same router a host wants to receive a channel change not occurring and functions, the difference being multicast or drop from a multicast. the subscriber having to push the where in the network the intelli- As it applies to broadcast video, remote control button again. gence and control exists. a set top, via the remote, sends a join when a channel request is The second issue is security of Zhone, as part of its open standards made and a leave when the channel content. IGMP allows no means platform philosophy, supports both is left. This constitutes a channel of correlating a join or leave to a bridged and routed IGMP multicast change. device or subscriber and there- in its MALC access platform, and fore cannot control who accesses Z h one t echnologies
  • 3. w h i t e pa p e r Bridged and routed options for multicast video delivery content itself. Therefore, studios or ease of provisioning may direct a cases, although larger carriers serving concerned with digital piracy of decision, with scaling and performance more metropolitan markets will most content fear IPTV using IGMP can an assumed constant until the prob- likely be most severely impacted. allow access to digital content by hack- lems actually occur. Tracing the roots of IPTV ers and thieves. The centralized router This is not to imply that every IPTV Initially, video over phones lines was is not intended to maintain the proper service provider will have problems performed a Switched Digital Video database to match IGMP requests to or see performance issues. Many (SDV) using ATM rather than IP. Since individual devices and their authoriza- Telco’s offering IPTV today are small no IPTV standards yet adopted, suppli- tion to request multicasts. rural Telco’s who will never reach ers used a combination of cable stan- IGMP implementation is oft times a subscriber base largest enough dards and proprietary means to build characterized as “It isn’t a problem to see performance degradation. At the video system. DSM-CC was used as until it breaks, then I will know I have the same time, though, performance the channel change protocol. a problem”. For a carrier, this means cannot be quantified based strictly on IPTV has a reputation in the industry lab evaluations and field trial tests of the number of subscribers, number as being unpredictable in performance IPTV will generally work well because of set tops, or number of channels. and problematic based on some well scalability is not part of the measure- Human factors, such as the sophistica- publicized failures with early deploy- ment criteria. It may not be for several tion on the subscriber to always use ments. years, when a significant subscriber the Electronic Program Guide (EPG) base is attained, that the hidden prob- versus ‘channel surfing’ via the remote When Zhone developed its MALC lems of multicast performance come control can weigh the equation. There Broadband Loop Carrier access plat- to light. The, the carrier is forced to are so many permutations that it is form, it too recognized the value of add more equipment and re-vamp its almost impossible to develop a set delivering IPTV and controlling it network to compensate for the perfor- of metrics to determine performance at the access edge. Zhone studied mance problems. In the initial imple- affecting thresholds. Smaller operators IGMP and concluded that a combina- mentation stage, factors such as costs may experience problems in many tion of dense mode multicast with Figure 1: MALC IPTV delivery features Z h one t echnologies
  • 4. w h i t e pa p e r Bridged and routed options for multicast video delivery IGMP proxy would yield optimum for initiating all multicast. By design, MALC supporting both IGMP snooping performance for IPTV. The notion of the core Router has a lot of interfaces (bridged) and IGMP Proxy (routed), distributing multicast at the edge of (ports) and a great deal of imbedded they has the flexibility to choose they the network, and controlling it as close IP software functions, but a relatively way they wished to implement it. to the subscriber as possible seemed small processor for transactions. IGMP Therefore, MALC’s were provisioned to make sense for IGMP in IPTV just multicast, which involves a series of as routed IGMP multicast through as it was proven for DSM-CC in SDV. join and leave commands, tend to IGMP proxy, and their core router was When the IPTV standards emerged, the build rapidly during peaks, especially if bypassed for support of IPTV. One easiest path for implementation was channel surfing occurs frequently. Layer 2 switch acting as a hub was Layer 2 IGMP snooping using bridging used between the access and transport At some point, the processor filled for multicast, however, and because network for video. In the 3 years CCI and began to buffer requests, causing most access vendors implemented it has offered IPTV there has not yet a slowdown in channel changing. As that way, it was deployed. The notable been a problem in scaling service at buffers overflow occasionally (usually IPTV failures were largely caused by any node, nor any fluctuations in the in peaks), channel changing actually a combination of this implementation levels of multicast performance. stopped. With the access system and coupled with scaling of the deployment network already in place, the solution Bridged Mode multicast to a point where problems occurred. rested with the router vendor. The The advantage of bridged mode, To compare performance and scal- solution was to buy a number using IGMP snooping at Layer 2 in ability, let’s use two customers as a of smaller edge routers to co-exist the access node, is provisioning cast study. The first, a non Zhone with DSLAM’s at the central office to simplicity. It is a simple process to customer using IGMP snooping at offload processing on the core router. provision the access node to bridge Layer 2 bridging. The second (Consoli- The core router then had only the multicast as a host from the central dated Communications Incorporated), edge routers to treat as hosts for IGMP multicast Router, as the access system a Zhone MALC customer, implement- multicast, rather than every set top itself is a passive participant in the ing IPTV using IGMP proxy with Layer being the host. This solved the prob- process of multicast. As long as the 3 routing. The non Zhone customer lem, although at significant cost to Router is not overloaded with IGMP put in a number of DSLAM’s for add a number of video-specific edge requests and buffers them, channel triple play, using their core Router to routers to resolve the limitation of changing works fine and performance perform IGMP multicast at Layer 3. In the DSLAM to only perform IGMP is good. And, because the work is lab and field tests, it worked fine, as Layer 2 snooping. done in the Router, access systems do it did for almost 2 years. But, as they not require extensive intelligence for CCI, being a larger Independent approached 3000 subscribers (with multicast and therefore less software Operating Company (IOC) serving each subscriber having 2 or 3 set tops is needed in its core processing. some fairly dense markets, assumed in the home), suddenly channel chang- from the start the DSLAM would serve Many Telco’s opt for using bridged ing became unpredictable during peak a fairly large subscriber population, mode with IGMP snooping because it viewing hours. Instead of a second with as many as 500 video subscrib- requires much less complex provision- or less to change a channel, it would ers with 3 streams per subscriber ing than doing routed, and is simple to take anywhere from 3-6 seconds per per node. When CCI looked at their implement. Since core Routers already channel change. On several occasions, network, it immediately decided that exist, it allows utilization of existing channel changing just stopped entirely. centralized multicast from a core assets without extensive network re- After extensive research and inves- router was too risky, and service qual- provisioning. And many of the small tigation, the problem was traced to ity required distributing IPTV function- rural IOC’s implementing IPTV today the core router, which was the source ality to the access edge. With Zhone’s have a small enough subscriber base Z h one t echnologies
  • 5. w h i t e pa p e r Bridged and routed options for multicast video delivery Figure 2: Access Control Piracy Protection with IGMPv2 proxy to not run into performance problems functions to pass multicast to MALC’s, not paid for. And going a step further, that larger networks would. MALC or a simple Layer 2 switch is used in correlating a MAC address for each set supports bridged mode with IGMP lieu of the Router. top to the subscriber line and insur- snooping and has numerous customer ing that no device other than the one With the main disadvantage provision- implementations in this manner that authorized for that line can forward ing complexity and managing multicast have acceptable performance due to joins and leaves to the network. at each node rather than a central the size of the subscriber footprint. router, there is a number of upside In routed mode, MALC can either use Routed Mode multicast benefits. IGMP proxy allows MALC to dense or sparse mode for multicast if Using Routed mode for multicast maintain multicast in a stateful envi- bandwidth is a consideration. I dense requires more extensive and complex ronment rather than stateless as with mode, all multicast traffic will forward provisioning at the access level. bridged and snooping. Using IGMP to MALC and IGMP joins and leaves Between the Router and access node, tables, MALC performs active queries will process at the access node. In each multicast route must be defined to determine if there are excessive sparse mode, new joins will be sent and provisioned by IP address. Once leaves and assure joins and leaves are to an upstream Router if the IGMP done, the central Router no longer in balance, the end result being elimi- address for that channel is not present. handles IGMP requests, and the MALC nating unnecessary bandwidth residing This allows streaming only the broad- now becomes the multicast router for in the network. Using a provisioned cast in use. It differs from IGMP snoop- IPTV using IGMP proxy. Multicast is no Access Control List, or ACL, each ing (Layer 2) in that MALC using IGMP longer controlled from a central point, subscriber line has assigned only those Proxy and its query table to determine but controlled on a distributed basis IP multicast addresses that subscriber if a join is an active multicast or initi- at each access node at Layer 3. The is authorized to receive, therefore ate a new routed stream from upstream Router performs only simple Layer 2 eliminating the possibility of pirating in the network. channels or programs a subscriber has Z h one t echnologies
  • 6. w h i t e pa p e r Bridged and routed options for multicast video delivery Figure 3: Sparse and Dense Mode broadcast features Conclusions tion to bridged IGMP snooping. Too routing is used at the access edge with Bridged or routed modes can both many variables, such as user patterns IGMP proxy. The carrier must deter- work for IPTV multicast video services, and peak hour demands play a part, mine how much risk their deployment with traffic and volume determining thus it becomes a field performance faces based on size and scalability, which is best able to assure a quality issue that shows up when a combina- compared to the provisioning and level of service. There is no way to tion of factors cause thresholds to be operational impacts distributed IPGMP quantitatively determine how many exceeded. In every deployment, large multicast and routing causes. subscribers, how large the network or or small, IGMP multicast is optimized how many streams will cause degrada- for performance and consistency when Z h one t echnologies
  • 7. w h i t e pa p e r Bridged and routed options for multicast video delivery It is important, however, to offer carri- ers the choice to decide. By supporting either bridged or routed IGMP multi- cast in MALC, Zhone let’s the custom- er decide how it wishes to configure its network. Many access systems and vendors only support IGMP in a bridged mode with snooping since they are merely Layer 2 devices. Zhone promotes the concept of opera- tor flexibility with a minimum of future investment. MALC allows a carrier to implement IPTV services with multi- cast in a simple bridged mode and, when subscriber growth or perfor- mance requires it, re-provision multi- cast to routed in either dense or sparse mode. Adding new equipment such as edge routers to offload the central- Figure 4: IPTV edge routing functionality ized core Router is not necessary. Nor making future upgrades to set tops and middleware to support IGMP V3 for distributed multicast in the core network necessary. Re-provisioning MALC merely enables the imbedded IGMP proxy features to operate and create a fully distributed multicast network using the existing network, unlike access systems supporting only bridged multicast as Layer 2 devices that cannot migrate, and therefore force the network to change. Zhone technologies, inc. @ Zhone way 001 oakport For more information about Zhone and its products, please visit the Zhone Web site at street oakland, ca 91 or e-mail Zhone, the Zhone logo, and all Zhone product names are trademarks of Zhone technologies, inc. other brand and product names are 10..000 phone www. trademarks of their respective holders. specifications, products, and/or product names are all subject to change without notice. copyright 00 Zhone technologies, inc. all rights reserved. Br_wp_010 Z h one t echnologies