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 |