DSL Aggregation 101

Migrating from ATM to Ethernet using the DSL Forum's TR-101 * Drivers & standards * Architecture * Multicasting

January 4, 2007

17 Min Read
DSL Aggregation 101

Published in the Spring of 2006, the Broadband Forum ’s Technical Report 101 (TR-101), Migration to Ethernet-Based DSL Aggregation, promises to become a definitive blueprint for carriers wanting to migrate their broadband infrastructures from ATM to Ethernet.

The DSL Forum is no shrinking violet when it comes to trumpeting the virtues of TR-101, declaring roundly in the press release that followed TR-101’s publication:

  • TR-101 enables service providers to evolve their DSL access networks to better support faster rate technologies such as ADSL2plus and VDSL2. In parallel, it specifies the architecture to coordinate service rate management and multicast capability in an Ethernet network without affecting existing services that are currently offered. By leveraging TR-101, service providers can develop a multi-service end-to-end architecture to support offerings of new secure value-added consumer and business services such as Internet Protocol Television (IPTV).

But how does TR-101 achieve all this, and what effect will it have on the elements of an existing ATM-based DSL aggregation architecture? How does TR-101 overcome such issues as security, legacy protocols, and scaleability? This report provides an overview of such key points and examines TR-101’s approach to one of its key applications – video multicasting.

Here’s a hyperlinked contents list:

  • Page 4: Multicasting in TR-101


    This report is based on a Webinar, Migration to Ethernet-Based DSL Aggregation, moderated by Stan Hubbard, Senior Analyst, Heavy Reading, and David Allan, Co-Chair of the DSL Forum's Architecture and Transport committee, and sponsored by Alcatel-Lucent (NYSE: ALU), Cisco Systems Inc. (Nasdaq: CSCO), and Juniper Networks Inc. (NYSE: JNPR). An archive of the Webinar may be viewed free of charge by clicking here.

    Related Webinar archives:

  • VDSL2: New Competition for Cable and Satellite

  • VDSL2: Deployment & Migration Issues

  • DSL Chip Update: Higher Speeds, Enhanced Technologies

  • Using Metro Ethernet to Deliver Triple Play Services

  • State of Carrier Ethernet: Benefiting From Carrier Ethernet Standards

  • Ethernet in the First Mile: Technology & Market Update

  • The New Access Network: Multiservice Aggregation via Pseudowires

— Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.

Next Page: DSL Drivers & Standards

The key driver of DSL architecture evolution is the move by services providers from basic broadband Web access to higher-value services – essentially, (very) high-speed multimedia applications that exploit convergence among data, voice, and video for things like triple play, IPTV, HDTV, and network gaming. To do this, service providers have to figure out how to provide more bandwidth, add more features, and ensure an efficient network and better service management.

All this had big implications for the underlying DSL architecture and how it must evolve. That architecture has to:

  • Support an open service delivery model to accommodate a wide range of service providers

  • Provide network enhancements to cover, for example, quality of service (QOS), multicast access, migration from the current ATM installed base to Ethernet aggregation, and migration from copper to fiber-rich outside plant

  • Allow operations to scale effectively and efficiently, which means enhancements to network/service management

“The architecture recommendations emerging from the DSL Forum more or less track the trend of moving from basic high-speed access to multimedia services,” says David Allan, Senior Advisor, CTO Office, Nortel Networks, and DSL Forum Architecture and Transport Committee Co-Chair. Table 1 summarizes the key Technical Recommendations in their historical sequence.

Table 1: Development of DSL Forum Architecture Technical Recommendations






Access to legacy ISP data services over ADSL � replicates Point-to-point Protocol (PPP) techniques used in dialup Internet access. Mainly a wholesale model for access providers � Layer 2 Tunneling Protocol (L2TP) being the dominant direction at the time

TR-058, TR-059


Focus on multiservice. Introduced �application service provider connection model� [A10-Application Service Provider (ASP) interface], giving more value to access provider. Service rate control moved from DSL rate training in the DSL Access Multiplexer (DSLAM) to packet policing/shaping in the Broadband Remote Access Server (B-RAS)



B-RAS requirements to meet TR-059 architecture



Addresses issues of replacement of ATM aggregation networks by Ethernet. Adds architectural options for multicast/IPTV delivery

So TR-025 was primarily purely for access to the then existing ISPs, and was essentially a Layer 2 wholesale handoff using many of the same facilities and infrastructure – such as RADIUS – that ISPs were then using for their dialup services. TR-058, TR-059, and TR-092 looked to multiservices and adding value at Layer 3.

