ITU Home Page NTC of ITU

ATM and ADSL for High Speed Internet Access


Options for ATM/ADSL Configurations

With the growing prospects of ADSL deployment for delivering growing broadband services to homes, small businesses and remote offices, not only many new business opportunities will be emerge for service providers, but it will also increase the possible technical configuration options at the network infrastructure and at the customer premises. In this section, in spite of the multitude of variants that can be implemented, focus will provided in defining the basic guidelines that could be adopted for practical scenarios among the many conceivable network architectures.

This document deals with ADSL and ATM for high speed Internet access: the IP protocol is assumed as the underlying applications driver; ATM is deemed to be adopted (in spite of the fact that frame-based solutions could as well be developed, but from the strategic and long-term point of view ATM guarantees scalability and traffic integration on a much wider scope) to ensure data transport between the customer premises and the network providers (from the network access and transport providers, up to the service and applications supplier).

Following the ADSL network reference diagram (page 9): within the customer premises equipment takes place the encapsulation of (IP-based) data into ATM, the transmission of the cell flows across the ADSL link over the local loop, in parallel with the voice telephony traffic. The link terminates in a central office (CO) or remote digital loop carrier (DLC) system within the provider premises. The access node comprises the ADSL Termination Units typically referred to as DSLAM (Digital Subscriber Line Access Module). They perform aggregation and multiplexing of ADSL traffic, ATM cells, from multiple ADSL links onto the network provider and up to the service providers systems.

The Network Access or transport Provider (NAP) will be equipped with a collection of ATM switches (distributed regionally, nationally or internationally) that route the ATM traffic up to the Network Service Provider (NSP) facilities. The NSP may have either a backbone of ATM, frame-based switching systems, IP routers or eventually RAS (Remote Access Server) systems, which will recover the cells from the remote side of the NAP and ADSL/CPE premises. This implies a compatible termination of the encapsulation layer employed end-to-end, and the routing of packets (IP) across the destination network: LAN, WAN, applications, public services, or Internet gateway.

With the increasing business nature of the services provided through the Internet/Intranets, for corporate and teleworking purposes, the NSP routers or RAS systems may handle security and other administrative operations, user authentication, cryptography, IP address assignment, etc.

The encapsulation model affects the cost, performance, scalability, and impacts on the functionality of the network as a whole, hence the importance to understand the viable scenarios affecting the communication protocols across the ATM/ADSL network:

Communication Protocols across the ADSL Network

Source: ITU, Efficient Networks, Inc.

The following table details the possible encapsulation methods for the ATM/ADSL network, which would be function of the services and requirements determined at the NSP level. One obvious characteristic to look for the CPE is the ability to support one or more of these encapsulation mechanisms:

Encapsulation Method

Description

ATM Support

Characteristics

Ethernet frames over ATM RFC 1483 - "Multiprotocol Encapsulation over ATM Adaptation Layer 5"

PVCs

Simplicity and compatibility with Ethernet

Protocols: IP and other LAN protocols

IP Packets over ATM RFC 1577 - " Classical IP and ARP over ATM"

PVCs and SVCs

Widely supported in ATM products

Only IP protocol

Point-to-Point Protocol (PPP) over ATM Draft RFC [PPPATM]

PVCs and SVCs

Compatibility with existing dialup procedures

Dynamic IP addresses assignment, and default IP procedures support

Connection management, protocol transparency, security, multiple networks and destinations

Native ATM ATM API extensions such as Winsock2 with Microsoft's ATM extensions

PVCs and SVCs

No intermediate TCP/IP protocol stack

ATM features: addressing, service categories, quality of service (QoS)

Accordingly, a quite different set of options exist for the ADSL equipment to be deployed at the CPE side. This is ultimately dependent on the options and the requirements at the NAP network and the protocol encapsulation scheme at the NSP. Obviously, requirements and access needs vary from network to network and user to user, no single solution being best in every case. The table below lists the types of remote access scenarios and criteria to be met, and recommends the most effective CPE solution for the corresponding environment "deployment scenario".

Deployment Scenario

Recommendation

Support for a single remote user ATM/ADSL adapter card in a desktop PC
Clean demarcation between NAP and customer equipment ATM and ADSL as external units
Simple setup and configuration with existing Ethernet LANs Ethernet bridging ADSL modem. No ATM support
Operation with existing complex customer premises LANs Ethernet routing ADSL modem. No ATM support
Minimal changes to remote IP address management and security procedures PPP over ATM encapsulation with any ATM adapter
Low cost solution for a remote workgroup ATM/ADSL adapter in a router or routing server PC
Support for native ATM applications Winsock2 ATM extensions with any ATM adapter

Back to IBC Menu



Home | Search | Contact | Comments | © Copyright
Last Modified: 1997-10-17