Date: Wed, 30 May 2001 00:09:57 -0400 From: Bill Vermillion <bill@wjv.com> To: Laurence Berland <stuyman@confusion.net> Cc: bv@wjv.com, Colin Campbell <sgcccdc@citec.qld.gov.au>, Christophe Prevotaux <c.prevotaux@hexanet.fr>, deepak@ai.net, isp@FreeBSD.ORG Subject: Re: OC48 interface Message-ID: <20010530000957.D51041@wjv.com> In-Reply-To: <3B146D6C.E4EE89F6@confusion.net>; from stuyman@confusion.net on Tue, May 29, 2001 at 10:47:56PM -0500 References: <3B12CBBE.567B1A8D@confusion.net> <Pine.BSF.4.33.0105291136060.90725-100000@guru.citec.qld.gov.au> <20010529003126.C3968@wjv.com> <3B1406F2.E4DCBD0F@confusion.net> <20010529200519.B11016@wjv.com> <3B146D6C.E4EE89F6@confusion.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 29, 2001 at 10:47:56PM -0500, Laurence Berland thus sprach: > > 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. I rember the first data muxes I saw - pure TDM - four channels of 2400 each on a 9600 line. It only took a few years for statistically multiplexing to replace that. ATM is more like that and, and with the really high speeds coming you should be able to get enough data to be ensure packets enough so it would be the same as TDM. > > Speeds will be there, but it just won't be SONET. I remember > > sitting through some tutorials about 2 years ago - and Ciena > > was calling all the SONET upgrades 'fork lift upgrades' because it > > doesn't upgrade that well. > I'm guessing this has to do with the timeslices getting smaller, > but I really don't know enough to say (if anyone wants an intern > who will work for cheap, loves unix, and wants to learn all the > crazy network stuff, please email me!!!). I'm envisoning a lot of empty cells as the speed get higher - but the big growth is appearing to be in things that want wide highspeed bandwidth. DS3's dedicated to a continuing video stream are getting to be much cheaper and reliable than a satellite feed for continous broadcast use. You surely don't need SONET for that. > > 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. > > If I'm mis-understanding this, please let me know. > I think we're both on the right track. I wish I had more > experience in all this... I'm just learning this too so if I'm wrong somebody please correct me in a hurry. Bill -- Bill Vermillion - bv @ wjv . com 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?20010530000957.D51041>