DSL Refernce

Title:        *DSL Reference
By:           James Bensley
Created:      07/12/2012
Last Updated: 05/01/2016
Corrections:    jwbensley <at> gmail <dot> com

xDSL Comparison
ADSL1 Reference
ADSL1 Topology Models
ADSL1 Protocol Stack
ADSL2+ Reference
SHDSL Reference

References:

Briding & Routing: Farsworth, S (2010). On PPPoA, PPPoE ATM and ADSL. Available: http://blog.farnz.org.uk/2010/02/on-pppoa-pppoe-atm-and-adsl.html, Last Accessed: 27/12/2014.
Briding & Routing: RFC1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5.
Briding & Routing: RFC2364 PPP over AAL5.
Briding & Routing: RFC2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5.
Briding & Routing: Rowe, M (2009). Understanding IPoEoATM and RFC 1483 Bridinging. Available: https://www.farside.org.uk/200903/ipoeoatm, Last accessed 27/12/2014.
Protocol Overheads: RFC2516 A Method for Transmitting PPP Over Ethernet (PPPoE).
Protocol Overheads: Aken, D (2000). Encapsulation Overhead(s) in ADSL Access Networks. Available: www.technicolorbroadbandpartner.com/getfile.php?id=525, Last Accessed 27/12/2014.
Protocol Overheads: Aken, D (2003). Encapsulation Overhead(s) in ADSL Access Networks. Available: http://wand.net.nz/~513/2006/readings/adsl-2.pdf, Last Accessed 16/09/2015.
Protocol Overheads: Broadband Forum (2001). TR-043: Protocols at the U Interface for Accessing Data Networks using ATM/DSL. Available https://www.broadband-forum.org/technical/download/TR-043.pdf, Last Accessed 27/12/2014.
Protocol Overheads: Broadband Forum (2006). TR-101: Migration to Ethernet-Based DSL Aggregation. Available https://www.broadband-forum.org/technical/download/TR-101.pdf, Last Accessed 22/12/2015.

AAL5
AAL5 (ATM Adaption Layer 5) is an encapsulation method that allows variable length payloads to be carried by one or more fixed size ATM cells.
Data is placed into the AAL5 CPCS-PDU (Common Part Convergence Sublayer).

        AAL5 CPCS-PDU Format
+-------------------------------+
|             .                 |
|             .                 |
|        CPCS-PDU Payload       |
|     up to 2^16 - 1 octets)    |
|             .                 |
|             .                 |
+-------------------------------+
|      PAD ( 0 - 47 octets)     |
+-------------------------------+ -------
|       CPCS-UU (1 octet )      |
+-------------------------------+
|         CPI (1 octet )        |
+-------------------------------+CPCS-PDU Trailer
|        Length (2 octets)      |
+-------------------------------|
|         CRC (4 octets)        |
+-------------------------------+ -------

RFC1483/RFC2684 - Routing and Bridging of multiple protocols over ATM AAL5
LLC encapsulation and VC mux provide two methods of multiprotocol encapsulation over ATM (placing data into the AAL5 CPCS-PDU).
Two modes of operation exist for these two multiplexing methods, routed and bridged.

LLC encapsulation can carry multiple protocols (such as IPv4, IPv6, ARP and Ethernet) per ATM virtual circuit.
LLC tends to require fewer VCs in a multiprotocol environment.
VC mux uses seperate ATM VCs for each protocol.
VC mux tends to reduce fragmentation overhead (a TCP ACK with no other TCP or IP options fits exactly into one ATM cell).

LLC Encapsulation
LLC Encapsulation is needed when several protocols are carried over the same VC.
To allow the receiver to properly process the incoming AAL5 CPCS-PDU, the Payload Field must contain information necessary to identify the protocol of the routed or bridged PDU. In LLC Encapsulation this information is encoded in an LLC header placed in front of the carried PDU (IEEE 802.2 Logical Link Control (LLC) header).

Routed ISO protocols have the 3 octet LLC header as follows, routed non-ISO protocols like IP have the 3 octet LLC headers which is followed by an IEEE 802.1a SubNetwork Attachment Point (SNAP) header:

Three octet LLC header
+------+------+------+
| DSAP | SSAP | Ctrl |
+------+------+------+

The presence of a SNAP header is indicated by the LLC header value 0xAA-AA-03. A SNAP header takes the following form:

+------+------+------+------+------+
|         OUI        |     PID     |
+------+------+------+------+------+

