Integrating DHCP and PPP

White Paper

Juniper Networks, Inc.1194 North Mathilda AvenueSunnyvale, California 94089 USA408.745.20001.888 JUNIPERwww.juniper.net

Integrating DHCP and PPP: Delivering World Class Multiplay Services

Marc BernsteinGary SouthwellIPTV Solutions Group

Part Number: 200201-001 Sept 2006

Copyright ©2006, Juniper Networks, Inc2


Tabel of ContentsIntroduction ........................................................................................................................ 3

Requirements ...................................................................................................................... 3

Understanding TR-101 ......................................................................................................... 3

Assuring the Services ........................................................................................................... 4

Multiplay in a Multi-Edge Network ....................................................................................... 6

Dynamic Policy Management in a Multi-Edge Network ................................................ 7

IGMP Forking ............................................................................................................... 8

Summary ............................................................................................................................. 8

Contact ................................................................................................................................ 8

Copyright ©2006, Juniper Networks, Inc �


Introduction Some network equipment providers advocate using DHCP for broadband networks and predict the death of PPPoE (PPP over Ethernet). In reality, this view of the world is accepted by neither the DSL Forum nor existing broadband service providers. DHCP is required to support IP-based “broadcast” television service, but PPP provides more functionality and remains the dominant solution for unicast traffic such as a host of data services beyond Internet access including VPN, gaming, unlicensed mobile access (UMA) and VoIP services. With the move towards Video on Demand and multiplay services, many service providers are looking to leverage, not replace, their PPP-based networks.

RequirementsAs broadband service providers look to leverage their investment, there are two clear trends:

• Support for both business and residential customers using the same network. Residential and SOHO customers often share the same DSLAM today while separate “business DSL services” use a parallel infrastructure. With the move to put all services over IP, these can share a common broadband access network.

• Customized service bundles which allow each subscriber to select services from a menu of available options. These include basic service such as VoIP and IPTV, incremental services such as PVR and Video on Demand, and new services typically found in the “data stream” such as gaming, UMA, video telephony, on-line dating and karaoke on demand, home network monitoring or video on demand to the PC. It also includes more granular support of data services, for home office to larger business applications such as the ability to offer VPN support, collaborative services and data back-up.

Collectively, the ability to offer any service to any customer is referred to as multiplay services.

Offering multiplay services requires an underlying services-aware network which supports both multicast (IPTV broadcast services) and unicast (all other) services. These networks must be able to prioritize and grant appropriate bandwidth to each service as required by each subscriber. This is a significant departure from traditional solutions which statically prioritize video and voice services over all other services.

Understanding TR-101DSL Forum’s TR-101 defines the network topologies for supporting multiple services using Ethernet networks. Unlike its predecessor, TR-101 does not mandate a single topology but rather allows several variations. One new alternative is support for IP over Ethernet (IPoE) encapsulation. IPoE extends several LAN-based protocols, including DHCP, to allow use on a broadband network. Figure 1 shows one common network topology when using TR-101.

Figure 1: TR-101 Single Edge Topology

BSRDSLAM Switch

PPPoE and/or IPoE (DHCP)

RG



TR-101 does not advocate using IPoE over PPPoE, but rather allows the broadband provider to select when to use each alternative. Since DHCP was designed for use on a shared LAN, its capabilities match well with the requirements for sending common traffic to many users. Traditional broadcast television is an example of this. As a result, IPoE/DHCP is typically used for delivering IPTV traffic.

In contrast, PPPoE more closely meets the needs of point-to-point broadband connections such as data and VoIP, since it was designed to support this environment. Broadband networks have been using PPP for nearly ten years, while DHCP is a recent entrant into this market.

Existing unicast services are offered using PPP today and there is little impetus to move away from using it. In fact, many broadband service providers prefer to stick with PPPoE since it is more functional and mature than IPoE/DHCP, eliminates the need to retrain operations personnel, and lowers the risk of adding new subscribers and services.

The most common broadband implementation, therefore, is to use IPoE/DHCP to support television and other services across the broadband network to the STB, while using PPPoE to support services to other devices such as PCs and VoIP phones. Businesses receive all broadband services typically via PPP, while residential subscribers receive services via both technologies.

Assuring the ServicesEfficiently managing the bandwidth to each subscriber requires a network which can understand the needs of all applications, regardless of the encapsulation used. This means that network equipment must understand the application priority, regardless of where this information is carried in the packet. Figure 2 shows the placement of the priority fields in both PPPoE and IPoE packets.

