- Posts: 6
- Thank you received: 0
DSLAM Basics
18 years 1 month ago #17580
by Ranger24
Patience - the last reserve of the any engineer
Replied by Ranger24 on topic Re: DSLAM Basics
QoS.
Have to be honest. I hate this topic....spins my noggin around too much! Let's have a go anyway.
There are 2 different networks scenarios to deal with - ATM DSLAM, or IP DSLAM. ATM dslam is easy as there is only one system to deal with - ATM so we can use ATM Traffic descriptors between CPE and B-RAS.
Once we introduce an IP DSLAM then life becomes more complicates as we noW have ATM between the DSLAM and Ethernet/IP between the DSLAM and B-RAS.
So in this case we may have ATM TDs set at the CPE that the DSLAm must be aware of and understand how to map to either VLAN priorities or IP DSCP(CoS). This mapping is as simple as the administrator creating the mapping with in the DSLAM. For Example:
[code:1]
ATM VLAN IP
===================================
CBR ---> HIGH ---> EF
rtVBR ---> MED ---> AF
nrtVBR ---> MED ---> AF
UBR ---> LOW ---> DF
[/code:1]
It also has to be remembered that any QoS implemented at the IP layer by the CPE can be (and perhaps should be) over written by the DSLAM in an upstream direction. But this will depend on the DSLAM configuration including the connection type.
The connection across the IP DSLAM can connect traffic at either Layer 2 or Layer 3. This means any IP QoS set by the CPE will only be read by DSLAM if the connection is configure at layer 3 (i.e is a routed connection on the DSLAM). For layer 3 connections (Switched connections) it will be the BRAS that interprets the QoS.
The preferable option is not to have the DSLAM QoS aware but to have the B-RAS manageing the downstream QoS through either dynamic or static traffic management. The DSLAM should not become a choke point as the B-RAS should be configured in such away as to ensure excess traffic is not permitted to the DSLAM. By using the B-RAS in this manner better use can be made of the transmissing network between the DSLAM and B-RAS whether Ethernet or ATM.
For an operator user control of the QoS (upstream) is not desirable as the user does not (and CANNOT) know the traffic requirements, capabilities and capacities of the network beyound the CPE. Business Users for example pay for a required level of services (bandwidth, latency, etc). The last thing an operator wants is users setting their own QoS and then affecting other paying traffic.
R
Have to be honest. I hate this topic....spins my noggin around too much! Let's have a go anyway.
There are 2 different networks scenarios to deal with - ATM DSLAM, or IP DSLAM. ATM dslam is easy as there is only one system to deal with - ATM so we can use ATM Traffic descriptors between CPE and B-RAS.
Once we introduce an IP DSLAM then life becomes more complicates as we noW have ATM between the DSLAM and Ethernet/IP between the DSLAM and B-RAS.
So in this case we may have ATM TDs set at the CPE that the DSLAm must be aware of and understand how to map to either VLAN priorities or IP DSCP(CoS). This mapping is as simple as the administrator creating the mapping with in the DSLAM. For Example:
[code:1]
ATM VLAN IP
===================================
CBR ---> HIGH ---> EF
rtVBR ---> MED ---> AF
nrtVBR ---> MED ---> AF
UBR ---> LOW ---> DF
[/code:1]
It also has to be remembered that any QoS implemented at the IP layer by the CPE can be (and perhaps should be) over written by the DSLAM in an upstream direction. But this will depend on the DSLAM configuration including the connection type.
The connection across the IP DSLAM can connect traffic at either Layer 2 or Layer 3. This means any IP QoS set by the CPE will only be read by DSLAM if the connection is configure at layer 3 (i.e is a routed connection on the DSLAM). For layer 3 connections (Switched connections) it will be the BRAS that interprets the QoS.
The preferable option is not to have the DSLAM QoS aware but to have the B-RAS manageing the downstream QoS through either dynamic or static traffic management. The DSLAM should not become a choke point as the B-RAS should be configured in such away as to ensure excess traffic is not permitted to the DSLAM. By using the B-RAS in this manner better use can be made of the transmissing network between the DSLAM and B-RAS whether Ethernet or ATM.
For an operator user control of the QoS (upstream) is not desirable as the user does not (and CANNOT) know the traffic requirements, capabilities and capacities of the network beyound the CPE. Business Users for example pay for a required level of services (bandwidth, latency, etc). The last thing an operator wants is users setting their own QoS and then affecting other paying traffic.
R
Patience - the last reserve of the any engineer
18 years 1 month ago #17581
by Ranger24
Patience - the last reserve of the any engineer
Replied by Ranger24 on topic Re: DSLAM Basics
Hi Lady,
IN theory these would only provide the name of the CPE vendor and not the DSLAM vendor (if I have got it right).
I am never too sure who actually adopts these TR's ...I have not come across and opertors using the model described in TR-069.
Perhaps if you could explain why you need the DSLAM identifier and where you are in the network (Customer end, Network Operations Centre etc) then we could figure out how this could be achieved.
R
IN theory these would only provide the name of the CPE vendor and not the DSLAM vendor (if I have got it right).
I am never too sure who actually adopts these TR's ...I have not come across and opertors using the model described in TR-069.
Perhaps if you could explain why you need the DSLAM identifier and where you are in the network (Customer end, Network Operations Centre etc) then we could figure out how this could be achieved.
R
Patience - the last reserve of the any engineer
18 years 4 weeks ago #17620
by lady
Replied by lady on topic Re: DSLAM Basics
Thanks Ranger. A lot of service providers (mainly in Europe) are strictly following the TR standards and for CPEs, the TR69 standard. Especially in places where the service providers use CPE management softwares.
Well, the reason for all these questions: I need to know how service providers keep a check on which CPE is terminated on which DSLAM. Say for instance there are are 1000 CPEs out there, and there are 5 DSLAMS. How does an operator know, the terminating points of the CPE? Im trying to figure out how they troubleshoot when they suspect a problem. Say for instance a user calls and says that hes unable to browse, the operator figures (using his CPE management software) that this problem is not with the CPE or the configuration on the CPE but could be with the line card in the DSLAM.....what next, how is he able to find out where to look for? Do they do it manually?
I thought if by using the TR69 parameter ATUCVendor, he can retrieve the vendor name of the ATUC (or the dslam) using the CPE management software, but again all 5 dslams could be from the same vendor. So what next? Does this make sense?
Well, the reason for all these questions: I need to know how service providers keep a check on which CPE is terminated on which DSLAM. Say for instance there are are 1000 CPEs out there, and there are 5 DSLAMS. How does an operator know, the terminating points of the CPE? Im trying to figure out how they troubleshoot when they suspect a problem. Say for instance a user calls and says that hes unable to browse, the operator figures (using his CPE management software) that this problem is not with the CPE or the configuration on the CPE but could be with the line card in the DSLAM.....what next, how is he able to find out where to look for? Do they do it manually?
I thought if by using the TR69 parameter ATUCVendor, he can retrieve the vendor name of the ATUC (or the dslam) using the CPE management software, but again all 5 dslams could be from the same vendor. So what next? Does this make sense?
18 years 4 weeks ago #17622
by Ranger24
Patience - the last reserve of the any engineer
Replied by Ranger24 on topic Re: DSLAM Basics
Hi Lady,
Your post makes great sense however I disagree with in parts. Having worked across Europe with several of the big operators I have yet to see TR69 implemented.
CPE management has to be split into 2 fields - Residential CPE & Business CPE.
For residential CPE there is currently very little management especially as the CPE can be changed by the user to any that supports the provided service. However once triple play & IPTV are delivered managemnt of the CPE & or Set top box does become an issue.
For Business customeres remote manageemnt of the CPE is a requirement - I have seen this implemented by establishing 2 VPIs to the CPE - 1 for traffic and 1 for management. Then the management VPI can be used by the management software.
In the scenario describe by your post you need to take a holistic view of the network & management tools. Typically operators will have a single CRM (customer relationship management) tool that contains details of the customer account & supplied services along with their network details - where they are geographically & which DSLAM they are connected to. (normally the CRM tools is heavily integrated with the Provisioning & configuration systems).
This allows 1st line technicians to identify the correct DSLAM and log in to it to perform initial diagnosis. This will involve confirming the customer connection (which linecard & port) and configured services (PPP, DHCP, IPTV, VOIP etc)
The first challenge is often "How am I sure I am looking at the right Connection?" Solved quite simply by operators ensuring each port is configured with a unique customer identifier - Account number / telephone number.
Once the correct port is identified then the traffic on the port can be analysed and often this can confirm if the CPE is configured correctly or not. The next step for a business customer would be to log into the CPE and check it out.
All troubleshooting needs to be sone from a system point of view, with the view that the DSLAM is the central point between CPE and B-RAS.
Help at all?
Your post makes great sense however I disagree with in parts. Having worked across Europe with several of the big operators I have yet to see TR69 implemented.
CPE management has to be split into 2 fields - Residential CPE & Business CPE.
For residential CPE there is currently very little management especially as the CPE can be changed by the user to any that supports the provided service. However once triple play & IPTV are delivered managemnt of the CPE & or Set top box does become an issue.
For Business customeres remote manageemnt of the CPE is a requirement - I have seen this implemented by establishing 2 VPIs to the CPE - 1 for traffic and 1 for management. Then the management VPI can be used by the management software.
In the scenario describe by your post you need to take a holistic view of the network & management tools. Typically operators will have a single CRM (customer relationship management) tool that contains details of the customer account & supplied services along with their network details - where they are geographically & which DSLAM they are connected to. (normally the CRM tools is heavily integrated with the Provisioning & configuration systems).
This allows 1st line technicians to identify the correct DSLAM and log in to it to perform initial diagnosis. This will involve confirming the customer connection (which linecard & port) and configured services (PPP, DHCP, IPTV, VOIP etc)
The first challenge is often "How am I sure I am looking at the right Connection?" Solved quite simply by operators ensuring each port is configured with a unique customer identifier - Account number / telephone number.
Once the correct port is identified then the traffic on the port can be analysed and often this can confirm if the CPE is configured correctly or not. The next step for a business customer would be to log into the CPE and check it out.
All troubleshooting needs to be sone from a system point of view, with the view that the DSLAM is the central point between CPE and B-RAS.
Help at all?
Patience - the last reserve of the any engineer
18 years 3 weeks ago #17643
by lady
Replied by lady on topic Re: DSLAM Basics
Thanks Ranger. That really helped. Do you have any idea what kind of CRMs they use?
About your first sentence, unfortunately, I have to completely disagree ) Im currently working on TR69 implementations on CPEs and CPE management softwares for Residential CPEs for European service providers and I dont see things slowing down at all.
About your first sentence, unfortunately, I have to completely disagree ) Im currently working on TR69 implementations on CPEs and CPE management softwares for Residential CPEs for European service providers and I dont see things slowing down at all.
Time to create page: 0.149 seconds