[160155] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Muni fiber: L1 or L2?

daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jan 31 22:48:58 2013

From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAMrdfRy76Mk0vpaen0a56TrfdJxKjt+B9YteeaHr6NpW+LJ5pQ@mail.gmail.com>
Date: Thu, 31 Jan 2013 19:48:16 -0800
To: Scott Helms <khelms@zcorum.com>
Cc: Fletcher Kittredge <fkittred@gwi.net>, NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Jan 31, 2013, at 19:21 , Scott Helms <khelms@zcorum.com> wrote:

> Fletcher nailed it, if you want the architecture you're describing =
then you simply don't want PON.  Its built around lower cost and a big =
part of that lower cost is minimizing the fiber costs by serving =
splitters (and thus many homes) from a single fiber that back hauls to =
the CO.  The other reason PON won't work for what you want is the =
splitters are passive and completely static in their operation.  Here's =
an image of one that may make this clearer:
>=20
> =
http://media.wholesale-electrical-electronics.com/product/imgage/Electrica=
l&Electronics/2010101220/6dc7c82d59d9fd931bfba560a3e85031.jpg
>=20

I know what a splitter is and how they work. I understand PON really =
quite a bit better than you imagine I do.

Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> =
fiber-drops to each house -> ONT.

All I'm proposing is making n really short and making "fiber-drops to =
each house" really long.
I'm not proposing changing the fundamental architecture. Yes, I =
recognize this changes the economics and may well make PON less =
attractive than other alternatives. I don't care. That's not a primary =
concern. The question is "can PON be made to work in this environment?" =
It appears to me that it can.

It will work as I've described, but, yes, it's very suboptimal from a =
cost perspective if your only goal is to deploy PON for a single =
provider.

If, OTOH, your goal is to have a fiber infrastructure in the =
neighborhoods that can support a multitude of possible services of which =
PON from a number of providers is just one such possible service, then, =
the PON operators can, in fact, install in the MMR and do the splitting =
at the MMR end of the subscriber fiber with home-runs from the MMR to =
each home.

True, PON is probably not the best technology fit for this. Ethernet =
probably makes more sense in most cases. However, if you have providers =
that do PON everywhere else and they don't want to support "exception =
equipment" for your facility, then it allows them to install PON just =
like their other deployments, only the splitter is next to the OLT =
instead of out near a collection of ONTs.

> If you have to either run several (or more) fibers to a neighborhood =
or have managed neighborhood elements then you've simply destroyed the =
use case for PON.  Luckily this use case matches pretty exactly for =
Ethernet, but you must do your wholesale play at layer 2 IMO to work =
economically.
>=20

I disagree.  If you have home-run fiber to a large bank of patch panels =
in an MMR that can serve a ~8km radius of subscribers and providers can =
colocate whatever L2+ equipment they want to in said MMR with said =
fibers available for lease on equal footing to all providers, then the =
providers can deploy whatever makes the most sense to them whether =
that's SONET, Ethernet, PON, or optical tin cans over your fiber-string.

Yes, this is more expensive for the fiber deployment than running FTTH =
from the local BBox and having splitters in the BBox, but if it's being =
done intelligently, especially in areas of greenfield deployment, then =
it doesn't have to be a lot more expensive.

I get roughly 201 Sq. Km. as the area of an 8km radius circle (For the =
metrically challenged, that's roughly 77 Sq. Mi. or an area a little =
larger than Washington DC (68.3 sq. mi according to wikipedia).

If you're willing to require more expensive optics, you could go to a =
larger area served to accommodate lower population densities and for =
higher density areas, it might make economic sense to make the service =
radius smaller and have more centers. I don't know what the economically =
ideal subscriber volume per center would be. That would have to be =
calculated.

Owen

>=20
> On Thu, Jan 31, 2013 at 6:28 PM, Owen DeLong <owen@delong.com> wrote:
>=20
> On Jan 31, 2013, at 13:57 , Fletcher Kittredge <fkittred@gwi.net> =
wrote:
>=20
>>=20
>>=20
>>=20
>> On Thu, Jan 31, 2013 at 4:36 PM, Owen DeLong <owen@delong.com> wrote:
>> If you have an MMR where all of the customers come together, then you
>> can cross-connect all of $PROVIDER_1's customers to a splitter =
provided
>> by $PROVIDER_1 and cross connect all of $PROVIDER_2's customers to
>> a splitter provided by $PROVIDER_2, etc.
>>=20
>> If the splitter is out in the neighborhood, then $PROVIDER_1 and =
$PROVIDER_2
>> and... all need to build out to every neighborhood.
>>=20
>> If you have the splitter next to the PON gear instead of next to the =
subscribers,
>> then you remove the relevance of the inability to connect a splitter =
to multiple
>> OLTs. The splitter becomes the provider interface to the open fiber =
plant
>>=20
>> Owen;
>>=20
>> Interesting.   Do you then lose the cost advantage because you need =
home run fiber back to the MMR?   Do you have examples of plants built =
with this architecture (I know of one such plant, but I am hoping you =
will turn up more examples.)
>>=20
>=20
> I don't know of any. Yes, it would eliminate part of the theoretical =
cost savings of the PON architecture, but the point is that it would =
provide a technology agnostic last mile infrastructure that could easily =
be used by multiple competing providers and would not prevent a provider =
from using PON if they chose to do so for other reasons.
>=20
> Owen
>=20
>=20
>=20
>=20
> --=20
> Scott Helms=20
> Vice President of Technology=20
> ZCorum=20
> (678) 507-5000=20
> --------------------------------=20
> http://twitter.com/kscotthelms=20
> --------------------------------=20


home help back first fref pref prev next nref lref last post