SIP on FTTH systems
mark.tinka at seacom.mu
Thu Feb 6 12:42:39 UTC 2014
On Thursday, February 06, 2014 02:29:40 PM Mikael
> 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
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
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...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the NANOG