[168872] in North American Network Operators' Group
Re: SIP on FTTH systems
daemon@ATHENA.MIT.EDU (cdel.firsthand.net)
Thu Feb 6 04:57:19 2014
In-Reply-To: <201402061001.21028.mark.tinka@seacom.mu>
From: "cdel.firsthand.net" <cdel@firsthand.net>
Date: Thu, 6 Feb 2014 09:56:45 +0000
To: "mark.tinka@seacom.mu" <mark.tinka@seacom.mu>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Time for users to consider splitting L2 services from IP ?=20
Christian de Larrinaga
> On 6 Feb 2014, at 08:01, Mark Tinka <mark.tinka@seacom.mu> wrote:
>=20
> On Thursday, February 06, 2014 09:19:59 AM M=C3=A5ns Nilsson=20
> wrote:
>=20
>> 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.
>=20
> There are, typically, three topology models for modern FTTH=20
> (wireline, really) networks that a service provider could=20
> deploy:
>=20
> 1. SVLAN N:1 model
> 2. CVLAN 1:1 model
> 3. Hybrid of both
>=20
> 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).
>=20
> 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.
>=20
> 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.
>=20
> The N:1 SVLAN model is quite simple and scalable for=20
> wholesale FTTH services.=20
>=20
> There is product from some vendors, now, that is built with=20
> FTTH 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.
>=20
> 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.
>=20
> Cheers,
>=20
> Mark.
