how-to block ads
|
|
Uniqs:
227 |
Share Topic
 |
 |
|
|
approval from:
fAcEtIOUs 
| The issue is everywhere. If you look at this data and combine it with some telecom knowledge, you understand BC's major projects that impact xDSL services:
A remote or subtended shelf is linked with 1 or 2 155Mbps OC-3 links. If one of these can have up to 144 ports, you see the issue. Back when speeds where 1.5Mbps, this wasn't an issue, and not all shelves or RT's will have high subscription rates, and those that do will more likely have been upgraded with the sort-of-fix: Dual gig-e fed Stingers with VDSL2 LIM's (3X48 Ports, I9450 chipset). But the issue here is that much of this extra bandwidth will be reserved for IPTV, so DPI/QoS will still be used. At least they will all have the Gige uplinks in a LAG that can gracefully fail over to a single link.
Next the aggregation: this is simple... the upstream Al-Lu equipment that most dslams connect to is ATM based with a pair of relatively slow OC-12 uplinks, and these can feed 48 subtended stingers. This is also being upgraded for the future that has multicast/IGMP and ethernet rather than ATM to support IPTV. The aggregation layer also goes from OC-12/48 to Gige that probably go to a Nortel 8600 edge router, then onto core routers.
**DPI by ellacoya/arbor is now inserted here before or after the BAS. Has slow Gige interfaces considering how much traffic there is, so 10GE upgrades are coming**
Finally, the BAS/SMS servers after which traffic exits onto the 3rd party networks (Gateway Access Service, Teksavvy, etc.). These are servings thousands of clients and aren't exactly crazy fast... Juniper 1410/1440. These will also likely move to E320's which have better throughput, faster interfaces and backplanes and best of all, more redundancy and better failover.
So yes, DPI sucks, especially since the system doesn't apply it only to the clients from congested elements, but to any PPPoE xDSL user. But it is needed to alleviate congestion to a degree, especially until next generation infrastructure is implemented. | | |
|
 R0CKYTSI RockyPremium,VIP
join:2005-05-19
Chatham, ON
1 edit | said by Bellus_today :
If you look at this data and combine it with some telecom knowledge, you understand BC's major projects that impact xDSL services:
A remote or subtended shelf is linked with 1 or 2 155Mbps OC-3 links. If one of these can have up to 144 ports, you see the issue. Back when speeds where 1.5Mbps, this wasn't an issue, and not all shelves or RT's will have high subscription rates, and those that do will more likely have been upgraded with the sort-of-fix: Dual gig-e fed Stingers with VDSL2 LIM's (3X48 Ports, I9450 chipset). But the issue here is that much of this extra bandwidth will be reserved for IPTV, so DPI/QoS will still be used. At least they will all have the Gige uplinks in a LAG that can gracefully fail over to a single link.
Next the aggregation: this is simple... the upstream Al-Lu equipment that most dslams connect to is ATM based with a pair of relatively slow OC-12 uplinks, and these can feed 48 subtended stingers. This is also being upgraded for the future that has multicast/IGMP and ethernet rather than ATM to support IPTV. The aggregation layer also goes from OC-12/48 to Gige that probably go to a Nortel 8600 edge router, then onto core routers.
**DPI by ellacoya/arbor is now inserted here before or after the BAS. Has slow Gige interfaces considering how much traffic there is, so 10GE upgrades are coming**
Finally, the BAS/SMS servers after which traffic exits onto the 3rd party networks (Gateway Access Service, Teksavvy, etc.). These are servings thousands of clients and aren't exactly crazy fast... Juniper 1410/1440. These will also likely move to E320's which have better throughput, faster interfaces and backplanes and best of all, more redundancy and better failover.
So yes, DPI sucks, especially since the system doesn't apply it only to the clients from congested elements, but to any PPPoE xDSL user. But it is needed to alleviate congestion to a degree, especially until next generation infrastructure is implemented.
One could agree with some parts of this if first off we, TekSavvy, weren't on AGAS circuits (Ethernet, which was not part of the disclosure for some reason) and second, if Bell had put a timeline on this. They planned on leaving this in permanently. This wasn't a temporary situation but rather a permanent control mechanism............. Two much different situations.
Edit: Maybe see these discussions to get an appreciation for the situation: »The Bell Disclosure!
--
TSI Rocky - TekSavvy Solutions Inc. | |
|
