Sei sulla pagina 1di 8

White Paper

Multicast Call Admission Control


Ensuring Bandwidth Availability in Broadband Networks

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 USA 408.745.2000 1.888 JUNIPER www.juniper.net

Part Number: 200250-001 Nov 2007

Multicast Call Admission Control

Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Implementing Multicast CAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Multicast CAC with IGMP Passthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Access Node Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Multicast CAC with IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Multicast CAC with IGMP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Juniper Networks Support for Multicast CAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Copyright 2007, Juniper Networks, Inc.

Multicast Call Admission Control

Executive Summary
This paper describes multicast call admission control (CAC), which ensures that requests to view additional channels do not affect the IPTV service quality for existing viewers . It is intended for business or technical managers who are seeking to increase average revenue per subscriber (ARPU) . The amount of bandwidth consumed by IPTV is increasing dramatically as the number of televisions per household grows, IPTV service penetration increases, more high definition channels are offered, and video on demand (VOD) usage rises . As a result, it is important that the network verify that sufficient bandwidth is available to support a new video request before allowing a new connection to be established . Juniper Networks support for multicast call admission control (CAC) prevents subscribers from requesting additional channels if the network cannot successfully deliver them, ensuring high service quality for existing viewers . In addition to checking bandwidth available to each subscriber, Junipers multicast CAC capability validates that there is sufficient bandwidth to forward additional channels to the access node (such as a DSLAM), which has become an additional bottleneck as more content such as VoD is sent to individual subscribers rather than being multicast to many viewers .

Introduction
Bandwidth is booming . Even in the last mile to the home, new technologies such as Gigabit Passive Optical Networks (GPON) and Ethernet in the First Mile (EFM) hold the promise of delivering all services without concern about whether bandwidth is available . Unfortunately, this vision is not yet a reality . DSL remains the predominant access method, with costly fiber buildouts years away . Compounding this, even fiber does not offer unlimited bandwidth . For example, a fully loaded GPON system provides less than 20 Mbps per subscriber . In addition, relieving the last mile bottleneck simply moves the bottleneck further back in the network . Finally, operators often limit bandwidth to subscribers, offering tiered bandwidth services to drive revenue . This means that bandwidth will continue to be a design consideration into the foreseeable future . Broadband networks must therefore understand what applications require dedicated bandwidth, and must be able to prevent applications from being started if sufficient bandwidth is not available . One method of dealing with this bottleneck is to allocate bandwidth to each service . Figure 1 shows a simple example of how bandwidth can be carved-out to support different service packages . This requires that the broadband operator pre-define each bundle . To minimize the associated burden, a limited number of packages are typically available . The bandwidth that can be consumed by video is controlled by restricting the number and type of set-top boxes that the operator provides to the subscriber .

Voice (128 Kbps)

Voice (128 Kbps)

Voice (128 Kbps)

Data (2 Mbps)

Video (8 Mbps)

Data (2 Mbps)

Video (4 Mbps) Data (6 Mbps)

Video (4 Mbps)

Unused

One HD-capable STB (6 Mbps) One SD-only STB (2 Mbps) Internet Access @ 2 Mbps

Two SD-capable STBs (4 Mbps) Internet Access @ 2 Mbps

Two SD-capable STBs (4Mbps) Internet Access @ 6 Mbps

Figure 1: Sample Service Packages Using Pre-Allocated Bandwidth


Copyright 2007, Juniper Networks, Inc.

Multicast Call Admission Control This is acceptable for simple deployments, but limits the revenue opportunity in more complex environments such as: HDTV on any TV: This allows the subscriber to view HDTV on any capable TV in the home, but only allow the subscriber to receive one HDTV stream due to bandwidth . Having a second viewer tune to an HDTV channel will result in degraded quality for both streams . Same service, different bandwidth: Channels (of same quality, e .g ., SD) being sent with differing bandwidth, such as when migrating from MPEG-2 to MPEG-4 . The bandwidth saved when using MPEG-4 could be used for other purposes, such as gaming . Homes with many TVs: Some homes have four or more TVs, although all are not being viewed at the same time . Limiting the number of televisions limits the places within the home where TV can be viewed . Any service to any device: Allowing IPTV to be viewed on PCs and gaming consoles, or allowing the STB to access the Internet, requires breaking the mapping of clients to services . Committing bandwidth to the STB-based video service may mean that there is insufficient bandwidth for watching TV on the PC, even if nobody is viewing the STB-based television service . Offerings that support many services: As new services that require committed bandwidth including gaming and IP videoare developed, they cannot be offered since it is impossible to continually partition the bandwidth to each subscriber . A better approach is to allow the subscriber to request any service from any device, and allow the network to dynamically determine whether the request can be honored . One piece of this is multicast CAC, which prevents IPTV content from being sent to the subscriber if doing so would affect the viewing quality on other TVs . It does this by verifying that sufficient bandwidth is available to support the additional stream . Multicast CAC it is a critical piece of the network solution . It is used in two ways: During normal day-to-day operation, it restricts each subscriber to the limits of the service plan . This includes avoiding over-subscription on the access link by limiting the amount of IP video that can be sent to each subscriber . During times of network failures or usage growth, it prevents subscribers from starting new sessions that could impact existing sessions . For example, it can block a connection if this would over-commit the connection from the core network to the Access Node (AN) . Implementing multicast CAC requires two key functions: The network must approve each subscribers request to view a new TV channel After approval, the requested stream must be forwarded to the subscriber