“One of the things we were very interested in doing at that stage was enabling a new spectrum of candidate business relationships in the network,” says Allan. “TR-92 introduces the notion that the access provider could manage network facilities at Layer 3 for application service providers. So these merely needed a relationship and a hand-off interface to a network service provider, who would handle most of the addressing and other connectivity issues associated with being able to offer higher-value services.”

However, TR-92 was oriented to the existing ATM DSL architectures, with their heavy reliance on DS3 or OC3 types of transport. While it put a lot of useful functionality into the B-RAS, the bandwidth and other limitations of the ATM architectures meant that something else was needed to handle the future challenges facing service providers.

“So at this point we brought forward TR-101, which is migrating to Ethernet DSL aggregation," says Allan. “It started as a one-for-one replacement, but it emerged quite quickly that a key driver was that we were also going to want to offer multicast and video-type services in the aggregation network. So we brought the recommendation forward to both migrate from ATM to Ethernet, and to take advantage of the additional multicast capabilities we could get in the aggregation network once we had an Ethernet infrastructure.”

TR-101 provides the specifications for key features needed to make this step, including:

  • Multiservice end-to-end architecture capable of supporting IPTV

  • Building on TR-058, TR-059, and TR-092 for continuity

  • IP QOS in the B-RAS/edge routers, now renamed broadband network gateways (BNGs)

  • Ethernet QOS in the DSLAM and aggregation network

  • Multicast replication in DSLAM and/or aggregation switch, with Internet Group Management Protocol (IGMP) snooping

  • PPP and IP wholesale services using BNG

  • Additional IP services using application wholesale

  • Multicast content does not need to go via the B-RAS/BNG, as there is the ability to insert video via a separate BNG or server

As the last point indicates, a potentially very important aspect of TR-101 is its support for the notion of a multi-edge architecture. This means that different types of service can have their own separate and optimized edge devices – for example, for broadcast IPTV or VOD.

“So the relatively high-touch BNGs that are doing the existing B-RAS functionality do not necessarily need to source or personalize the relatively high-bandwidth multicast flows,” says Allan. “That allows us to redistribute some of the functionality in the access network to handle this and to properly reconcile the QOS models and the appropriate tracking and service assurance. That was a fairly key thing that we had to work on, because if I have a single feed into a network it is a trivial problem compared to getting into multiple-feed scenarios.”

Essentially, a multi-edge architecture has separate Ethernet VLANs – one for each service – that are supported by separate, dedicated BNGs, as opposed to using a single central BNG to handle all services. The simplest multi-edge architecture is the dual edge, which, if implemented, would probably split services into video and everything else, as video has the highest network impact of all the next-gen services.

Next Page: TR-101 Architecture

Figure 1 shows the basic high-level TR-101 Next-Generation DSL Architecture, based on Ethernet aggregation. Generally, it assumes an IP-based regional broadband network (RBN) generously provided with hand-off interfaces to ISPs, network service providers (NSPs), and application service providers (ASPs), although there is provision for direct Ethernet linking to the aggregation network.

245.jpgNotably, there is no B-RAS, as this device becomes the broadband network gateway (BNG). Subtending from the BNG is the access network, which interconnects the access nodes or DSLAMs, and includes the aggregation network and a key reference point – the V reference point. Like the U reference point between the access network and the customer premises network (CPN), the V reference point preserves a terminology that goes back to older International Telecommunication Union, Standardization Sector (ITU-T) Recommendations.

It is a policy-based architecture, separating where policy is applied from where policy is enforced, in the same vein as in TR-059, and is intended to support business services and higher access speeds.

“Higher access speeds have meant that the access node – as typically the boundary between glass and copper – has reached progressively further out into the aggregation network, and one of the things we had to do in terms of defining an Ethernet architecture was to use VLAN approaches fairly extensively in order to take advantage of the Ethernet standards that exist,” says DSL Forum Architecture Committee’s Co-Chair Allan.

The main focus of TR-101, however, is on only part of this architecture, as shown in Figure 2. That is, TR-101 concerns mainly the BNG, any video source feeding into the aggregation network, the Ethernet aggregation network itself (which can consist of a number of switches, or in some cases, is just a null-function, where operators connect the access node directly into the BNG), the access node (DSLAM), and ultimately the network interface device (NID) and customer premises equipment (CPE).

246.jpgNetwork Elements and Features

Table 2 summarizes the main features of TR-101 as it affects these network elements.Table 2: Effect of TR-101 on Key Network Elements

Network element



PPPoE and/or IP/DHCP services. Bandwidth/QOS policy enforcement. Security. Multicast control. OAM

BNG (video only)

