DSLAM Basics

RavenLady · Posted: Fri Aug 18, 2006 6:50 pm Post subject:

This is an old post but have to commend you Ranger! The only thing I would add is that most deployed DSLAMs are still utilizing ATM backbones and the most common ATM trunks used are DS3 for CO based DSLAMs and IMA links for remote DSLAMs. Inverse multiplexing over ATM allows utilizing up to eight T1s to provide approx. 3- 12Mbps of combined BW to layer 2. Fairly elegant for a layer 1 protocol! Being able to use a GigE optical trunk on the MOE network pleases me! (DS3s are such a pain but keeps lots of Techs working!) MV
_________________
MV

Ranger24 · Posted: Sat Aug 19, 2006 9:04 am Post subject:

Hi RavenLady,

From your post I guess you are in the States (ATM, DS3 etc gave it away), and work with DSLAMs.

It is true that the majority of DSLAMs deployed 2 years ago or longer are ATM, however here in Europe IP / Ethernet DSLAMs are taking off and a significant number of operators (national & local) are now only deploying GE based DSLAM. (Also fibre is plentiful and cheap here - at one time the UK had a huge over availability of SDH fibre)

In SIngapore (I Think) IP DSLAMs have been IP based since they were first available - High density population with high ARPU makes it attractive & profitable.

R

koslyr · Posted: Mon Sep 25, 2006 10:36 pm Post subject:

At the phase of transition formATM to Metro Ethernet, it is necessary to be done some crucial choices for the next generation network.
Lets say that we have the known topology CPE - DSLAM – SWITCH – BRAS.

Between CPE & DSLAM there is ATM over ASDL and is needed to be defined the Single PVC or Multi PVC. So what is the best scenario, if we want to provide triple play services? What is the best choice for point of view of CPE (we don’t want all users to be obliged to buy a new modem/router in order to access the new services)? What is the best option according to parameter of scalability?

Also between DSLAM & SWITCH there is a same dilemma. More specific, the two options are Single Tag (S-Vlan) and Double Tag or Q in Q(S-Vlan, C-Vlan). Is there any connection if we choose multi pvc and Q in Q or just is this independent?

Also if we choose to establish the single Vlan (say one Vlan per Service per Dlsam) how the dslam discriminates the traffic for a specific user? Has the capability the Ethernet Dslam to Mac Learning the Mac addresses of the subscribers or just it is more simple to configure each physical port of the dslam to a certain vlan (customer vlan) in order to achieve the distinction of each user internet traffic?

Ranger24 · Posted: Tue Sep 26, 2006 12:56 pm Post subject:

Hi Koslyer

A bit short for time but Ill try to answer your questions

1) CPE & PVCs

Firstly for me this depends upon the customer state i.e existing or new. If existing then you are tied into the existing modem and your ability to remotely configure the modem. Worse case is you cannot reconfigure remotely so will probably have to make do with a single PVC and run the services over this. In this case the QoS services over the DSLAM become important. Different services will have to be seperate by DiffServ / CoS so the DSLAM will need to be able to map these to ATM QoS. Also Modem connectivity is an issue - i.e. for IPTV how does the modem connect to the TV, directly or via a STB.

If you can remotely reconfiguthe modem, or are supplying a new customer then typically in europe we supply services over 2 PVC - one for VoIP and 1 shared between IPTV & Internet access.

DSLAM & SWITCH

Don't over complicate this! the DSLAM nomally have vlans as follows:

1 per wholesale ISP (where ISPs prov services via your DSLAM)

1 for VoIP

1 for Internet Access

1 for IPTV

(maybe 1 for Video on Demand)

Further seperation is possible (i.e. geographically based on network design).

USER Identification.

Multiple services for multiple users can be supplied in the same VLAN and the DSLAM should be able determine the correct end user connection based on it's configuration. For example:

Customers configured as layer 2 connections -> MAC table
Customers configured as layer 3 connections -> Routing table

I'll give more details when I get more time.

br

R