What is an Access Node? Access Node is a generic term for a device that aggregates traffic from multiple subscribers. This includes DSLAMs (xDSL), OLTs (FTTH), CMTSs (cable) and other equipment. Equivalent terms include Multi-Service Access Node (MSAN) and Broadband Digital Loop Carrier (BBDLC).

Copyright 2007, Juniper Networks, Inc.

Multicast Call Admission Control

Implementing Multicast CAC


Multicast CAC is implemented by Junipers Broadband Services Routers (BSR), which is an extension of the traditional Broadband Remote Access Server (BRAS) deployed in many broadband networks . This device determines whether the subscribers request should be fulfilled, and forwards a copy of the stream if appropriate . However, the level of functionality depends upon how the AN responds to incoming Internet Group Management Protocol (IGMP) channel change requests . There are three common IGMP implementations in ANs: IGMP Passthrough, IGMP Proxy, and IGMP Snooping .

Multicast CAC with IGMP Passthrough


When using IGMP Passthrough, the AN forwards the IGMP request to the BSR without taking any action . IGMP proxy, or snooping, is not enabled in the AN . As a result, the BSR determines whether the request can be supported, and if so it forwards the multicast group out the subscribers interface . Since both unicast and multicast traffic is sent to each subscriber directly from the BSR, it can manage the bandwidth available to all applications to ensure successful traffic delivery and deny requests to view multicast traffic if there is insufficient bandwidth . The BSR checks several points to ensure that bandwidth is available: Bandwidth available to each subscriber Bandwidth available to each access node Bandwidth available to each aggregation switch Figure 2 illustrates how the BSR performs this calculation for the subscriber, and similar checks are done for the other potential congestion points . If there is insufficient bandwidth available at any of these points, then the connection is disallowed .
Bandwidth per channel Group 224.1.1.2 224.1.12.101 Subscriber
AN

Bandwidth 2 (SD) 6 (HD) 6 (HD)

DSLAM
Switc

Port

224.1.12.104

BSR

10 Mbps

1 Gbps

1 Gbps

Bandwidth (per subscriber) Sub 10.10.1.3 Total 10 Commit 0 Request 2 Total 2 Approved

IGMP (join 224.1.1.2)

IGMP (join 224.1.12.101)

Sub 10.10.1.3

Total 10

Commit 2

Request 6

Total 8

Approved

IGMP (join 224.1.12.104) Denial Message

Sub 10.10.1.3

Total 10

Commit 8

Request 6

Total 14 Denied

Figure 2: BSR CAC (per subscriber)

Copyright 2007, Juniper Networks, Inc.

Multicast Call Admission Control Implementing this solution requires that: The BSR must know the bandwidth consumed by each IPTV channel . This can be configured directly into the BSR, or it can dynamically learn the bandwidth required by each multicast group . The AN must pass all IGMP channel change requests to the BSR without modification . This allows the BSR to determine whether there is sufficient bandwidth available to honor the request . The BSR must learn the bandwidth available to each subscriber . This is configured in the BSR, or this information can be forwarded by the AN using Access Node Control Protocol (see below) .

Access Node Control Protocol


Access Nodes test the connected access lines to determine the train rate for, or bandwidth available to, each subscriber . When using BSR-based multicast CAC, the BSR must know this information so that it can forward traffic at the appropriate rate to each subscriber . This is often manually configured into the BSR . An emerging standard, Access Node Control Protocol (ANCP), allows the AN to forward train rate information to the BSR . This is depicted in Figure 3 . ANCP defines extensions to General Switch Management Protocol, which is defined in RFC 3292 . ANCP is being defined by the IETF, and is already implemented in some BSRs and ANs . It is also called Layer 2 Control (L2C) mechanism .
Last Mile Choke Points 10 Mbps 12 Mbps
AN

