Date: Sun, 17 Mar 1996 18:53:57 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Terry Lambert <terry@lambert.org> Cc: alk@Think.COM, hackers@freefall.freebsd.org Subject: Re: hackers-digest V1 #986 Message-ID: <199603172353.SAA12163@wa3ymh.transsys.com> In-Reply-To: Your message of "Sun, 17 Mar 1996 15:44:42 MST." <199603172244.PAA20086@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > The larger Internet Backbone Operators (like UUNET, who I work for) > > are looking really, really hard at technologies to aggregate and > > multiplex customer connections. > > We call this technology a Frame Relay cloud. Yup, I know all about Frame Relay. UUNET owns and operates on the order of 40 Cascade 9000 frame relay switchs, trunked together with long-haul DS3 circuits. > > You have *one* connection into the central offices at T1 or T3 > speed, and your customers endpoint on your cloud. Yup, and we've got dozens of T1 LEC frame relay ports for doing just this. This addresses, nicely, the problem of aggregating 56/64K up to about 256K customer ports. The only problem with LEC T3 ports is that you can't get them: there is no tariffed service offered. We've been doing some early field tests with T3 NNI connections to address this particular problem with an unnamed LEC. Of course, this is orthoginal to terminating T1 leased lines from customer locations; some of them want their very own port from their premise to "mine", which isn't "shared". You can fix part of the problem space, but not all with one solution. Thus, the extreme interest in directly terminating M13 framed DS3 circuits carrying 28 T1 circuits. Now, if the LEC's would sell connections to their frame relay network using ADSL/HDSL local loops, this is an interesting proposition. Right now, at least Bell Atlantic is trying to figure out what they can do with all this stuff they bought for Phone-Company Video on Demand. The real interesting case is the 4-10 Mb/s customer access speed, and how you aggregate/terminate those connections. Multi-T1 IMUXed? SMDS? ATM? Who knows? The economics of these various solutions are very interesting to ponder, analyze and/or take/make bets on. > You pay for *one* line and amortize the cost over all your customers, > your customers pay for *one* line. > > You need *one* interface for all of them. Well, one for some number N.. > > The stuff we're looking for tomorrow has DS3 bearers, each carrying a > > bundle of 28 T1 circuits. That is, a pair of coax right into the > > termination equipment, and the T1 circuits never see twisted pair > > cable; they're demuxed in the hardware.. The challange is to figure > > how how to terminate hundreds of customer T1 circuits per site, and > > this stuff just has to be compact (or even better, not even there in > > the first place). > > How about one DS3 into a cloud... The T1 circuits never see your building. Yup, this is sort of what we do for customer termination on *our* network. Customer leased lines terminate in *our* frame relay switch which has these nifty 10 port boards with built-in CSU/DSUs. There's a single PVC built from that T1 port to the HSSI port on the same switch that connects to the backbone router. All this to get the port density way up, and the operations costs down significantly. > If your NSP goes into the same cloud, your building necer sees wires > unless you want your own connection. 8-). Wires are evil. The more wires there are, the more opportunities for things to be broken. I'm trying to design pops that have just coax cable (for DS3, channelized and clear) and fiber. The problem, you see, is trying to drastically scale up in effectively constant volume.. Sorry for the diversion; this is pretty far afield from FreeBSD, 'cept that I run it on my machine and it works pretty good. Louis Mamakos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603172353.SAA12163>