IP/DHCP services for unicast VOD and multicast IPTV. DiffServ QOS per class. Security. Multicast injection. DHCP relay

Ethernet aggregation

IP/DHCP services for unicast VOD and multicast IPTV. DiffServ QOS per class. Security. Multicast injection. DHCP relay

Access node (DSLAM)

ATM-Ethernet interworking. VLAN handling.Security. QOS. Multicast/IGMP. OAM


Layer 3 routing gateway. IGMP Proxy

The BNG continues to support PPPoE-based services, and it may also support IP and DHCP directly. This reflects increased industry interest, in some cases, in avoiding the use of PPPoE and instead moving directly to IP connectivity.

TR-101 carries forward bandwidth and QOS policy enforcement at the BNG from the TR-059 multiservice and B-RAS requirements work. However, there are security implications when changing from an ATM infrastructure to an Ethernet infrastructure that place some additional requirements on the BNG, and also, in the envisioned multi-edge architectures, there are implications of combining multiple sources feeding onto a customer loop with the QOS model that the BNG is expected to support.

“Certainly, one of the things that we need to do in the aggregation network is to track what sources are currently feeding the CPE, and we have defined the mechanisms in TR-101 to do that,” says Allan. “And, as we are changing from ATM to Ethernet infrastructure, there is a new set of OAM requirements that takes advantage of the excellent work going on in the IEEE and the ITU-T in the connectivity fault management work in 802.1ag and Y.1731.”

Figure 3 shows how modern, developed Ethernet OAM can now be applied to broadband networks. The basic point is that the use of stacked VLANs and standard Ethernet MAC addressing provides a layering of connectivity and hence of OAM. Three Ethernet maintenance levels being used, one corresponding more or less to the trunking connectivity between the access node and the BNG (red line), one virtually to the linecard for the individual customer back to the BNG (blue), and one to the customer’s routing gateway direct from the BNG (green).

247.jpgIn practice, the last OAM layer to the customer is probably rather early for wide deployment, and there have been discussions of the possibility of interworking Ethernet OAM with the access-link maintenance entity level – be that I.610-based or ultimately Ethernet in the first mile (EFM) – to produce a complete OAM framework.

Technical Issues

TR-101 has to address a number of specific technical issues raised by replacing ATM aggregation by Ethernet aggregation, as ATM and Ethernet have somewhat different technical characteristics.

ATM is designed to facilitate traffic management and QOS at Layer 2 in a very fine-grained and per-customer stateful fashion. It enables business and residential customers to be mixed on the single network and fits the early “standard” DSL architecture (TR-059), and so is well supported by equipment and management systems. Also, it has some inherent security, being a telco-inspired, connection-oriented technology.

Ethernet, in contrast, scales more cost-effectively to 1- and 10-Gbit/s network speeds. It dissociates Layer 2 connectivity from QOS, which can simplify service-provider provisioning by, for example, using pre-built VLANs and then adding or changing the user profile later. QOS is provided via Ethernet (priority) and IP (DiffServ) techniques and per-subscriber hierarchical scheduling. However, security was not an original design consideration.

Table 3 summarizes how these characteristics translate into specific issues, and the steps taken by TR-101 to overcome them.

Table 3: Technical Issues & TR-101 Solutions to Migrating From ATM to Ethernet Aggregation




Spoofing (Ethernet MAC address), Denial of Service (DOS) attacks, and to ensure correct mapping of customers to services

Trusted agents in the DSLAM for PPPoE/DHCP. Additional Ethernet MAC-level policy elements to block malicious customers

PPPoE Intermediate Agent extensions. Layer 2 DHCP Relay Agent extensions. ARP processing AND IP spoofing protection

Legacy protocols not amenable to Ethernet

Define interworking models and address OAM implications

PPPOA/PPPOE interworking. IPOA/IPOE Interworking

How to communicate the DSL loop status to the BNG for service management and QOS purposes

Extensions to PPPoE/DHCP to communicate this information to the BNG in a standard way

PPPoE Intermediate Agent or DHCP Relay Agent adds Access Loop characteristics (encapsulation, syncrate). The BNG sends the Access Loop information to the RADIUS server

VLAN scaling: 4094 are tags insufficient for any non-trivial network

Offer multiple tagging strategies for tag conservation

S-tag per port (S-tag demuxing). S-tag per DSLAM and C-tag per port. S-tag per DSLAM/MAC demuxing

