| Most large-scale deployments of DSL by telecom carriers in North America and Europe use ATM to provide the end-to-end connections between the customer's premises and the service provider who provides access to the services used by the customer. The use of ATM for the core of the access network, as shown in Figure 14.1, has several advantages for the access provider: -
Telephone companies have widely deployed ATM networks to provide other data services to their customers. They are thus familiar with their architecture, engineering, and management. The connection-based nature of ATM provides an architecture that the telephone carriers are comfortable with and know how to operate . -
The ATM-based core networks scale well as the number of customers supported by the network increase. The networks can be engineered so that the quality of service (QoS) to each customer is unaffected by the addition of new customers to the network. -
ATM protocols and networks support differentiated quality of service for different customers on the same network or for multiple services to the same customer. This gives the carriers the potential to offer multiple services to individual customers. Figure 14.1. Overview of the use of ATM in DSL access architectures. Table 14.1 lists the qualities of ATM-based architectures when compared with the criteria listed in DSL Forum TR-43. 14.2.1 AAL5 ATM adaptation Layer 5 (AAL5) defines the method for carrying datagram-based services (such as IP) over an ATM virtual circuit. An AAL5 PDU spans multiple cells and provides error detection for the transmitted data. Table 14.2 lists the qualities of AAL5 when used to support DSL. A stack based on ATM and AAL5 is used as the basis for most of the widely implemented DSL end-to-end protocols for data traffic. Figure 14.2 illustrates the stacks for these five protocols. Figure 14.2. Stacks for four commonly implemented protocols over ATM/AAL5 at the "U" Interface. This Interface is the interface that carries the DSL physical layer between the customer's premises and the network. Adapted from DSL Forum TR-43, 2001. Table 14.1. Qualities of ATM-based Architectures | Criteria | ATM Qualities | | Payload efficiency | ATM has a 5-byte header in every 53-byte cell resulting in a 10% "header tax" for all communications over ATM. | | Session multiplexing | ATM provides intrinsic support for multiple sessions via the use of multiple virtual circuits between a network and the customer's premises. | | Multiprotocol support | An ATM virtual circuit can support many different protocol stacks. Many IP-based environments can be supported using AAL5 [5]. AAL1 is appropriate for transport of services requiring emulation of a constant bit rate point-to-point circuit, and AAL2 was developed to carry digital telephony efficiently . | | Autoconfiguration and management | The integrated local management interface (ILMI) provides a method of configuring the ATM service at the customer premises. DSL Forum TR-37 describes the use of ILMI for configuration of DSL services. | | Service selection | Although the use of permanent virtual circuits (PVCs) requires preconfiguration , the use of switched virtual circuits (SVCs) allows communication between the users' premises and the service providers to be set up in real time as needed. SVC setup can be used as part of a service selection process or a user can select the appropriate preconfigured PVC to reach a particular service. | | Security and AAA | The support of VCs end to end keeps communications for different users and services separated, which provides some security enhancements. The security functions of higher levels of the stack are unaffected by the use of ATM. | | Error detection | Errors to cell headers introduced during transmission can be detected . | | Standards status | ATM is defined in numerous standards developed by the ITU-T and ATM Forum. | 14.2.2 Multiplexing Other Protocols on AAL5 IETF RFC 2684 [2] defines several methods for encapsulation of data protocols over ATM virtual circuits. It allows the definition interfaces that permit the ATM circuit to be used by a bridge to transport link level protocols (such as Ethernet) to the remote site. It also allows the definition of interfaces that permit routed protocols such as IP to be transported directly over the ATM virtual circuits. RFC 2684 supports two different methods for carrying connectionless network interconnect traffic, routed and bridged protocol data units (PDUs), over an ATM network. The first method allows multiplexing of multiple protocols over a single VCC (virtual circuit connection). The protocol carried by a PDU is identified by prefixing the PDU with an IEEE 802.2 LLC header [9]. This method is called "LLC encapsulation." The second method does higher-layer protocol multiplexing implicitly by VC, and it is called "VC multiplexing." LLC encapsulation is used to carry Ethernet over ATM VC in a DSL environment, and VC multiplexing is used to carry IP directly over the AAL5 adaptation layer. Table 14.2. Qualities of AAL5 | Criteria | AAL5 Qualities | | Payload efficiency | AAL5 adds 8 bytes of trailer to each PDU. The effect on total payload efficiency is a function of the PDU length, which can be as high as 65,535 bytes. | | Session multiplexing | AAL5 does not support session multiplexing within a particular VC. The higher levels of the stack supported by AAL5 may support multiple sessions. | | Multiprotocol support | RFC 2684 describes methods for encapsulating multiple protocols over AAL5. | | Autoconfiguration and management | The use of AAL5 on VCs on a DSL connection can be communicated to the user's CPE via the ILMI interface. | | Service selection | This is a function of higher-layer protocols. | | Security and AAA | AAL5 neither enhances nor degrades the security function of protocols above or below it in the stack. | | Standards | AAL5 is defined in ITU-T Standards I363.5 [5]. | Bridged Ethernet Figure 14.3 illustrates a DSL access architecture that uses IP over a bridged Ethernet. Using RFC 2684 LLC encapsulation allows the Ethernet packets to be carried over an ATM VC supporting AAL5 adaptation. If the Ethernet PDUs carry IP packets, then IP packets carried on the LAN will be transported over the Ethernet on the DSL connection. PPP over Ethernet discussed in Section 14.1 also uses LLC encapsulated Ethernet to bridge the premises LAN to the far end of the network. Figure 14.3. Bridged Ethernet directly transporting IP. Table 14.3 shows the IP over Ethernet qualities for the encapsulation of Ethernet over AAL5 using RFC 2684 encapsulation. IP Directly on AAL5 IP can be directly transported on AAL5 using RFC 2684 VC multiplexing. In this case a router at the customer's premises terminates the DSL circuit and the ATM AAL5 VC. Figure 14.4 illustrates an access network supporting IP directly on AAL5. Figure 14.4. IP directly on AAL5. Table 14.4 lists the qualities of a protocol stack supporting IP on AAL5. Table 14.3. IP over Ethernet Qualities | Criteria | IP over Ethernet Qualities | | Payload efficiency | Ethernet requires an 8-byte header for each 1,492-byte Ethernet packet. The RFC 2684 LLC encapsulation requires an additional 8 bytes of header information. | | Session multiplexing | RFC 2684 LLC encapsulation does not support sessions directly. However, higher lever protocols (such as PPPoE) can support sessions. | | Multiprotocol support | RFC 2684 describes methods for encapsulating multiple protocols over AAL5. Ethernet is capable of supporting multiple protocols. | | Autoconfiguration and management | The ATM ILMI can be used to indicate that LLC encapsulation is used. If IP is transported directly over Ethernet, standard IP tools such as DHCP can be used to configure the customer's devices over the network. | | Service selection | This is a function of higher-layer protocols. | | Security and AAA | This is not a function provided by RFC 2684. Higher-level protocols can be carried over LLC encapsulation, and can provide these functions. | | Standards | IETF RFC 2684. | Table 14.4. IP on AAL5 Qualities | Criteria | IP on AAL5 Qualities | | Payload efficiency | No extra overhead is added beyond that required for ATM, AAL5, and IP components of the stack. | | Session multiplexing | IP directly on AAL5 does not support session multiplexing. | | Multiprotocol support | This protocol stack is meant to support IP and protocols that run over IP (other routed protocols such as IPX can also be supported). | | Autoconfiguration and management | The use of IP over AAL5 can be communicated using the ILMI interface. The IP layers of the stack can be configured using standard IP tools. | | Service selection | This is a not a function of this stack. | | Security and AAA | This function is not inherent in this stack. However, security tools such IPsec can be supported over IP. | | Standards | VC multiplexing is defined in RFC 2684. | Table 14.5. PPP Qualities | Criteria | PPP Qualities | | Payload efficiency | PPP adds a 2-byte header to each PDU. | | Session multiplexing | As PPP can support multiple simultaneous protocols, multiple sessions can be implemented. | | Multiprotocol support | PPP allows the support of multiple protocols over each session. Each PDU contains a protocol ID to identify the payload type. | | Autoconfiguration and management | PPP allows the negotiation of link capabilities such as compression and encryption using link control protocols (LCP) during session startup. Network control protocols (NCP) are used to support automatic address assignment. Additional configuration information can be provided using DHCP. | | Service selection | It is possible to use the PPP negotiation process to select access to a particular service. | | Security and AAA | The functionality provided by the PPP LCP protocols allows for the authentication and identification of users of a service. PPP allows the negotiation of the use of encryption on a link. | | Standards | Defined in IETF RFC 1661 [6]. | 14.2.3 Use of PPP Point-to-point protocol (PPP) was defined as the Internet standard for transmission of IP packets over serial lines. PPP supports the assignment and management of IP addresses, network protocol multiplexing, link configuration, error detection, and data-compression negotiation. The protocol is described in IETF RFC 1661 [6]. Although originally defined for use over point-to-point connection, such as those provided by analog modem over the dial telephone network, the protocol has been adapted for use over broadband connections such as those provided by DSL services. Two such adaptations of PPP have been defined: PPP over ATM PPP over ATM is described in IETF RFC 2364 [3] and DSL Forum TR-17 [8]. Figure 14.5 illustrates the protocol stack and network architecture for PPP over ATM. Figure 14.5. PPP over ATM stack. PPP over ATM is specifically designed to support environments where the user's device supports the termination of both the ATM session and the PPP session. For example, a workstation or PC that supports an ATM stack directly and contains a DSL modem internally could support this protocol. Similarly, a router that used DSL for WAN access could terminate a PPP over ATM session to the service provider while routing traffic locally on the LAN. Table 14.6 shows the qualities of PPP over ATM as a network protocol for DSL access. PPP over Ethernet PPP over Ethernet addresses the problem of connecting multiple devices over DSL access on the customer's premises. The protocol solves this problem by allowing the transport of multiple PPP sessions over an Ethernet LAN, which is multiplexed over AAL5 on the DSL WAN interface. As with PPP over AAL5, PPP over Ethernet can provide a PC user with an access environment that simulates the dial-up environment seen with analog modems on the PSTN. However, multiple PPP sessions can be multiplexed over one ATM VC, allowing relatively simple support for multiple devices over the DSL interfaces, and the ability for each user on the LAN to select from multiple service providers over a single ATM VC. The configuration of the ATM network is therefore quite simple when PPP over Ethernet is supported; a single VC can support multiple simultaneous users of multiple services without the complexity or expense of a router on the customer's premises. Figure 14.6 illustrates the architecture of a PPP over Ethernet network. Figure 14.6. PPP over Ethernet (PPPoE). Table 14.6. PPP over ATM Qualities | Criteria | PPP over ATM Qualities | | Payload efficiency | No extra overhead is added beyond that required for the ATM, AAL5, and PPP components of the stack. | | Session multiplexing | Only a single PPP session can be supported per ATM VC. | | Multiprotocol support | PPP over ATM inherits the multiprotocol capabilities of PPP. | | Autoconfiguration and management | PPP over ATM inherits the management tools that are provided by the ATM and PPP components of the protocol stack. | | Service selection | It is possible to use the PPP negotiation process to select access to a particular service. Additionally, multiple ATM VCs could be used to access different services. | | Security and AAA | The functionality provided by PPP provides the security and AAA functionality for PPP over ATM. | | Standards | Defined in IETF RFC 2364. | PPP over Ethernet has the qualities shown in Table 14.7 as a protocol for DSL access. |