The three-octet Organizationally Unique Identifier (OUI) identifies an organization which administers the meaning of the following two octet Protocol Identifier (PID). Together they identify a distinct routed or bridged protocol. The OUI value 0x00-00-00 specifies that the following PID is an EtherType. The format of the AAL5 CPCS-PDU Payload field for routed non-ISO PDUs is as follows:

Payload Format for Routed non-ISO PDUs
+-------------------------------+
|       LLC  0xAA-AA-03         |
+-------------------------------+
|        OUI 0x00-00-00         |
+-------------------------------+
|     EtherType (2 octets)      |
+-------------------------------+
|             .                 |
|         Non-ISO PDU           |
|     (up to 2^16 - 9 octets)   |
|             .                 |
+-------------------------------+

In the particular case of an Internet IP PDU, the Ethertype value is
0x08-00:

Payload Format for Routed IP PDUs
+-------------------------------+
|       LLC  0xAA-AA-03         |
+-------------------------------+
|        OUI 0x00-00-00         |
+-------------------------------+
|       EtherType 0x08-00       |
+-------------------------------+
|             .                 |
|           IP PDU              |
|     (up to 2^16 - 9 octets)   |
|             .                 |
+-------------------------------+

For LLC Encapsulation of bridged PDUs, they are encapsulated by identifying the type of the bridged media in the SNAP header. As with routed non-ISO protocols, the presence of the SNAP header MUST be indicated by the LLC header value 0xAA-AA-03. With bridged protocols the OUI value in the SNAP header must be the 802.1 organization code 0x00-80-C2 and the actual type of the bridged media must be specified by the two octet PID. Additionally, the PID must indicate whether the original Frame Check Sequence (FCS) is preserved within the bridged PDU. The necessary number of padding octets MUST be added after the PID field in order to align the Ethernet/802.3 LLC Data field of the bridged PDU to begin at a four octet boundary. The bit ordering of the MAC address MUST be the same as it would be on the LAN or MAN. AAL5 CPCS-PDU Payload field carrying a bridged PDU:

Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
|       LLC  0xAA-AA-03         |
+-------------------------------+
|        OUI 0x00-80-C2         |
+-------------------------------+
|    PID 0x00-01 or 0x00-07     |
+-------------------------------+
|         PAD 0x00-00           |
+-------------------------------+
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
|  LAN FCS (if PID is 0x00-01)  |
+-------------------------------+

The Ethernet/802.3 physical layer requires padding of frames to a minimum size. A bridge that uses uses the Bridged Ethernet/802.3 encapsulation format with the preserved LAN FCS must include padding (PID 0x00-01). A bridge that uses the Bridged Ethernet/802.3 encapsulation format without the preserved LAN FCS MAY either include padding, or omit it (PID 0x00-07). When a bridge receives a frame in this format without the LAN FCS, it must be able to insert the necessary padding (if none is already present) before forwarding to an Ethernet/802.3 subnetwork.

VC Multiplexing
VC Multiplexing creates a binding between an ATM VC and the type ofthe network protocol carried on that VC. Thus, there is no need for protocol identification information to be carried in the payload of each AAL5 CPCS-PDU. This reduces payload overhead and can reduce per-packet processing. VC multiplexing can improve efficiency by reducing the number of cells needed to carry PDUs of certain lengths. For ATM PVCs, the type of the protocol to be carried over each PVC must be determined by configuration. For ATM SVCs, the negotiations specified in RFC 1755 must be used.

PDUs of routed protocols must be carried as the only content of the Payload of the AAL5 CPCS-PDU. The format of the AAL5 CPCS-PDU Payload field thus becomes:

Payload Format for Routed PDUs
+-------------------------------+
|             .                 |
|         Carried PDU           |
|    (up to 2^16 - 1 octets)    |
|             .                 |
|             .                 |
+-------------------------------+

PDUs of bridged protocols must be carried in the Payload of the AAL5 CPCS-PDU exactly as described for LLC encapsulation, except that only the fields after the PID field must be included. The AAL5 CPCS-PDU Payload field carrying a bridged PDU must have the following formats:

Payload Format for Bridged Ethernet/802.3 PDUs
+-------------------------------+
|         PAD 0x00-00           |
+-------------------------------+
|    MAC destination address    |
+-------------------------------+
|                               |
|   (remainder of MAC frame)    |
|                               |
+-------------------------------+
| LAN FCS (VC dependent option) |
+-------------------------------+

RFC1483 (1993), RFC2684 (1999).

LLC vs VC Mux overhead

