SIP on FTTH systems

Mailman List Mirror (Read Only)
1

Quick question:

I am thinking in a possible wholesale FTTH environment operated by a
telco where the end user is connected to ISP-X via PPPoE.

ONTs have built-in ATAs that can provide POTS service to a house and do
SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through.

In a scenario where the data PPPoE connection is done by an external
router, what are the options to operate the VoIP service so that

- VoIP still uses the special lane on the GPON with QoS

- VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is
not involved in routing such traffic or allocating an IP address ?

Is the only option to program the ONT to establish its own PPPoE session
to the ISP that carries only SIP traffic (and can such a setup make use
of the special "lane" reserved for VoIP traffic ? on the gPON system ?)

What other scenarios exist ?

In normal incumbent-only FTTH systems, does the OLT provision a special
IP to the ATA via DHCP and intercepts that traffic to hand off to a
local SIP server and never touches the internet ?

In the USA, do CLECs have access to homes served only by FTTH ? If so,
how it is accomplisehd ?

2

In our vendor's implementation, the main access shelf hands out IPs to the
"ATAs" integrated in the ONTs over a separate VLAN. No PPPoE required.

Frank

3

Thanks. This would imply that in a wholesale environment, use of the
integrated ATA would have to be charged separatly with the telco then
handing off SIP traffic from the OLT to (likely) a nearby CLEC SIP
server that is colocated (or pay for transit to internet to reach
distant SIP server)

I know that in the australian NBN plan, they do charge separatly to
access the "dedicated" VoIP service, but this is meant more as a means
to access the QoS managed bandwidth than to deal with handoff and IP
management service that is performed locally instead of by the ISP.

4

Quick question:

I am thinking in a possible wholesale FTTH environment operated by a
telco where the end user is connected to ISP-X via PPPoE.

ONTs have built-in ATAs that can provide POTS service to a house and do
SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through.

In a scenario where the data PPPoE connection is done by an external
router, what are the options to operate the VoIP service so that

- VoIP still uses the special lane on the GPON with QoS

- VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is
not involved in routing such traffic or allocating an IP address ?

Or, one could make sure everything has a globally unique IP address and is
using reasonably secured communications. The downside is that one
then can't defend the existence of those empire-building middleboxes. It
is not the telco way, so is of course unthinkable. Like anything beyond
WAP was on cell phones a decade ago.

  Warum soll man es einfach machen,
  wenn man es so schön komplizieren kann?

  (Why make things simple when you can
   build them so beautifully complicated?)

5

There are, typically, three topology models for modern FTTH
(wireline, really) networks that a service provider could
deploy:

  1. SVLAN N:1 model
  2. CVLAN 1:1 model
  3. Hybrid of both

The SVLAN (N:1) model is simple; just have a single VLAN for
each service (VLAN 10 for Internet/Unicast, VLAN 20 for
VoIP, VLAN 30 for IPTv/Multicast). This is simple and easy
to scale, but if one is using relatively "dumb" AN's (like
GPON's or MSAN's), it can be difficult to control how much
bandwidth customers need, and how they can roam between
services in the home (given CPE ties services to ports).

The CVLAN (1:1) model is good for identifying services and
bandwidth requirements on a per-customer basis. The main
problem with this model is that Multicast traffic gets
treated like Unicast, because each customer has a unique
VLAN for themselves, and as such, the upstream PE router
ends up having to replicate the same linear video stream as
many times as there are customers down the line.

The Hybrid model, where CVLAN's are used for all Unicast
traffic (Internet, VoIP and VoD, typically), and a single
SVLAN is used for all customers to handle Multicast traffic
(so-called MVLAN). The challenge here is if you're the type
of operator that likes to have a consistent set of address
per VLAN, it can become a little tricky if your VoIP service
is a walled-garden running on private IP space, given it
shares the same VLAN as Internet and VoD which would
normally run on public IP space.

The N:1 SVLAN model is quite simple and scalable for
wholesale FTTH services.

There is product from some vendors, now, that is built with
FTTH in mind. 1U, dense switches (Active-E) that support
(reasonably) proper QoS and bandwidth management controls on
customer- and core-facing ports, at Layer 2. So that offers
you a lot more capability at the AN, and you can manage
bandwidth as close to the customer as possible, unlike
typical GPON deployments which may not have these features,
leaving you to apply bandwidth policy at the PE router -
much too far up the line.

These new products can also support split horizons across
bridge domains (which GPON's and DSLAM's do today), meaning
that customers can use the same SVLAN's, but can only
communicate via the upstream router (Layer 3), eliminating
risk associated with Layer 2 visibility between customers
connected to the same bridge domain.

Cheers,

Mark.

6

Time for users to consider splitting L2 services from IP ?

Christian de Larrinaga

7

