DSLAM Basics

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).

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

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?

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

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+).

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