Figure 2: Priority Markings in PPPoE and IPoE

Currently, Ethernet DSLAMs and switches cannot understand PPPoE encapsulation, so cannot differentiate between applications or provide proper queuing. In other words, every application is not assured of receiving the resources required to ensure that the subscriber is satisfied with the quality of experience, regardless of what applications are being used at any given time. This is illustrated in Figure 3.

EthernetHeader

VLAN Tag

PPPoE

IPoE

Ethertype

PPPoE Header

IP Header

IP Payload

PPPoE TrailerFCS (2)

EthernetHeader

VLAN Tag

Ethertype

IP Header

IP Payload

PPPoE TrailerFCS (2)

Ethernetpriority markings

(IEEE802.1p)

IPpriority markings

(DiffServ)

Copyright ©2006, Juniper Networks, Inc 5


Figure 3: Typical DSLAM QoS Capabilities

There are several potential solutions to this conundrum:

• Move existing unicast traffic to IPoE. While technically feasible, this is an expensive proposition with little or no gain. It requires significant investment in changing procedures, reconfiguring network elements and retraining personnel. For many data applications (including most business applications) it is less secure than PPP. Simply, this is not an economically feasible business alternative for existing broadband access networks. Also this approach does not support wholesale access, in which each subscriber can choose their own ISP. This is required in some countries. PPP supports wholesale access applications today.

• Use DSLAMs which understand PPPoE, and allow the DSLAM to manage traffic to each subscriber. Though technically possible, this is not a good business decision. Due to the large number of DSLAMs in the network, adding this capability to every device would add significant operational as well as capital expense to this most expensive portion of the access network. As a result, few DSLAMs (if any) on the market today can inspect PPPoE packets.

It is more cost-effective to inspect PPPoE packets and prioritize the traffic accordingly in the edge router. In addition, DSLAMs do not typically provide the processing and queuing to manage traffic to each subscriber, limiting the service provider’s ability to support multiplay services.

• Introduce Ethernet aggregation switches which understand PPP. This parallels the DSLAM discussion above, although there are fewer Ethernet switches in the network than there are DSLAMs. It remains more cost-effective to provide PPPoE awareness and bandwidth management in the edge router. As a result, current Ethernet switches do not understand PPPoE. Instead, their role in PPPoE networks is limited to queuing traffic based on the Ethernet 802.1p priority markings.

The additional processing required to inspect and prioritize PPP leads Ethernet and DSLAM switch vendors to advocate use of DHCP, since Ethernet switches often can interpret IP DiffServ priority settings when using DHCP. Again, while technically feasible, it is the business justification which prevents many broadband operators from making this migration.

• Manage traffic using an edge router which understands PPPoE and IPoE. In this model, the edge router uses advanced queuing to manage traffic for each application being used by each subscriber. Since the edge router understands both IPoE and the PPPoE traffic, it can look inside the packet to determine the application and map it to the subscriber and/or service policy.

CoreBSRDSLAM

RG

Mom

Dad

Junior

Sis

Typical DSLAM:Can prioritize between DHCP and PPPoE sessions• For example, TV (DHCP) gets higher priority than Internet (PPPoE) session

Can prioritize within DHCP session• Based on Ethernet priority markings, not an application (IP) markings

Cannot prioritize within PPPoE session since DSLAMs do not understand PPP• Cannot specify whether VPN is more important than gaming, for example

Can prioritize between subscribers• Limited memory and processing prohibits per-subscriber queuing across multiple applications

TV

VPNWebTV

Games

STB (DHCP) session• IPTV/VoD content delivery

• TV parental controls

PC (PPPoE/Internet) sessions• Gaming

• VPN

• Web sur�ng

• TC on PC



This is naturally more cost-effective since there are far fewer edge routers in the network (often one edge router per 100 DSLAMs or dozens of switches), reducing the amount of configuration required which in turn lowers operational expenditure. It also allows existing ATM DSLAMs and lower cost Ethernet DSLAMs to be mixed in any switched access network as services are rolled out, rather than forcing an upfront wholesale migration. Finally, this matches the existing operational models, minimizing processes and procedural change as well as retraining costs.

The following table summarizes these options:

Alternative Implications

Move existing traffic to IPoE Costly with no revenue increase.

Use DSLAMs which understand PPPoE Higher cost DSLAMs, which already account for most of network capital cost. Thousands of DSLAMs to reconfigure as new services introduced. As a result, no current DSLAMs support PPPoE.

Use Ethernet switches which understand PPPoE

Similar discussion to DSLAMs, although there are fewer switches. No current Ethernet switches support PPPoE.

