DSLAM and FTTP

Do DSLAM's have a role in FTTP (ie managing the line speed) or are they just used for copper lines ?

If not, is there similar tecnology that regulates line speeds on FTTP ?

In reply to a post by marpoint:

Do DSLAM's have a role in FTTP (ie managing the line speed) or are they just used for copper lines ?

If not, is there similar tecnology that regulates line speeds on FTTP ?

No DSLAMs are not used in the Openreach FTTP network, its completely passive between the exchange (where its connected to a OLT) and the customer property (where its connected to a ONT) there is a splitter between these two points but that uses mirrors I believe to split the fibre 32 ways.

Edited by deleted (Sat 27-Feb-21 10:06:07)

In reply to a post by marpoint:

If not, is there similar tecnology that regulates line speeds on FTTP ?

As noted above its the OLT (Optical Line Termination) that is configured and determines the downstream / upstream bandwidths and configures this with the ONT (Optical Network Termination) sometimes also called the ONU by some equipment vendors.

The ONT is effectively the 'optical modem' for want of better description in your home/premises.

For Openreach based FTTP the PON network is aggregated at the OLT which is located in the GEA Headend exchange - not necessarily your nearest local exchange.

Just to add to the above: the line bitrate (what you think of as "sync speed" in DSL) is *fixed* on FTTP. For most GPON networks, including Openreach FTTP, it's 2.4Gbps downstream, 1.2Gbps upstream.

There is no rate adaptation based on line conditions: either it works, or it doesn't. The network is designed so that the light lost over the fibre is within the "optical budget" of allowable loss.

Downstream and upstream are simultaneous, as they're on different wavelengths, but individual ONTs on the same splitter have to take it in turns to transmit upstream. This is controlled by the OLT, which allocates timeslots.

The service data rate you get is controlled by the OLT shaping traffic. Roughly speaking, delays are inserted between packets, to ensure that overalll you don't receive or send data faster than the service you paid for.

Except if there is a subtended headend in the DSLAM.

That’s indeed correct...but to provide some context to the OP, in terms of providing a simple explanation of the essential difference between FTTP and FTTC Openreach architectures - sub-tended FTTP headends are the (quite rare) exception rather than the rule

In reply to a post by witchunt:

Except if there is a subtended headend in the DSLAM.

When I was typing my post I was thinking to myself should I over complicate my post by making reference to a subtended headend which are probably only in a very low percentage of DSLAMs, I thought I better not but knew someone else would to be very honest I never in a million years expected it to be you

Where are service tiers enforced? Is the ONT performing rate limiting of upstream traffic or is each ONT allowed to transmit in the allocated time slot and packets above the provisioned rate are discarded/buffered further into the network?

In reply to a post by candlerb:

Downstream and upstream are simultaneous, as they're on different wavelengths, but individual ONTs on the same splitter have to take it in turns to transmit upstream. This is controlled by the OLT, which allocates timeslots.

The service data rate you get is controlled by the OLT shaping traffic. Roughly speaking, delays are inserted between packets, to ensure that overalll you don't receive or send data faster than the service you paid for.

What's to stop you giving everyone else on your splitter a "really bad day" by abusing the fibre and preventing them from being able to establish connections? How are Openreach able to deal with such situations? Thinking it could be a faulty ONT, or could be a malicious attack to take someone offline.

In reply to a post by jpm:

Where are service tiers enforced? Is the ONT performing rate limiting of upstream traffic or is each ONT allowed to transmit in the allocated time slot and packets above the provisioned rate are discarded/buffered further into the network?

See page 9 for downstream and page 21, 22 for upstream....

https://www.openreach.co.uk/cpportal/content/dam/cpp...

In reply to a post by jimbof:

In reply to a post by candlerb:

Downstream and upstream are simultaneous, as they're on different wavelengths, but individual ONTs on the same splitter have to take it in turns to transmit upstream. This is controlled by the OLT, which allocates timeslots.

The service data rate you get is controlled by the OLT shaping traffic. Roughly speaking, delays are inserted between packets, to ensure that overalll you don't receive or send data faster than the service you paid for.

What's to stop you giving everyone else on your splitter a "really bad day" by abusing the fibre and preventing them from being able to establish connections? How are Openreach able to deal with such situations? Thinking it could be a faulty ONT, or could be a malicious attack to take someone offline.

1. VLAN tagging
2. Prioritisation and queuing
3. Traffic shaping

In reply to a post by Pheasant:

1. VLAN tagging
2. Prioritisation and queuing
3. Traffic shaping

Those are all IP layer measures. I mean, at a more fundamental level, given this is - if I understand correctly - effectively a shared light pipe from 32 houses to one port at the exchange, what's to stop that being ruined by a badly behaved device at one end flooding the fibre with light all the time?

ONTs only transmit when they're given permission by the OLT. In theory, it's possible for an ONT to go off the rails and blat over everyone as you say. But in practice I've never heard of ONTs failing in that way.