BSR

15 Mbps

ANCP (Sub. A = 10 Mbps) ANCP (Sub. B = 12 Mbps) ANCP (Sub. C = 15 Mbps)

AN informs BSR of bandwidth to each subscriber

Figure 3: ANCP The challenge to using IGMP passthrough is that, if the same content is being viewed by multiple subscribers, it will be sent to the AN multiple times . If bandwidth to the AN is limited, this is unacceptable . However, this solution requires the same bandwidth as a network delivering mostly VOD and Internet-based video . This is acceptable as more and more ANs are connected upstream using gigabit Ethernet .

Multicast CAC with IGMP Snooping


When implementing IGMP transparent snooping, the AN replicates multicast traffic upon request and also forwards the IGMP request to the BSR . Since the AN acts independently, the BSR cannot prevent the last mile link from initially getting over-subscribed . However, since each IGMP request is forwarded upstream, the BSR can begin throttling unicast, best-efforts traffic once the request reaches the BSR . In this case, the AN may have enough memory to queue traffic to each subscriber and prevent any packets from being dropped .

Copyright 2007, Juniper Networks, Inc.

Multicast Call Admission Control

Multicast CAC with IGMP Proxy


When implementing IGMP proxy in the AN, it replicates multicast traffic upon request . Unlike the other scenarios, however, the IGMP request may not be forwarded to the BSR . Since the BSR will not throttle best-efforts traffic, there is a greater chance that the AN will run out of buffer memory and drop packets .

Juniper Networks Support for Multicast CAC


Juniper Networks E-series Broadband Services Routing Platforms support multicast CAC to ensure high quality delivery of multicast IPTV and other services . The routers provide multicast CAC per subscriber (VLAN or ATM VCI), per AN (stacked VLAN or VPI), and per aggregation switch (BSR port) . In addition, Juniper E-series support additional related capabilities, including: Dynamic bandwidth learning: The BSR can dynamically measure and learn the amount of bandwidth required by each channel . This is a critical function as new channels are added or existing channels are delivered at new speeds, such as to support PC clients or using newer techniques such as MPEG4 . Operator-imposed limits: The BSR can query the subscriber management system to provide additional operator-imposed limits, such as restricting the number of streams which can be delivered to each subscriber . ANCP: The BSR communicates with the AN to learn the bandwidth available to each subscriber .

Conclusion
Multicast CAC requires tracking network usage, and allowing new applications to join the network only if resources are available to ensure successful service delivery . This is a critical function for ensuring service delivery . It can be integrated into normal daily operation, but also protects the network and subscribers from network growth and failures . Juniper E-series routersincluding the E320, E120 and ERX1440provide these capabilities and are used by many of the worlds largest IPTV providers . For further information on these and other design considerations, contact your Juniper Networks sales representative, visit us at http://www .juniper .net/solutions/service_provider/multiplay/, or call us at 866-298-6428 (USA, Canada and Mexico) or 978-589-0500 (outside USA) .

About Juniper Networks


Juniper Networks, Inc . is the leader in high-performance networking . Juniper offers a high-performance network infrastructure that creates a responsive and trusted environment or accelerating the deployment of services and applications over a single network . This fuels high-performance businesses . Additional information can be found at www .juniper .net .

Copyright 2007, Juniper Networks, Inc.

Multicast Call Admission Control

CORPORATE HEADQUARTERS AND SALES HEADQUARTERS FOR NORTH AND SOUTH AMERICA Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA Phone: 888.JUNIPER (888.586.4737) or 408.745.2000 Fax: 408.745.2100 www.juniper.net

EUROPE, MIDDLE EAST, AFRICA REGIONAL SALES HEADQUARTERS Juniper Networks (UK) Limited Building 1 Aviator Park Station Road Addlestone Surrey, KT15 2PG, U.K. Phone: 44.(0).1372.385500 Fax: 44.(0).1372.385501

EAST COAST OFFICE Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886-3146 USA Phone: 978.589.5800 Fax: 978.589.0800

ASIA PACIFIC REGIONAL SALES HEADQUARTERS Juniper Networks (Hong Kong) Ltd. 26/F, Cityplaza One 1111 Kings Road Taikoo Shing, Hong Kong Phone: 852.2332.3636 Fax: 852.2574.7803

Copyright 2007 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JUNOS and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

To purchase Juniper Networks solutions, please contact your Juniper Networks sales representative at 1-866-298-6428 or authorized reseller.