koslyr · Posted: Wed Sep 27, 2006 6:45 pm Post subject:

Thanks Ranger for your immediate answer and valuable information.

About DSLAM Configuration.
Which is the best implementation if you have a network with triple play services?
1) 1 S-Vlan (Service Vlan) for Service Identification – Separation.
1 Mac Address per Port for User Identification.
2) 1 S-Vlan (Service Vlan) for Service Identification – Separation.
1 C-Valn (Customer Vlan) per Port for User Identification.
At the second case we are using the Q in Q configuration.

About QoS at DSLAM.
In order to define QoS at the most of dslam there are two main concepts. The “Line Profile” and “Traffic Descriptors”. If I know well the Line Profile has to do with the hardware characteristics (SNR ratio, Attenuation, Max – Min rate) of port dslam & subscriber line. So this profile defines the user traffic only between DSLAM and CPE. The Traffic Descriptor is at logical layer and maybe has to do with the supplied services. Also the Traffic Descriptor offers the ability to specify traffic profile according to QoS or Cos parameters. For example if the core network is ATM based then the Traffic Descriptor corresponds the VP to CBR, VBR or UBR. At the case of Metro Ethernet just you are able to define a priority according to 802.1 p (0-7). So at my opinion the “Traffic descriptor” is at logical layer applied to services and if define for the Network part (Dslam to Bras).
Here I have another question. When you define QoS the main concerning is the downstream direction form Bras to CPE. At the network topology the dslam is the last component of this chain (BRAS – SWITCHES – DSLAM – CPE). So the QoS definition at Dslam for downstream flow what really offers to us? Is it worthing to specify QoS at Dlsam level or just leave this for Bras routers or for Metro Ethernet switches?

Lets give a brief example of QoS at Dslam.
We have a network with 3 services (fast internet, VoIP, IPTV)
Which is the best QoS configuration that must be done at DSLAM?
My proposal is the follow.
Configure each ADSL2+ port at a “Line Profile” of 24Mbps/1Mbps.
Create three “Traffic Descriptors” with different L2 priority and assign these to each S-Vlan(I assume that the network consists of three vlans).

Ranger24 · Posted: Thu Sep 28, 2006 9:00 am Post subject:

Hi Koslyer,

I'd prefer to use option (2) however most of the implementations I have worked with use option (1) as many existing CPEs do not support customer VLANS.

You are correct about the line profile, it defines the transmission capability of the line, and represents a target to be achieved not an absolute.

My preferred approcah would be the one you describe:

1) Set the line profile to aim for max performance (24Mbps)

2) Use QoS to define the used bandwidth and service priorities.

For example for triple play you may set the line to attempt to achieve 24mb/s and then define the bandwidth usage with traffic descriptors:

a) IPTV - Med priority (VLAN CoS), or AF (IP CoS) at 4mb/s per channel

b) VoIP - High Priority, or EF (128kb/s)

c) Internet - Low Priority, or DF (whatever if left)

As to where to apply QoS methods it really is going to depend upon both the network architecture and the B-RAS used. For me if it is possible to use the B-RAS to manage DSLAM customer bandwidth dynamically (i.e. SE800 from Redback).

By using the B-RAS to manage the traffic the DSLAM management can be simplified - every customer has the same config (line profile etc) and then you have a central point to manage services - the B-RAS.

Hope this helps.

br

R

koslyr · Posted: Thu Sep 28, 2006 7:46 pm Post subject:

Hi Ranger

You refer about dslam configuration that the 2 option (Q in Q) has a suuport problem from many existing CPEs. I don’t think this is right, as the CPEs don’t ever know about q in q. This Vlan stacking is applied to GE uplink of the dslam towards to metro Ethernet network. At the downstream flow the dlsam removes the s-vlan & c-vlan before sends the packets from adsl port to CPE. At the link Dslam – Cpe there is not any vlan label definition.