As I understand it, the transmit control is quite sophisticated, and even takes into account the different distances (and hence round-trip times) between each ONT and the OLT.

I did see similar problems occasionally in the old days of 10base2 networks (we're talking 1990's here), when a NIC went bad and started transmitting continuously. But shared ethernet is different: devices just wait until they see a quiet line before they transmit, and are not being given explicit permission to transmit.

In reply to a post by witchunt:

Except if there is a subtended headend in the DSLAM.

Being pedantic, I'd say "cabinet" there. A "DSLAM" provides a DSL (copper) service.

Edited by candlerb (Sat 27-Feb-21 19:56:20)

In reply to a post by jimbof:

In reply to a post by Pheasant:

1. VLAN tagging
2. Prioritisation and queuing
3. Traffic shaping

Those are all IP layer measures. I mean, at a more fundamental level, given this is - if I understand correctly - effectively a shared light pipe from 32 houses to one port at the exchange, what's to stop that being ruined by a badly behaved device at one end flooding the fibre with light all the time?

I can imagine a couple of brute force scenarios, but the reality is the absolute risk is very low and could be quite easily traced. Even if a single PON was “attacked” - the total affected customers is still relatively low.

In reply to a post by candlerb:

....in the old days of 10base2 networks (we're talking 1990's here), when a NIC went bad and started transmitting continuously. But shared ethernet is different: devices just wait until they see a quiet line before they transmit, and are not being given explicit permission to transmit.

Thank goodness both 10Base2 and 10Base5 were dying out as I got into work. One poor terminator or dicky BNC connector could bring down an entire segment.

The other day someone mentioned “broken ring” as a moniker for TR. I had a good chuckle.

UTP and switched Ethernet transformed local area networking.

In reply to a post by Pheasant:

Thank goodness both 10Base2 and 10Base5 were dying out as I got into work. One poor terminator or dicky BNC connector could bring down an entire segment.

I used to admin a school network, the kids would steal the BNC's, it was a nightmare

The other day someone mentioned “broken ring” as a moniker for TR. I had a good chuckle.

UTP and switched Ethernet transformed local area networking.

My company was 16Mbps TR for ages, mostly retrofit over structured cabling for the newer buildings, the older ones had the IBM Type1 ports, and we all had adaptors. Even with laptops and a PCMCIA TR card. Thankfully this was all ripped out for switched Ethernet.

16 Mbps TR was slightly faster than 100 Mbps hub Ethernet, it was switching and volume that killed TR. I read IBM sold the patents to Cisco, whom promptly buried them

Oh yeah I remember good old IBM Type 1 thick as your middle finger and about as flexible and the “self healing” connectors to physically close the ring on the TR hubs.

We were ripping it out by the truckload in CBD high rise offices in Sydney in the early nineties and replacing it with new fangled Category 3 and 5! We still kept the TR going and just used Type 1 plug adapters into the structured cabling Those were the days. I guess that was all old world big blue before they fancied themselves and refashioned themselves from a hardware company to a “services” organisation.....

I remember as a summer job after leaving school I setup my uncles office, must’ve been around 1990/91 and cabling it with thinnet. A few years later we ripped out the coax and star wired with Krone Cat 5 as I recall and used HP 100VG AnyLAN gear. Must’ve been around 93/94 or something like that.

In reply to a post by jimbof:

In reply to a post by Pheasant:

1. VLAN tagging
2. Prioritisation and queuing
3. Traffic shaping

Those are all IP layer measures. I mean, at a more fundamental level, given this is - if I understand correctly - effectively a shared light pipe from 32 houses to one port at the exchange, what's to stop that being ruined by a badly behaved device at one end flooding the fibre with light all the time?

Nothing.

Which is probably why Openreach don’t allow third party ONTs for residential customers; they always provide and manage the ONT.

It’s worth noting that GPON is a huge improvement relative to ADSL/VDSL2 services, where a malicious actor or completely unrelated hardware can disrupt service for hundreds of subscribers with simple RF interference. Just look at the recent news story about a village that kept losing broadband services that was finally traced to a single malfunctioning television!

GPON has two key advantages versus DSL; physical access to the fibre is required to interfere with the signal, and all data is encrypted. It’s not perfect, but it’s a massive leap forwards for residential services.

In reply to a post by jimbof:

.. , what's to stop that being ruined by a badly behaved device at one end flooding the fibre with light all the time?

In reply to a post by Pheasant:

I can imagine a couple of brute force scenarios, but the reality is the absolute risk is very low and could be quite easily traced. Even if a single PON was “attacked” - the total affected customers is still relatively low.

Examples of analysis tools to track and trace rogue ONT/U’s...

https://youtu.be/9zPcbumcKzA

https://vimeo.com/262706881

Edit: Huawei’s rogue ONT detection process explanation:
https://forum.huawei.com/enterprise/en/huawei/m/View...

Edited by Pheasant (Sat 27-Feb-21 22:10:19)

In reply to a post by DougM:

GPON has two key advantages versus DSL; physical access to the fibre is required to interfere with the signal, and all data is encrypted. It’s not perfect, but it’s a massive leap forwards for residential services.

