White Paper

Integrating DHCP and PPP:

Delivering World Class Multiplay Services

Marc Bernstein
Gary Southwell
IPTV Solutions Group

Juniper Networks, Inc.

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

Part Number: 200201-001 Sept 2006

 Integrating DHCP and PPP: Delivering World Class Multiplay Services

Tabel of Contents
Introduction . ....................................................................................................................... 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

Integrating DHCP and PPP: Delivering World Class Multiplay Services

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.

Requirements
As 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-101
DSL 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.

DSLA Swit BSR

M ch
RG

PPPoE and/or IPoE (DHCP)

Figure 1: TR-101 Single Edge Topology

Copyright ©2006, Juniper Networks, Inc 

 Integrating DHCP and PPP: Delivering World Class Multiplay Services

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 Services

Efficiently 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.

Ethernet Ethernet
Header Header
Ethernet
VLAN Tag priority markings VLAN Tag
(IEEE802.1p)
Ethertype Ethertype
PPPoE Header IP IP Header
priority markings
IP Header (DiffServ)
IP Payload
IP Payload PPPoE Trailer
FCS (2)
PPPoE Trailer
FCS (2) IPoE

PPPoE
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.

 Copyright ©2006, Juniper Networks, Inc

Integrating DHCP and PPP: Delivering World Class Multiplay Services

STB (DHCP) session

TV • IPTV/VoD content delivery
• TV parental controls

Sis
Games
DSLA BSR
M
RG Core
Junio
r

VPN Typical DSLAM:

Web Can prioritize between DHCP and PPPoE sessions
TV • For example, TV (DHCP) gets higher priority than Internet (PPPoE) session PC (PPPoE/Internet)
Dad Can prioritize within DHCP session sessions
Mom • Based on Ethernet priority markings, not an application (IP) markings • Gaming
Cannot prioritize within PPPoE session since DSLAMs do not understand PPP • VPN
• Cannot specify whether VPN is more important than gaming, for example
• Web surfing
Can prioritize between subscribers
• Limited memory and processing prohibits per-subscriber queuing across • TC on PC
multiple applications

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.

Copyright ©2006, Juniper Networks, Inc 

 Integrating DHCP and PPP: Delivering World Class Multiplay Services

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
Move existing traffic to IPoE
Use DSLAMs which understand PPPoE
Use Ethernet switches which understand
PPPoE
Manage traffic at edge router
Implications
Costly with no revenue increase.
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.
Similar discussion to DSLAMs, although there
are fewer switches. No current Ethernet
switches support PPPoE.
No operational change.Single provisioning
point.

Multiplay in a Multi-Edge Network

The 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.
IPTV

BSR

IPoE

DSLA Swit
M ch
RG

BSR

PPPoE

Data, VoIP
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.

 Copyright ©2006, Juniper Networks, Inc

Integrating DHCP and PPP: Delivering World Class Multiplay Services

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:
IPTV
BSR

IPoE 2
3
DSLA Swit
M ch
RG 1
SDX-3
00

BSR 3

Data, VoIP

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.

Copyright ©2006, Juniper Networks, Inc 

 Integrating DHCP and PPP: Delivering World Class Multiplay Services

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.
IPTV

BSR

IGMP (IPoE)
DSLA Swit
M ch
RG

SDX-3
00

IGMP (IPoE)
BSR

Data, VoIP

Figure 6: Multi-Edge Network with IGMP Forking

Summary
Adding 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.

Contact
Marc Bernstein
mbernstein@juniper.net
978-589-0651

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.

 Copyright ©2006, Juniper Networks, Inc