ADSL reference diagram

I’m getting lots of ADSL QoS questions lately, 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):

  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 …

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

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.

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

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

    ReplyDelete
  3. Carlos Garcia22 June, 2009 14:12

    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?

    ReplyDelete
  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!

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

    ReplyDelete
  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

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

    Zohouri@in.com

    ReplyDelete
  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 :)

    ReplyDelete
  9. You might want to extend the drawing to include LAC/LNS session forwarding (which still are layer 2).

    ReplyDelete
  10. Ouch ... getting more and more complex ;)

    ReplyDelete
  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

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

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

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

    ReplyDelete
  15. A very helpful post as I am working through a small DSL implementation now. Thanks!

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.