All neighbours probably have access to the same fibre though. I guess it's a matter of weighing the simplicity of a system that has street-furniture mounted electronics vs electronics only at customer premises and head end exchange.

In reply to a post by Pheasant:

Examples of analysis tools to track and trace rogue ONT/U’s...

https://youtu.be/9zPcbumcKzA

https://vimeo.com/262706881

Edit: Huawei’s rogue ONT detection process explanation:
https://forum.huawei.com/enterprise/en/huawei/m/View...

Thanks. These approaches all seem to rely on the devices being (reasonably) well behaved it seems.
One of the slides in the first presentation filled me with dread - that the challenge is understanding the issue is not with the equipment at the reporting customer's premises.

In reply to a post by jimbof:

In reply to a post by DougM:

GPON has two key advantages versus DSL; physical access to the fibre is required to interfere with the signal, and all data is encrypted. It’s not perfect, but it’s a massive leap forwards for residential services.

All neighbours probably have access to the same fibre though. I guess it's a matter of weighing the simplicity of a system that has street-furniture mounted electronics vs electronics only at customer premises and head end exchange.

In reply to a post by Pheasant:

Examples of analysis tools to track and trace rogue ONT/U’s...

https://youtu.be/9zPcbumcKzA

https://vimeo.com/262706881

Edit: Huawei’s rogue ONT detection process explanation:
https://forum.huawei.com/enterprise/en/huawei/m/View...

Thanks. These approaches all seem to rely on the devices being (reasonably) well behaved it seems.
One of the slides in the first presentation filled me with dread - that the challenge is understanding the issue is not with the equipment at the reporting customer's premises.

Have you had issues with your FTTP or are you just 'theorising' these faults?

In reply to a post by Pheasant:

Have you had issues with your FTTP or are you just 'theorising' these faults?

It's not installed yet. I'm interested to see how it works - in general it is worth understanding the possible points of failure.

No need to be so incredulous - that gear exists for detecting some of these fault conditions seems to me to indicate they're not as rare as you might think...

In reply to a post by jimbof:

In reply to a post by Pheasant:

Have you had issues with your FTTP or are you just 'theorising' these faults?

It's not installed yet. I'm interested to see how it works - in general it is worth understanding the possible points of failure.

No need to be so incredulous - that gear exists for detecting some of these fault conditions seems to me to indicate they're not as rare as you might think...

Politely you’re overthinking it. FTTP is way more reliable than FTTC. Take it from me, I’ve had lightning strike that fried practically everything. ONT was a bit [censored] on the Ethernet port (refused to connect at 1000baseT only at 100BaseT but it was otherwise working.

I’ve honestly never heard of anyone having an ONT fault that effectively nuked the PON. Of course nothing is bulletproof (or impossible) but the probability is that the issues will be far more mundane...like the dude last week with insects in his CSP. Or a branch through the overhead fibre....

Edited by Pheasant (Sun 28-Feb-21 20:50:19)

With respect, I'm not overthinking anything, I don't think these things are even particularly likely, I'm just interested to know how things work and how they may fail.

Luckily for me all my fibre runs will be underground except it looks like the last foot or so. Our FTTC cabinet is on a relatively busy city centre street so that has far more chance of being driven into, pee'd in, etc etc.

In reply to a post by jimbof:

With respect, I'm not overthinking anything, I don't think these things are even particularly likely, I'm just interested to know how things work and how they may fail.

Luckily for me all my fibre runs will be underground except it looks like the last foot or so. Our FTTC cabinet is on a relatively busy city centre street so that has far more chance of being driven into, pee'd in, etc etc.

In terms of deliberate or malicious intent. A bit of digging reveals some white hat security vulnerabilities on particular French GPON implementations a few years ago. Note that there has no immediate correlation to any present day GPON here in the UK, but nonetheless makes for interesting reading....

https://pierrekim.github.io/blog/2016-11-01-gpon-ftt...

My reading of the above is as a ‘theoretical’ discovery into the means to obtain ‘free’ gigabit capable service rather than service disruption itself. Although the author claims to have contacted Orange about the vulnerabilities....

Other brute force techniques (that could see you in front of a magistrate) could simply involve injecting 1310 nm light in the upstream. That would be akin to operating a radio frequency jammer on GPS, mobile or other terrestrial frequencies - so a a pretty quick way to land yourself in deep [censored]. Wouldn’t be that hard to work out who either...

In terms of equipment failure, there is little to suggest that the optics/lasers used inside ONT/ONUs could suddenly and unexpectedly fail ‘on’ / effectively get stuck transmitting ‘1’. Indeed proactive and reactive monitoring in the OLT should see any unexpected optical behaviour and send shutdown messages to the ONU before it becomes a potential nuisance. Otherwise I guess it’s an engineer visit to replace it.

As said all rather esoteric and rather theoretical, and rather more mundane failures in the outside plant would be waaaaay more likely.

Enjoy your connection when it arrives. 👍😀