Professional Documents
Culture Documents
1. Introduction
DSLAMs connect individual customers with the broadband
service provider network. Today's DSLAMs can become
quite large systems by aggregating several thousands of
subscriber lines. They are built modularly out of different
line cards, a backplane, and at least one trunk card, see Figure
1. Figure 2 highlights our future outlook on aggregation
and transport technologies, where most of the traditional
equipment has become obsolete. Narrowband switches and
ATM switches have completely disappeared. Former broadband
remote access server (BRAS) functions have become
partly obsolete, partly distributed. The IP-DSLAM now
represents the central access point for all narrow- and broadband
services.
In order to build such systems, well de_ned traf_c scenarios
and application benchmarks are required to explore
design trade-offs. These design trade-offs are not bound
to the architecture of a line or trunk card, but affect the
functional partition between these cards, too. However, no
system-level benchmarks have been de_ned so far that specify
both comparable and representative DSLAM usage scenarios.
Existing benchmarks often focus on function kernels
only, e. g. packet forwarding, MPLS, or IPSec. Although
most of these kernels represent typical computational
loads they often cannot be used off-the-shelf for a
particular application.
This is why we recognize the need for a reference implementation
of a complete DSLAM system to _rst enable
design space exploration and furthermore simplify the programming
of the resulting system. This process is particularly
eased if the benchmark application can be derived
DSLAM Architecture
xDSL
xDSL
xDSL
ISP
Upstream traffic
Downstream traffic
Internet
Ethernet
xDSL
Customer-Premises
Equipment (CPE)
Digital Subscriber Line
Access Multiplexer
CPE
CPE
CPE
or ATM
Multiple Services
provider network
(voice, video, data)
connect the cards with each other. The channels are the
abstraction of an Ethernet switch (or switching cascade).
They provide point-to-point links with limited bandwidth.
Line cards have a number of individual DSL ports and one
port to the internal crossbar. Trunk cards have a number of
crossbar ports and one uplink port. This functionally correct
arrangement has been chosen for ease of implementation.
Real world trunk cards have only one high speed port to
the crossbar instead, thus leaving the multiplex/demultiplex
step to the crossbar. A DSLAM that intends to exploit the
switching capabilities between line cards would have to use
a re_ned abstraction of the Ethernet backplane.
All cards have push inputs and pull outputs, and some
queuing is required on the cards. The channels pull packets
with constant bitrates from one card and push them into
the next card, similarly to sources (push) and sinks (pull).
The rates of sources, sinks, and channel elements have to
be balanced for an operational model.
3.3. DSLAM Functionality
The functionality of a future DSLAM can be described by
a set of eleven primary tasks that are explained next. A
primary task may contain several Click elements:
_ Ethernet encapsulation: Encapsulated IP packets that
are received on an ingress port are extracted from the
frame, processed, and encapsulated again to be transported
over the internal backplane or to egress ports. We
use Click's EtherEncap, SetCRC32, CheckCRC32, and
Strip elements for that purpose. They are encapsulated in
from eth and to eth compound elements.
_ AAL5: AAL5 splits IP packets into a ATM cells or reassembles
them, respectively. We use ATM solely as
layer-2 point-to-point protocol. Our IP-DSLAM does not
rely on any of ATM's QoS features. Two Click elements
IP2ATMand ATM2IP have been implemented for AAL5.
_ IP header check: Packets are checked as speci_ed
in RFC1812 [2]. This includes checksum and TTL/
HLIM veri_cation. We use modi_ed CheckIPHeader and
CheckIP6Header elements.
_ IP source address/port veri_cation: In upstream direction
for each DSL port the source addresses are veri_ed.
An IPVerifyPort element has been implemented that uses
reverse-path forwarding on the IP source address to verify
the annotated port information.
_ 5-tuple classi_cation/destination lookup: Based on IP
source/destination addresses, protocol type, and layer-4
protocols and port numbers a classi_cation is performed
to determine traf_c class and forwarding information.
Click's IPFilter and a derived IPFilterAnno are used.
_ Traf_c policing and QoS: In downstream direction the
classi_cation result is used for traf_c conditioning. In upstream
direction traf_c pro_les derived from service-level
agreements are enforced. We use Click's BandwidthMeter
for policing the connected queues. Schedulers provide
the required QoS distinction.
_ Multicast duplication: Multicast duplication may be performed
Queue
Bandwidth
meter
SetAnno
(3,0)
Bandwidth
meter
SetAnno
(3,1)
Bandwidth
meter
SetAnno
(3,tc-1)
Bandwidth
meter
SetAnno
(3,0)
Bandwidth
meter
SetAnno
(3,1)
Bandwidth
meter
SetAnno
(3,tc-1)
Bandwidth
meter
SetAnno
(3,0)
Bandwidth
meter
SetAnno
(3,1)
Bandwidth
meter
SetAnno
(3,tc-1)
a) IPv4 only
b) IPv4/IPv6
c) IPv6 only
Figure 5. Exemplary upstream line card (left) and trunk card (right) combining
IPv4 and IPv6.
Trunk Card Downstream
tc . Number of traffic classes
n . Number of line cards
Queue
Queue
Queue
Queue
Queue
Queue
Queue
Queue
Queue
0
1
tc-1
0
1
tc-1
0
1
tc-1
Figure 6. Exemplary downstream trunk card (left) and line card (right).
example. Different IP protocol variants (a-c) are demonstrated
in the _gure.
The cards in downstream direction are shown in Figure
6. The trunk card in downstream direction again deploys
an Ethernet uplink port and supports a mixed IPv4/IPv6 scenario.
In downstream direction, packet forwarding and traf_c management per line card are necessary besides the usual
packet veri_cation. Additionally, multicast packets need to
be handled. It should be noted that the destination lookup
provides a combined record with destination line card ID
and port ID, multicast group (if any), and traf_c class information.
In this way, only one classi_cation step is necessary.
ICMP packets addressed for the IP-DSLAM itself
are _ltered out of the packet stream as soon as the IP header
veri_cation has been successful.
Similar to the upstream line card, the downstream line
card shows all ATM/Ethernet/IPv4/IPv6 combinations. The
multicast duplication is implemented in two stages to keep
the internal system load as low as possible. The 2-stage approach
requires only a simple traf_c management scheme
(two buffers per port) on the line card to ensure that traf_c
with higher priorities precedes the best effort multicast traf_c. The QoS packet scheduling has already been performed
on the trunk card.
The pure Click description of an exemplary distributed
DSLAM requires only 266 lines-of-code (w/o comments),
6. Conclusion
The goal of this work is the development of a modular speci
_cation of a future DSLAM that enables the systematic
7. Acknowledgments
This work has been supported by the German government
(BMBF), grant 01AK065A (PlaNetS).We thank JorgChristian Niemann and Uwe Tellermann, University of
Paderborn, Germany, for their insights in pro_ling embedded
processors.
References
[1] Agilent Technologies. JTC 003: Mixed packet size throughput.
Journal of Internet Test Methodologies, Sept. 2004.
[2] F. Baker. Requirements for IP version 4 routers. RFC 1812,
Internet Engineering Task Force (IETF), June 1995.
[3] S. Blake, D. Black, M. Carlson, et al. An architecture for
differentiated service. RFC 2475, IETF, Dec. 1998.
[4] V. Cerf. On the evolution of Internet technologies. Proceedings
of the IEEE, 92(9), Sept. 2004.
[5] B. Chen and R. Morris. Flexible control of parallelism in a
multiprocessor PC router. In USENIX, June 2001.
[6] DSL Forum. DSL evolution . architecture requirements for
the support of QoS-enabled IP services. TR-059, Architecture
& Transport Working Group, Sept. 2003.
[7] M. Guthaus, J. Ringenberg, D. Ernst, et al. MiBench: A free,
commercially representative embedded benchmark suite. In
4th Workshop on Workload Characterization, Dec. 2001.
[8] E. Kohler, R. Morris, B. Chen, et al. The Click modular
router. ACM Trans. on Computer Systems, 18(3), Aug. 2000.
[9] C. Kulkarni, G. Brebner, and G. Schelle. Mapping a domain
speci_c language to a platform FPGA. In DAC, 2004.
[10] B. Lee and L. John. NpBench; a benchmark suite for control
plane and data plane applications for network processors. In
Int. Conference on Computer Design (ICCD), Oct. 2003.