But consumer broadband is all about IP; the Layer 2 is
needed to transport that IP, and that's a network problem,
not a user one.

Mark.

8

There are more. There are models where each ISP gets its own customer vlan and L2 equipment do inspection of ARP/ND and does security filtering on L2/L3 using this information. There are also L3 networks where the traffic is source-routed out to the correct ISP, or each ISP gets its own VRF in the equipment and it's VRF a long way out.

To the original poster. People using PPPoE for FTTH makes me sad. When someone suggests this, please just say "go back to the drawingboard, redo it right".

9

There are more. There are models where each ISP gets its
own customer vlan and L2 equipment do inspection of
ARP/ND and does security filtering on L2/L3 using this
information. There are also L3 networks where the
traffic is source-routed out to the correct ISP, or each
ISP gets its own VRF in the equipment and it's VRF a
long way out.

Agree.

The models I listed are typical to an operator that runs its
own infrastructure (including the FTTH last mile), and does
not necessarily wholesale out to other operators.

I've seen certain countries that have given the incumbents
leeway to wholesale at the IP level, which the incumbent
likes because they "perceive" more control than if they had
to hand-off Layer 2 wholesale. In such cases, VRF's and/or
logical routers have been deployed.

To the original poster. People using PPPoE for FTTH makes
me sad. When someone suggests this, please just say "go
back to the drawingboard, redo it right".

Agree. DHCP really is the way to go, now. Plus, there is
good support for IPv6 with vendors today re: DHCP-based
subscriber management.

Mark.

10

The models I listed are typical to an operator that runs its own infrastructure (including the FTTH last mile), and does not necessarily wholesale out to other operators.

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

I've seen certain countries that have given the incumbents leeway to wholesale at the IP level, which the incumbent likes because they "perceive" more control than if they had to hand-off Layer 2 wholesale. In such cases, VRF's and/or logical routers have been deployed.

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.

Agree. DHCP really is the way to go, now. Plus, there is good support for IPv6 with vendors today re: DHCP-based subscriber management.

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

11

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
option.

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?

Mark.

12

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).

Why do you need to authenticate the customer? Don't your documentation system know the port/subscriber mapping? And why is this secure, instead of being tied to a physical connection the customer can now take the credentials and move? If the credentials are stolen, someone else can impersonate that customer.

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.

This worked 10 years ago, it's nothing recent.

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?

Yes? Since option 82 and friends gives you what port the DHCP request came in on, you now log IP/MAC connected to a port, and since you know to what apartment/house this port is physically connected to, nothing more is needed.

13

Why do you need to authenticate the customer? Don't your
documentation system know the port/subscriber mapping?
And why is this secure, instead of being tied to a
physical connection the customer can now take the
credentials and move? If the credentials are stolen,
someone else can impersonate that customer.

Which is why I said DHCP was better than PPPoE.

Failing to see where we disagree.

This worked 10 years ago, it's nothing recent.

In my previous post, I didn't say it was recent. I said it
was better than PPPoE if you're deploying FTTH now. What I
said was recent was that DHCP_IA and DHCP_IA_PD
implementation has improved significantly both in BNG's as
well as CPE.

Again, failing to see where we disagree.

Yes? Since option 82 and friends gives you what port the
DHCP request came in on, you now log IP/MAC connected to
a port, and since you know to what apartment/house this
port is physically connected to, nothing more is needed.

Again, don't see where we disagree.

This is a good thing.

Some operators provide services with no subscriber
management (i.e., no PPPoE, no DHCP; just a static IP
address documented about where it is, what street, what
building, what floor, what apartment, what customer), while
other service providers have a subscriber management
technique, PPPoE or DHCP, to log all the same information in
concert with the backend.

I'm just saying DHCP is better than PPPoE if you're
greenfielding FTTH deployments today, and I'm not sure you
entirely disagree.

Mark.

14

We're in violent agreement it seems. My only beef was that it seemed like you were implying this was something new.

15

This is a deep hole, and basically does not work with IPv6.

You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection, RA guard and more. One VLAN per customer and a separate multicast is much simpler.

Or do something bold, run L3 at the edge :slight_smile:

/Anders

16

We're in violent agreement it seems.

Tend to agree.

My only beef was
that it seemed like you were implying this was something
new.

In most of my travels, there is a healthy amount of
resistance toward DHCP from new (but mostly, existing)
broadband service providers when choosing between DHCP and
PPPoE for Unicast traffic. And the reasons for this vary -
we saw the OP is PPPoE-biased, for example.

It is better in 2014 than it was in 2011 in those places,
but by and large, DHCP adoption for subscriber management is
not moving as quickly as one would think, especially when
you consider all the FTTH work going on around the world.

Mark.

17

This is a deep hole, and basically does not work with
IPv6.