+----------------------------------------------------------------------+
| Encapsulated Protocol    | LLC Encapsulation | VC Based Multiplexing |
|----------------------------------------------------------------------|
| Bridged IEEE 802.3 PDU's | 10                | 2                     |
| (FCS not preserved)      |                   |                       |
|----------------------------------------------------------------------|
| Bridged IEEE 802.3 PDU's | 14                | 6                     |
| (FCS preserved)          |                   |                       |
|----------------------------------------------------------------------|
| Routed non-ISO PDU's     | 8                 | 0                     |
| (e.g. IP)                |                   |                       |
|----------------------------------------------------------------------|
| Routed ISO PDU's         | 4                 | 0                     |
|----------------------------------------------------------------------|
| PPP PDU's ¹              | 4                 | 0                     |
+----------------------------------------------------------------------+

¹ This encapsulation is identical to Routed ISO PDU's. Although PPP over ATM encapsulation could have been integrated into RFC1483/2684 very easily, still it became a separate RFC, RFC2364.M

RFC1483 (1993), RFC2684 (1999), Aken, D (2000), Aken, D (2003), Farnsworth, S (2010), Rowe, M (2009).

Individual Protocol Overhead

+---------------------------------------------------------------------------+
| Protocol     | Header Size  | Header Fields (Size)                        |
+---------------------------------------------------------------------------+
| IPv4          | 20 octects   |                                            |
| PPP           | 2-4 octets¹  | Address (1), Control (1), Protocol ID (2), |
|               |              | Padding (0)                                |
| PPPoE         | 6 octets⁸    | Version/Type (1), Code (1), Session ID (2),|
|               |              | Length (2)                                 |
| MAC (Ethernet)| 14 octects²  | Dest MAC (6), Src MAC (6), EtherType (2),  |
|               |              | MAC Padd (0), MAC FCS(4)                   |
| LLC-Routed    | 8 octects³   | LLC (3), SNAP (5), Padding (0)             |
| VX-Routed     | 0 ⁴          | None                                       |
| LLC-Bridged   | 8 octects⁵   | LLC (3), SNAP (5), Padding (0)             |
| VC-Bridged    | 2 octets⁶    | Padding (2)                                |
| AAL5          | 8 octets⁷    | CPCS-UU (1), CPI (1), Length (2), CRC (4)  |
| ATM           | 5 octets     | GFC (0.5), VPI (1), VCI (2), PT/CLP (0.5), |
|               |              | HEC (1)                                    |
+---------------------------------------------------------------------------+

¹ PPP can add padding octets but this is almost never used. Via the Protocol Field Compression LCP Option, the PPP Protocol ID can be negotiated down to 1 octect but this is not recommended.
² 18 octects when FCS Preservation is enabled
³ Assuming IP over LLC
⁴ Assuming IP over VX-Muv
⁵ Assuming Ethernet over LLC, FCS not preserved
⁶ Assuming Ethernet over VC-Mux, FCS not preserved
⁷ 8 is the minimum; AAL5 trailer will pad the payload to a multiple of 48 octets before passing down to the ATM layer
⁸ RFC2516: "The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492. Since Ethernet has a maximum payload size of 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the PPP MTU MUST NOT be greater than 1492".

RFC2516 (1999).

Common DSL Protocol Overheads

+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| IPoEoATM¹      |      | PPPoEoATM      |         | IPoA           |         | PPPoA          |         | IPoE           |         | PPPoE          |        |
|--------------------------------------------------------------------------------------------------------------------------------------------------------------
| IP             | 20   | IP             | 20      | IP             | 20      | IP             | 20      | IP             | 20      | IP             | 20     |
|                |      | PPP            | 2       |                |         | PPP            | 2       |                |         | PPP            | 2      |
|                |      | PPPoE          | 6       |                |         |                |         |                |         | PPPoE          | 6      |
| MAC            | 14²  | MAC            | 14²     |                |         |                |         | MAC 14²         |         | MAC 14²        |        |
| RFC1483B/2684B | 10³  | RFC1483B/2684B | 10³     | RFC1483/2684R  | 8⁴      | RFC1483/2684R  | 8⁴      |                 |         |                |        |
| AAL5           | 8    | AAL5           | 8       | AAL5           | 8       | AAL5           | 8       |                |         |                |        |
| ATM            |      | ATM            |         | ATM            |         | ATM            |         |                |         |                |        |
| Total          |      | Total          |         | Total          |         | Total          |         | Total          |         | Total          |        |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------+

¹ A.K.A "RFC1483 Briding"
² Ethernet w/o FCS
³ LLC Bridiging without FCS, with VC-mux this would be 2 octets
⁴ LLC routing non-ISO IP, with VC-mux this would be 0 octets

Aken, D (2000), Broadband Forum (2001), Broadband Forum (2006), Farnsworth, S (2010), Rowe, M (2009).