[168871] in North American Network Operators' Group
Re: SIP on FTTH systems
daemon@ATHENA.MIT.EDU (Mark Tinka)
Thu Feb 6 03:02:21 2014
From: Mark Tinka <mark.tinka@seacom.mu>
To: nanog@nanog.org
Date: Thu, 6 Feb 2014 10:01:14 +0200
In-Reply-To: <20140206071959.GH24602@besserwisser.org>
Reply-To: mark.tinka@seacom.mu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--nextPart2379466.2T0IlIyur3
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
On Thursday, February 06, 2014 09:19:59 AM M=E5ns Nilsson=20
wrote:
> 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.
There are, typically, three topology models for modern FTTH=20
(wireline, really) networks that a service provider could=20
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=20
each service (VLAN 10 for Internet/Unicast, VLAN 20 for=20
VoIP, VLAN 30 for IPTv/Multicast). This is simple and easy=20
to scale, but if one is using relatively "dumb" AN's (like=20
GPON's or MSAN's), it can be difficult to control how much=20
bandwidth customers need, and how they can roam between=20
services in the home (given CPE ties services to ports).
The CVLAN (1:1) model is good for identifying services and=20
bandwidth requirements on a per-customer basis. The main=20
problem with this model is that Multicast traffic gets=20
treated like Unicast, because each customer has a unique=20
VLAN for themselves, and as such, the upstream PE router=20
ends up having to replicate the same linear video stream as=20
many times as there are customers down the line.
The Hybrid model, where CVLAN's are used for all Unicast=20
traffic (Internet, VoIP and VoD, typically), and a single=20
SVLAN is used for all customers to handle Multicast traffic=20
(so-called MVLAN). The challenge here is if you're the type=20
of operator that likes to have a consistent set of address=20
per VLAN, it can become a little tricky if your VoIP service=20
is a walled-garden running on private IP space, given it=20
shares the same VLAN as Internet and VoD which would=20
normally run on public IP space.
The N:1 SVLAN model is quite simple and scalable for=20
wholesale FTTH services.=20
There is product from some vendors, now, that is built with=20
=46TTH in mind. 1U, dense switches (Active-E) that support=20
(reasonably) proper QoS and bandwidth management controls on=20
customer- and core-facing ports, at Layer 2. So that offers=20
you a lot more capability at the AN, and you can manage=20
bandwidth as close to the customer as possible, unlike=20
typical GPON deployments which may not have these features,=20
leaving you to apply bandwidth policy at the PE router -=20
much too far up the line.
These new products can also support split horizons across=20
bridge domains (which GPON's and DSLAM's do today), meaning=20
that customers can use the same SVLAN's, but can only=20
communicate via the upstream router (Layer 3), eliminating=20
risk associated with Layer 2 visibility between customers=20
connected to the same bridge domain.
Cheers,
Mark.
--nextPart2379466.2T0IlIyur3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iQIcBAABAgAGBQJS80FQAAoJEGcZuYTeKm+GLJIQAK7ej7pLTfqygBVNDCSJ2kUO
WnYdLDXGZzbZblsV2IuGw91VzWiQ6PsFZgLzFInt1n4jj2Qadma8sz8HdxtBT+zy
gCpZyCW2aA9TjJ1M5U9zcdCHiniDiTwlg37HFZ7tqP++sPWARexYk5pF/PpSDvs5
TKFI+4ot0ZCkFcZysnuqUvtPU0kK46/uuosHmmJb44HUXS2uHPpxItDVwb4fbJYc
IKuJrabAZ19oHQUqf6KWQ9PevOHGe1QN2cXzTm7YYzJIJsfl3F7eSnXpCdQ90SVM
b7hmMCqFTaC8GGXTaIu1EYULmI2Kjtj/NabgZXVBFTtbghyjz4FlVtqG0rDN/E37
p+y7wXXrk5tcf89dRGNqMEQJU1v4yUFDOARc/ODaTl+C83aonG0Ibsbbcin61DN+
L0Elig+M2x7HLuE0r7lJBMANMqexQ7WzHxPDEru/6MfHeDFR8y48ehhbsC06PT+d
8o/SD6w5b+BGD63CRYrx1qc3Tv8oAAJ9Tn2jgg8c7hLhv0kibRVOuj68Q/U/C8FW
OQ5q7F5p7o68DAJpCnn1BTRkRDTXQ9QwM4Pe6Z4V796Wewp+k1TL0/igr77bRtAj
Xxv4HjilT3Eokkgzh8oGhf7+b2UKUdi3RQvX2Gd4KCuUsiLrgHN2m1cSyHV9jmXq
UJyK6RyKf7yC7aPF11Yv
=rdFC
-----END PGP SIGNATURE-----
--nextPart2379466.2T0IlIyur3--