You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6
inspection, RA guard and more. One VLAN per customer and
a separate multicast is much simpler.

If you have a reasonably intelligent AN (like some of
today's Active-E devices), you can create so-called split
horizons on the same bridge domain (VLAN, really) where
customers will only communicate via the upstream BNG at
Layer 3.

At Layer 2, even though they are all sitting on the same
VLAN, there is no inter-communication between them.

I've also know Huawei OLT's support these split horizons
too.

Or do something bold, run L3 at the edge :slight_smile:

BNG's are too big to distributed that deeply, even in
distributed BNG designs. This would get costly.

Cheap switches that have decent IP/MPLS support are mostly
geared toward Metro-E deployments, i.e., business-grade
services. So they are quite poor with regard to susbcriber
management features and capabilities.

Mark.

18

Or do something bold, run L3 at the edge :slight_smile:

BNG's are too big to distributed that deeply, even in
distributed BNG designs. This would get costly.

You don't need a BNG. You need an L3 switch as the first hop the customer is talking to.

Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities.

If you have L3-in-vlan-per-customer at the first hop then you don't really need all of that. If you include rudimentary VRF support then you can even support wholesale. /64 per customer, DHCPv6(-PD) server support in the L3 switch and you're good to go. There is equipment that already claim to do this (I never got to test their implementation based on my requirements because I switched jobs, but they claimed to have implemented everything last year).

19

You don't need a BNG. You need an L3 switch as the first
hop the customer is talking to.

Fine for FTTB, but not for FTTH where you're serving tens-
to-hundreds-of-thousands of customers.

If your FTTH deployments are low scale (measure of low or
large scale depends on each operator's point of view), the
case for doing without subscriber management technologies
can be made.

If you have L3-in-vlan-per-customer at the first hop then
you don't really need all of that. If you include
rudimentary VRF support then you can even support
wholesale. /64 per customer, DHCPv6(-PD) server support
in the L3 switch and you're good to go.

I'm curious; in these deployments, what kind of customer
scale are you talking about? When someone says FTTH, I'm
thinking thousands and thousands of customers, in which case
not having a scalable susbcriber management system as well
as not having a scalable customer termination topology could
be difficult. Unless I misunderstand...

There is
equipment that already claim to do this (I never got to
test their implementation based on my requirements
because I switched jobs, but they claimed to have
implemented everything last year).

Modern Metro-E switches that support full IP/MPLS in the
Access have a lot of good IPv4 and IPv6 features, including
DHCP_IA and DHCP_IA_PD, but again, these are more FTTB- than
FTTH-focused, if you're talking about scale.

Cheers,

Mark.

20

You don't need a BNG. You need an L3 switch as the first
hop the customer is talking to.

Fine for FTTB, but not for FTTH where you're serving tens-
to-hundreds-of-thousands of customers.

Why?

If your FTTH deployments are low scale (measure of low or large scale depends on each operator's point of view), the case for doing without subscriber management technologies can be made.

Why is it different?

I'm curious; in these deployments, what kind of customer scale are you talking about? When someone says FTTH, I'm thinking thousands and thousands of customers, in which case not having a scalable susbcriber management system as well as not having a scalable customer termination topology could be difficult. Unless I misunderstand...

Yes, this is for hundreds of thousands of customers. Why do you need customer management? You document where a certain fiber goes to (what port), and then this port goes to a certain customer. That is the only customer management you need.

So you provision your L3 switch with a protocol based 0x86dd vlan per port, put a static /64 L3 subinterface into this vlan, then you have a built in DHCPv6(-PD) server in the same switch that hands out a static /56 on this vlan, plus hands out DNS-resolver etc. No dynamics, just static. You provision ACLs to only allow the /56, /64 and LL in on the L3 interface. You set ND cache max size to 20-50 entries per L3 subinterface to protect the 1024-2048 entries or whatever the L3 switch can handle. For IPv4 you need to do all the L2/L3-inspection magic in a common vlan.

This is now a standalone unit and you don't need any central system to stay up and running in order to move IPv6 packets, and you support both directly attached computer or a residential gateway that wants PD.

I did this type of DSL deplayment early 2000nds with an L3 switch and an ethernet DSLAM as media converter. This was obviously IPv4 only, but worked very well. At the same time the guys with central DHCP systems had a lot of country wide outages when the DHCP system went belly-up.

I only a few years later learnt what an LNS was when I talked to someone else who did more of a "follow-the-whitepaper" deployment of DSL.

Modern Metro-E switches that support full IP/MPLS in the Access have a lot of good IPv4 and IPv6 features, including DHCP_IA and DHCP_IA_PD, but again, these are more FTTB- than FTTH-focused, if you're talking about scale.

I would never want to have MPLS that far out into the network.