Of all these issues, VLAN scaling is of particular concern for mass-market services such as IPTV and VOD, as VLANs underpin the multicasting and unicasting on which these services depend. TR-101 thus offers several tagging strategies to permit the service provider to define its own architecture and strategy for VLAN tag conservation. The possibilities are: the C-VLAN being defined by the inner or customer tag and the S-VLAN being defined by the outer or stack tag in an 802.1ad Q-in-Q VLAN architecture:

  • S-tag per port, primarily focused on business services, since it is where the first demultiplexing takes place

  • S-tag per DSLAM and C-tag per port, which is intended to provide an analogy to the ATM virtual path (VP) and virtual circuit (VC), with the S-tag playing the role of the VP and the C-tag that of the VC

  • S-tag per DSLAM with MAC-level demultiplexing at the access node itself to identify the individual ports

TR-101 actually uses a so-called N:1 VLAN per service approach as a resolution to the VLAN scaling issue for multicast data, as described on the next page.

Next Page: Multicasting in TR-101

The whole point of multicasting is to try to ensure efficient use of network resources by transmitting only one copy of a multicast packet over a link at any one time, using packet replication as necessary at nodes where onward links diverge. Optimizing the TR-101 architecture for multicasting has implications for four main points: the CPE as it multicasts into the home network; the access node; the aggregation network; and the BNG. Figure 4 highlights the scope of multicasting in TR-101.

248.jpgTR-101’s approach to multicasting is based on the following:

  • N:1 VLAN structure for delivery of multicast data (“multicast VLAN”)

  • IGMPv3 processing for resource-efficient IPTV support. This uses proxy-routing on the routing gateway, transparent snooping on the access and aggregation nodes (with SSM support – source IP address matching), and router and PIM/SSM on the BNG.

  • Multicast policy management is kept central, with channel-specific access control handled by the IPTV middleware.

  • Multicast source may be a distinct BNG, and snooping and proxy at access node summarize customer requests.

  • Coordination of access loop state with the BNG(s) when required, handling the gathering of statistics, and dynamically adjusting hierarchical schedulers in the BNG.

N:1 VLANs are an important building block of the TR-101 architecture, defined in TR-101 as: Many-to-one mapping between user ports and VLAN. The user ports may be located in the same or different access nodes. So these are essentially normal VLANs because they group together multiple subscribers into one logical VLAN, typically on a per-service or per-ISP basis.

N:1 VLANs are especially important for residential triple-play services, whereas business services rely typically on 1:1 or point-to-point VLANs within the aggregation network (but can use N:1 VLANs, too).

So, as TR-101 observes: For residential N:1 VLAN users, traffic is single-tagged with an S-Tag throughout the aggregation network. Each user port may have multiple sessions that can be carried in different VLANs, and the S-Tag may be common to more than one user port or user session. It can be shared by a large group of users as long as the access node and access network can maintain isolation between users.

On the other aspects of TR-101’s approach to multicasting, DSL Forum's Allan points out that the work tried to keep multicast policy management central, so that a fair amount of functionality was specifically delegated to the IPTV middleware so as to keep access control for the access node and aggregation network simple.

Also, the multicast source can be a distinct BNG, so there is a separate feed into the aggregation network compared to the customer’s NSP/ISP access.

“The key thing that probably generated the most discussion was the coordination of the access loop state with respect to multicast services with the BNG,” says Allan. “So the BNG is still the primary statistics gathering point, and also manages the QOS for all other services net of whatever video traffic is being fed to the customer. But ultimately the multicast architecture itself ended up as being side by side with those unicast streams going back and forth between the BNG and the subscriber.”

Figure 5 shows how IPTV multicasting could be handled within the TR-101 architecture, using a dual edge (although this is optional) to split off the video services. The application service provider feeds IPTV multicast streams from the video server to the video BNG across the core network. The video BNG is the key point of insertion into the aggregation network, and this is indicated by the solid line running between the set-top box and the application service provider. However, the per-subscriber control traffic is kept distinct from the multicast traffic, and typically is fed through the primary broadband network gateway, as shown by the broken line.

249.jpgFigure 5 also highlights a few other aspects of the DSL Forum architectures – for example, the notion of an autoconfiguration server, the work on triple-play requirements, and the work on set-top-box object models.

It’s worth pointing out that there are some subtleties in using per-service VLANs in multi-edge architectures such as that of Figure 5, especially if there are lots of separate edges. When moving from an ATM provisioning environment, it is easy and tempting to think of per-service VLANs as somewhat analogous to ATM PVCs. However, this can lead to provisioning schemes that are rather complex and hard to manage when there are a lot of separate edge devices, and it may be better to use the VLANs rather like ATM VPs to provision instead a service for a number of users, rather than a specific VLAN for each and every service for each and every service provider.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like