About the first implementation with the mac address I have the follow questions:
1)The mac address is the real mac of the CPE? At this case how do you protect the network from the ability of the user to change his mac address with software?
2)Can you define at dslam a mac – pool of virtual macs in order to assign at each port a mac from this pool?
3)If the user defines at his CPE PPPoE then the dslam has to use the mac of the CPE? At the same scenario if we change this attribute to PPPoA what about the mac address?

Ranger24 · Posted: Fri Sep 29, 2006 11:50 am Post subject:

Hi Koslyer,

Sorry my confusion we are taking about the same thing but using different terms. I did not mean q-in-q. A number of CPEs can establish a vlan to the DSLAM but this is rarely used. In effect the CPE <-> DSLAM link is a point to point link so the downstream QoS can be manged by DSLAM (or B-RAS) and upstream can be left unmanged or manged by the CPE.

MAC Address:

1) MAC Address may be that of the CPE. Most modern DSLAMs should have MAC Spoofing protection as a feature (Nokia, Siemens, and I think Alcatel do have)

2)This is not to my knowledge available on any DSLAM. MAC addresses are typically hard coded to CPE. But if it available the implementation would be vendor specific

3)MAC address that is visible to the DSLAM will depend upon where the tunnel originates from. If a USB modem is used then the tunnel starts from the user PC and therefore the Modem MAC is not visible. If the modem is ethernet based then the tunnel typically starts from within the CPE so I would expect to see the CPE MAC. The type of tunnel should not affect this

If a Ethernet / IP DSLAM is used then I would expect PPPoE tunnels to pass through the DSLAM, But PPPoA tunnels should be terminated at the DSLAM and a matching PPPoE tunnel establish by the DSLAM to the BRAS. So in effect the DSLAM is a PPPoA to PPPoE converter.

br

R

koslyr · Posted: Tue Oct 03, 2006 10:50 pm Post subject:

I have read that many vendors (Alcatel, ZTE) could support an easy migration from ATM to IP Dslam with just exchanging the main controller STM-1 board card with an Ethernet board (Gbps ports). The subscriber’s cards and all the cables to CO and MDF remains as it has.
But this “transforming” Ethernet dslam has the same hardware characteristics with a pure IP/Ethernet dslam? I don’t think, because the pure Ethernet dslam has an internal 1Gbps bus connecting all the subscriber’s ports to the uplink interface. Also the backplane capacity at a pure Ethernet dslam is greater by a transformation Ethernet dslam.
So my question is, if the productivity of a migrated “ATM to Ethernet” Dslam will be the same as a standard Ip/Ethernet Dslam or it is more preferable to use the replacement method of only the main controllers cards (I assume that all the subscriber’s cards support adsl2+).

Ranger24 · Posted: Wed Oct 04, 2006 1:43 pm Post subject:

Good Questions!

To migrate from ATM to IP/Ethernet then 3 things must be considered:

1) Migration of software from ATM to IP/Eth capability

2) Migration of uplink from ATM (STM-!) to IP/ETH (1Gb/s)

3) Capability of Backplane.

In an ideal world the DSLAM Control Unit (processor, sw, etc) and the uplink will be contained on the same physical card or unit. This allows both control unit (and therefore the software) and the uplink to be upgraded at the same time. Normally this means the line card unit will also be upgrade (software cascades through the dslam).

As for the back plane you need to remember that a backplane is lttle more then wire with a little inteligence. They actual capacity of the backplane should be determined by the backplane interface chips found on the line cards and control unit. Typically these chips have an capacity in the region of 20 -40 Gb/s and the software for the migration should allow increased usage of the bandwidth. The traffic format on the backplane may be ATM, Ethernet or propriety but doesn 't really matter as the processing will be done in the control unit.

Additionally to this an ATM DSLAM will NOT have enough MAC addresses - those it does have will be used for the management channel only. So the DSLAM will need probably 2-3 additional MAC addresses to be configured.

The MAC addresses can be associated with either the control card ot the DSLAM chassis. I prefer assoiciation with the chassis so that if the control unit requires replacement the MAC addresses do not need re configuring.

br

R