ADSL Reference Diagram

I’m getting lots of ADSL QoS questions lately1, so it’s obviously time to cover this topic. Before going into the QoS details, I want to make sure my understanding of the implications of the baroque ADSL protocol stack is correct.

In the most complex case, a DSL service could have up to eight separate components (including the end-user’s workstation):

From end-user to core ISP network: ADSL components

From end-user to core ISP network: ADSL components

  1. End-user workstation sends IP datagrams to the local (CPE) router.
  2. CPE router runs PPPoE session with the NAS (Network Access Server) and sends Ethernet datagrams to the DSL modem.
  3. DSL modem encapsulates Ethernet frames in RFC 1483 framing, slices them in ATM cells and sends them over the physical DSL link to DSLAM.
  4. DSLAM performs physical level concentration and sends the ATM cells (one VC per subscriber) into the network.
  5. The backhaul network (DSLAM to NAS) could be partly ATM based. The ATM cells could thus pass through several ATM switches.
  6. Eventually the ATM cells have to be reassembled into PPPoE frames. In a worst-case scenario, an ATM-to-Ethernet switch would perform that function.
  7. The backhaul network could be extended with Ethernet switches.
  8. Finally, the bridged PPPoE frames arrive @ NAS which terminates the PPPoE session and emits the IP datagrams into the IP core network.

I sincerely hope no network is as complex as the above diagram. In most cases, the backhaul would be either completely ATM-based …

ADSL access network with ATM backhaul

ADSL access network with ATM backhaul

… or Ethernet based (when the DSLAM has Ethernet uplink interface):

ADSL access network with Ethernet backhaul

ADSL access network with Ethernet backhaul

The NAS could also be adjacent to DSLAM or even integrated in the same chassis.

Am I missing anything important? I know you could deploy numerous additional devices (for example, Cisco is promoting the Service Exchange Framework and Service Control Engine), but these devices would be placed deeper into the IP core.


  1. It’s not that ADSL would become popular in 2020. I wrote the blog post in 2009, and recreated the diagrams from old drawings in 2020. ↩︎

15 comments:

  1. Hello, probably nobody asked for this but...
    What do you use to do the diagrams? they look much better than with visio.

    thanks in advance
  2. PowerPoint with an old template from Cisco. Takes a while to draw, but the results are OK.

    A few years ago someone decided that the devices should be darker green/grayish-blue and I really like those icons. Then they unfortunately reverted back to the light blue (the DSLAM in the diagram is the "new" icon) ... but I guess this is a question of personal taste.
  3. Remember to include double VLAN tagging (QinQ) in the third scenario, between DSLAM and NAS. It adds a lot of "interesting" questions. How do QoS mechanisms consider both tags? Headers or payload? And what about the MTU?
  4. Great overview!
    What other options for L2 are there other than ATM, as im sure not all ISP's will continue supporting an ATM network. In your overview, the link im talking about is the DSL access.

    Again, thanks!
  5. As far as I understand, DSL access always uses ATM cells, but this does not impact the rest of the ISP network if the DSLAM has (Fast/Gig)Ethernet uplink.
  6. 2 & 3 can be merged into one device.
    The CPE can terminate the DSL line directly.

    The other change that could exist is that there is no PPPoE and the CPE gets assigned an address via DHCP or static config. In a DSL network I built in my last job our DSLAM was also the IP gateway for the CPE and acted as a router
  7. Hello Thank you for fruitfull blog entries,
    Would you please let me know more about QinQ (Double Tagging) ?

    I have experienced with that in Zhone DSLAM and Mikrotik RouterOS.

    But thirsty to know more about that!
    Sincerely,
    Momo.

    [email protected]
  8. @Colin: can you tell me more about your setup?

    I've seen DSL modems that also act as PPPoE clients and provide LAN services (DHCP/NAT). Likewise, DSLAM could include the PPPoE server/IP routing functionality and terminate PPPoE IP traffic, or it could use a different (simpler) protocol stack ... and I need to know about that :)
  9. You might want to extend the drawing to include LAC/LNS session forwarding (which still are layer 2).
  10. Ouch ... getting more and more complex ;)
  11. @ Ivan
    There are several IP-DSLAM's who are able to act as an IP edge device and terminate PPP sessions directly, Huawei's SmartAX MA5600 can do it as far as I know (is someone really using Huawei devices? ;-) ) and I'm pretty sure that other vendors have simmilar solutions. So you've mostly bare Ethernet and no ATM here...

    Yet another scenario would be a network which is on the way to an NGN - you might have legacy ATM-based services & devices (Voice over ATM, ATM-based DSL-lines, ...) and newer IP/MPLS-based services & devices.
    I know providers which use MPLS- or L2TPv3-tunneling to transport the legacy ATM traffic over their IP core to an ATM switch / LAC - not a good thing for troubleshooting...

    Regards
    Christoph
  12. DSL is available with "native" ethernet via EFM. All VDSL2 is native ethernet as far as I know. I estimate that most DSL deployments today would use ethernet backhauled, IP-aware hardware these days.

    Implementations and Applications of DSL Technology by Golden et al. explains S and C vlan tagging options concisely. But basically, you can have multiple VLAN's stacked just like with atm PVI/VCI. You can have 1:1 or N:1 configurations. It also expands the maximum amount of VLAN's by providing two 12-bit address segments, for 4096*4096 vlans.
  13. I thought that in newer 'IP' DSLAMs, such as ALU ISAMs, that you terminate the session on the DSLAM itself. I don't think that this is a good idea for IPVPN as you'd then need to run MP-BGP and MPLS on the DSLAM as well. It'd be OK for consumer-grade internet access. Not very good for LI.
  14. @ Conda
    Nope, in such a case you can just use the DSLAM as LAC and forward the VPN sessions to dedicated LNS systems unsing L2TP...
  15. A very helpful post as I am working through a small DSL implementation now. Thanks!
Add comment
Sidebar