Manage traffic at edge router No operational change.Single provisioning point.

Multiplay in a Multi-Edge NetworkThe solution gets slightly more complex when using multiple edge routers. Many organizations would like to use the same simple edge switch and DSLAM access networks, but manage the services separately in the metro network using different edge routers. This is most common if another organization (either another group within the same broadband service provider or a contracted third party) provides the IP video services. This scenario, permitted by TR-101, is depicted in Figure 4.

Figure 4: TR-101 Typical Multi-Edge Network

There are multiple options available for ensuring the subscriber’s QoE while still allowing true multiplay services. The most common method is to statically allocate bandwidth to IPTV and VoD services. Other (often PPPoE-based) services cannot use this bandwidth, even if the subscriber is not viewing any video content. This works well when there is a large amount of access bandwidth in the local loop for services to share, such as short local copper loops, PON or active Ethernet.

DSLAMRG

BSR

BSR

Switch

PPPoE

Data, VoIP

IPTV

IPoE

Copyright ©2006, Juniper Networks, Inc 7


As bandwidth becomes limited, it is more critical to manage bandwidth dynamically. There are two techniques which provide this capability.

Dynamic Policy Management in a Multi-Edge Network

Policies can be applied through a central policy manager. The policy manager monitors each subscriber request to invoke a service change, converts this into a policy and communicates policy information to each BSR. For example, switching from a SD channel (which requires 2 Mbps) to a HD channel (which requires 8 Mbps) will cause the policy manager to reduce the bandwidth available to “data” applications by 6 Mbps if there is no spare bandwidth available; or may leave the bandwidth for data applications unaffected if there is sufficient bandwidth. In either case, the net result is that the subscriber’s satisfaction is assured since each application has sufficient bandwidth.

The policy manager works with the video, gaming and other applications to ensure enough bandwidth is available, and also allows the subscriber to upgrade service. In addition, it provides application level call admission control function on a per subscriber service if bandwidth is not available for the service.

Figure 5 depicts a network with a policy manager (Juniper Networks SDX-300) which assures bandwidth and resources for all traffic. The SDX functions as follows:

Figure 5: Multi-Edge Network with Network Resource Management

1. A subscriber initiates or changes a service (such as moving from a standard to high definition television channel), and the request flows to the appropriate edge router

2. The edge router informs the SDX-300 of the request. Since the SDX is aware of all services through either router, it can make an informed decision about whether this is request can be honored and necessary network adjustments.

3. The edge router then instructs both edge routers what to do, based on this request. For example, the request can be denied if there is not enough access bandwidth available, or the SDX can inform the data edge router to reduce the amount of PPP based services traffic which it is sending so that the additional IPoE encapsulated video traffic can be accommodated on the DSL link.

In a network using a single edge router for all services, many of these decisions can be made within the edge router.

DSLAM

BSR

BSR

Switch

Data, VoIP

IPTV

IPoE

SDX-300

RG 1

2

3

3



IGMP Forking

In addition, IGMP forking can be used to inform both BSRs of broadcast TV activity. This technique, also permitted within TR-101, allows the RG to send messages such as channel change requests to both the video BSR and the data BSR. The video BSR needs this information to change the channel, while the data BSR can now determine whether it needs to adjust the bandwidth available for data applications (such as when switching from a SD to an HD channel). This approach maximizes bandwidth reuse and scales the policy management function at minimal expense.

Figure 6 illustrates the use of IGMP forking. While the SDX is not involved in changing channels, it still provides call admission control. Using a single edge router to support all services eliminates the need to use IGMP forking.

Figure 6: Multi-Edge Network with IGMP Forking

SummaryAdding DHCP-based IPTV service to an existing PPPoE-based broadband network is the simplest, lowest cost and lowest risk path to offering multiplay services on today’s broadband access networks. Cost-effectively and easily supporting this requires that the edge router (BSR) manage traffic delivery to each subscriber. All services can be consolidated onto the same access network, mixing business-based services (typically supported using PPPoE) with the mixed encapsulation services to residences. Intelligent, flexible edge routing allows the evolution to multiplay services with significantly less cost and disruption than upgrading the access network, regardless of the starting point or desired operational model.

ContactMarc Bernstein [email protected] 978-589-0651

DSLAM

BSR

BSR

Switch

Data, VoIP

IPTV

IGMP (IPoE)

SDX-300

RG

IGMP (IPoE)

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

Integrating DHCP and PPP

Documents

Transcript of Integrating DHCP and PPP