Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 May 2001 17:36:14 -0400
From:      "Deepak Jain" <deepak@ai.net>
To:        "Tom Samplonius" <tom@sdf.com>, <bv@wjv.com>
Cc:        "Laurence Berland" <stuyman@confusion.net>, "Colin Campbell" <sgcccdc@citec.qld.gov.au>, "Christophe Prevotaux" <c.prevotaux@hexanet.fr>, <isp@FreeBSD.ORG>
Subject:   RE: OC48 interface
Message-ID:  <GPEOJKGHAMKFIOMAGMDIEEBNCPAA.deepak@ai.net>
In-Reply-To: <Pine.BSF.4.05.10105292207500.19174-100000@misery.sdf.com>

next in thread | previous in thread | raw e-mail | index | archive | help


-----Original Message-----
From: Tom Samplonius [mailto:tom@sdf.com]
Sent: Wednesday, May 30, 2001 1:22 AM
To: bv@wjv.com
Cc: Laurence Berland; Colin Campbell; Christophe Prevotaux;
deepak@ai.net; isp@FreeBSD.ORG
Subject: Re: OC48 interface



On Wed, 30 May 2001, Bill Vermillion wrote:

> > > I'm still learning all this too but from what I've read the opinions
> > > are the OC-768 won't happen because SONET is a TDM [Time Division
> > > Multiplexing] method and carries a lot of overhead with it.
>
> > AFAIK TDM isn't frowned upon all that much. It carries overhead
> > as far as someone needing to provide clock, but it seems like the
> > best way to make truly separate channels in the same band on the
> > same fibre/pair/transmitter area. Or CDM, I suppose. Ethernetish
> > technologies are better, IMHO, for things where you just want a
> > big fat pipe. I guess this is why bandwidth ppl like it, but for
> > traditional telco stuff you might want sonet.
>
> Absolutely - but we have the 'circuit switched' tradition in telco.
> A certain cell is associated with a certain link.  The electrical
> equivalnet of pictures form the early days of telco with poles with
> dozens of cross-bars and hundreds of wires.  Separate channels is
> indeed a ciruit switched philophy.  But the world is moving rapidly
> to packet-switch, but telcos have a lot of SONET infrastructure.

  Telcos want to move to packet switching, because they want to
oversubscribe the network capacity.  At the end of the day, many people
want guarrenteed dedicated bandwidth.  I see the use of SONET increasing.
---

The theory of telco-style multiplexing (simplified) is the following. I can
sell 2000 1mb/s pipes and have 700 mb/s of capacity and NEVER deny any
packet to anyone. This means no increased latency and no packet drops.

The ISP-style of multiplexing (aka oversubscribing) is similar to the
following. I will sell 20 1mb/s pipes when I have 10mb/s of capacity. The
problem is that usage patterns don't become statistically predictable below
a certain point and therefore while the ISP is sold at only 50% of capacity,
he may be at 90+% utilization all the time.

In the telco model, its almost never that way. Until you throw data sessions
in. Then usage patterns grow. Multiplexing is still beneficial for end-user
traffic, but generally not on core<>core traffic.

---


POS (packet over sonet) links are more and more common on the various
backbone providers.  Basically POS is PPP over Sonet.  SONET is much
simpler than ethernet, so it requires PPP for IP encapsulation.  The
efficiency of such links is very high.  Much better than ATM.

---

SONET is a physical layer protocol that (when implemented) can provide
switching around cut fiber in sub milliseconds. There is no such thing as
native IP over Fiber, but POSIP is the closet thing we have. IP has no
extension that can tell you if a link is up or not.

--

...
> > > It makes sense.  I know that were I have some machines located [in
> > > a Level 3 facility] they say their goal is to drop all SONET and
> > > become a pure IP transport.
>
> > I assume by IP u mean ethernet or some similar technology with IP
> > running on it, or am I being dense again.
>
> I'm assuming a lot will be ATM.  Ethernot has a lot of overhead
> too. I'm just getting my feet wet there, and I've got a DSL link
> coming up next week - and it's ATM.  PPoA.  If it were PPoE you'd
> enacapsulate the Ethernet in the ATM and do the reverse at the far
> end.  Native mode makes more sens.

  ATM has tons of overhead.  About 10 to 15% usually.  Ethernet is pretty
light in comparision.  PPP is basically nothing in comparison.  Long haul
links are expensive, and most backbones are switching to POS.  ATM is
disappearing on many backbone networks.  Some backbone providers
(ie. Teleglobe) refuses to put any IP over ATM.  ATM is in significant
decline.  I'm aware of some regional IP providers who are phasing out all
ATM links in favour of PPP links (POS, DS3, etc.).

  All the OC192 router interfaces that Cisco and Juniper make today are
POS, not ATM.  I'm sure that Cisco and Juniper are going to be all over
OC768 POS too.

  ATM makes sense for DSL, because usually people want DSLAMs to be
simple, so they make the ATM network do the work.  I've worked on direct
bridged DSL (ethernet over ATM) and PPPoE (PPP over ethernet over ATM)
network.  The biggest problem with DSL is not the bandwidth, but getting
the DSLAM traffic to the IP network.  Paying another 5% overhead seems
small in comparsion to how difficult your ILEC/CLEC might make this for
you.

Tom

---


Keep in mind that ATM is very good with multiplexing and QoS because it has
a very high IP overhead (~30% in the real-IP world). Since you are
definitely oversubscribing in a DSLAM case, this helps make sure everyone
gets enough bandwidth to be happy, and the heaviest users get curbed the
most when needed.

ATM connections have other advantages like having a cell cloud where you can
have multiple DSLAMs in multiple cities and connect to that cloud via a
single entrance per ISP. If a single company were doing all the DSLAMs the
cost would be no better than a single point-to-point from each CO to the
datacenter. Since multiple ISPs provide DSL service to the same set of
DSLAMs, its either FR or ATM, and FR is generally provided over ATM anyway
nowadays.

Deepak Jain
AiNET


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?GPEOJKGHAMKFIOMAGMDIEEBNCPAA.deepak>