SIP on FTTH systems

Mark Tinka mark.tinka at
Thu Feb 6 12:42:39 UTC 2014

On Thursday, February 06, 2014 02:29:40 PM Mikael 
Abrahamsson wrote:

> I disagree on that one as well. It might be in some
> markets, but it's not in all.

I keep using the word "typical", but not sure if you're 
missing it.

Typical, not limited to, i.e., common, but not the only 

I'm basing this on what I've seen in various countries 
across a few continents I've worked in.

> This wasn't incumbents specifically, but just a different
> model to achieve the same thing, give end users access
> to multiple ISPs, multiple "cable TV" vendors, and
> multiple VOIP providers through a neutral network.

Again, just an example I gave, not to say it was the norm.

The countries I was referring to is where the incumbents 
either owned the infrastructure and were reluctant to open 
it up to competitors, or were awarded national broadband 
projects to deploy and run the infrastructure but were not 
specifically governed to how low the OSI Layer they can open 
up the infrastructure to.

In other places, it is a business model, in addition to more 
traditional ways of unbundling. These tend to be more 
evolved markets, but again, not limited to.

> What do you mean by subscriber management? This worked 10
> years ago, what problem are you saying has been solved
> recently?

End user authentication and management typically being done 
via PPPoE because that was the best and most secure way to 
manage customer connections (for some operators, still is).

By DHCP I mean an alternative to PPPoE-based authentication 
where Option 82 and friends can allow service providers to 
authenticate customers based on AN port, MAC address, VLAN 
ID, e.t.c., instead of username/password a la PPPoE. This 
gets passed as part of initial DHCP transactions.

Rethinking your comment (because I thought you meant DHCP as 
the way to go for subscriber management when you debunked 
PPPoE) I'm guessing you refer to simply assigning IP 
addresses to customer interfaces in FTTH scenarios? No?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the NANOG mailing list