- Test - lists.nanog.org

Re: MCI [ATM overhead]
by avg＠postman.ncube.com 21 Mar '96

21 Mar '96

Jeff Ogden wrote: >I don't think you can look at bandwidth without also looking at cost. If >the cost for an OC-3 is less than the cost for two DS3s, ... Then you can just put sync muxes at ends and get three clearline DS-3s. Still beats ATM over OC-3. (Of course, RFC-1916 is better). The pricing on ATM transport is merely an artefact of "pilot" status of ATM networks. Carriers lose money on that. When market will be established the prices are bound to rise to that of native IP transport, or, likely, more (as ATM does not handle levels of overcommitment found in IP backbones now). IP transport also tends to be overpriced, as revenues are used to sustain constant build-up (as opposed to capital investments used to build FR and ATM networks). That silly kind of accounting (when growth costs are counted as operational expenses in IP service) is what i was rallying against in Sprint for quite a time (that's being fixed, or so i told, now). --vadim

1 0

PPP over SONET (RFC-1619)
by William Allen Simpson 21 Mar '96

21 Mar '96

> From: bajaj(a)bellcore.com (Shikhar Bajaj) > Other than the SprintLink design Vadim mentions above, what other > alternatives are emerging for high bandwidth IP transport? Is anyone > implementing PPP over SONET (RFC 1619)? > I am aware of 2 vendors implementing PPP over SONET, and at least one public RFP that has been bid and accepted from one of those vendors. I am not under non-disclosure to either vendor, but would prefer that they disclose themselves. It seems silly to answer a public bid (last year), and still claim "non-disclosure". RFC-1619 is a Proposed Standard, and may change based on the implementation experience of the vendors as it goes to Draft Standard. The only problem discovered so far is that some PTT equipment vendors did not implement the SONET Loss of State (LOS) test requirement of 2.3 micro-seconds (119 unchanging zero/one bits at OC3), and instead implemented 73-bits, the minimum from G.958 for a badly designed timing recovery circuit. Many vendors are currently 'going around' Bellcore by applying proprietary solutions to problems and convincing the RBOCs that it doesn't matter if they are in long term partnerships. ISO -- pick a standard, any standard. This, in turn, may require an extra scrambling to be required. Not a big hardware commitment, though, but a serious annoyance. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

RE: MCI
by Bharat Ranjan 21 Mar '96

21 Mar '96

> > > > On Tue, 19 Mar 1996, Arun Welch wrote: > > >Yup. There's work in progress to put IP directly on SONET, which >should save > >people with OC-3c backbones from paying the ATM penalty. Last year, I was involved with some vendor work that was being done to optimize the SONET payload for various protocols. In particular, the 'growth' bytes Z3, Z4, and/or Z5 in the SONET Path overhead would be used to optimize the payload size based on the protocol being used. The thought was that such an optimization would take place at the "edge" of the network, where local traffic is passed to a WAN, via SONET. ATM and Frame Realy were being focused on in particular, especially with the concatenated (OC-Nc) payload. I was told that IP has now been added to the list of protocols that SONET would optimize/support. If this work comes out as a SONET standard, it would be a great plus when using OC-3c interfaces on routers. mm mm sssss nnnnnn * Bharat Ranjan * m m m s nnnnnnn * Network Engineer * m m m sssss nn nn * Microsoft On-Line Services * m m s nn nn * (206)-936-0471 * m m sssss nn nn * bharatr(a)microsoft.com * ******************************************************* * The opinions/ideas in this memo are not necessarily * * those of Microsoft Corp. * ******************************************************* > >

1 0

Re: MCI [ATM overhead]
by bajaj＠bellcore.com 20 Mar '96

20 Mar '96

>> There's beginning to be some expectation that there will be a transmission >> capacity crunch in the carrier's Sonet nets, and this ~25% ATM cell tax may >> be looked at carefully as packet over Sonet solutions emerge. > I.e. a dual clearline DS-3 actually carries as much user data as OC-3c ATM. > Which, incidentally, was why SprintLink backbone design is easily expandable > to dual links (that includes carefully considering implications for routing). > Sean presented that design on NANOG a year ago, BTW. Funny thing, the design > is expandable beyond that, too, so OC-3 ATM is already obsolete. > > --vadim Other than the SprintLink design Vadim mentions above, what other alternatives are emerging for high bandwidth IP transport? Is anyone implementing PPP over SONET (RFC 1619)? Shikhar

1 0

Re: MCI [ATM overhead]
by Wolfgang Henke 20 Mar '96

20 Mar '96

johnc(a)msc.edu (John Cavanaugh) writes: > You can find a paper that addresses this question at > > http://www.msci.magic.net/docs/magic/overhead.ps or > fte:ftp.magic.net/pub/magic/overhead.ps > > It covers OC-3c, OC-12c, 100 and 140 Mbps TAXI, and DS3 framing, and > gives the effective bandwidth at each layer. Thank you for the reference. I will certainly check it out. Here is a little table which I hope will help ISPs planning to upgrade bandwidth: SONET (Synchronous Optical Network) speeds given in Mbps nominal w/o Sonet ATM TCP/IP overhead OC-3 STS-3c 155.520 149 122 137 future net backbone OC-12 STS-12c 622.080 599 488 549 OC-48 STS-48c 2488.32 2396 1953 2197 current telco backbone OC-192 STS-192c 9953.28 9585 7813 8788 on single mode fiber or multi mode fiber or CATV 75 ohm coax (the lower speeds) Additions and corrections are welcome. Wed Mar 20 07:56:41 PST 1996 http://www.whnet.com/wolfgang/sonet.html > John Cavanaugh EMail: johnc(a)msc.edu > Minnesota Supercomputer Center, Inc. johnc(a)cray.com > 1200 Washington Ave. S Phone: +1 612 337-3556 > Minneapolis, MN 55415 FAX: +1 612 337-3400 Wolfgang Wolfgang Henke wolfgang(a)whnet.com . http://www.whnet.com/wolfgang/ WH Networks ... ftp.whnet.com /pub/wolfgang 2672 Bayshore Parkway Suite 503 ....... +1 415 390 9316 Mountain View CA 94043 ................... fax +1 415 390 9317

1 0

Re: MCI [ATM overhead]
by Wolfgang Henke 20 Mar '96

20 Mar '96

Jim Forster <forster(a)cisco.com> writes: He's talking about the overhead due to carrying variable length IP packets in fixed length ATM cells. Consequently the last cell of an AAL5 frame will contain 0 - 39(?) bytes of padding, which is wasted bandwidth. Assuming random length distributions (which they're not), the average waste is about 20 bytes per packet. My rough estimate, based on an average packet size of 200 bytes (used to be correct, not sure anymore), is that the waste due to cell padding is about 10%. Due to the highly skewed packet size distribution the actual overhead might vary substantially. Note that this 10% is on top of the ~10% overhead due to the 5 byte ATM cell headers (5/53 ~= 10%), and various other overheads (some of which are also present in frame over Sonet schemes). There's beginning to be some expectation that there will be a transmission capacity crunch in the carrier's Sonet nets, and this ~25% ATM cell tax may be looked at carefully as packet over Sonet solutions emerge. Great. Let's estimate the ATM bandwidth available on an OC-3. With STS-3c SONET at 155.520 Mbps it gets reduced to 149.760 Mbps due to section, line and path SONET overhead. Next we reduce 10% due to 20 bytes lost on average 200 byte long packets due to incomplete ATM cell fills resulting in 134.784 Mbps. Then we need to subtract 9.43% due to ATM headers of 5 bytes in 53 byte packets. Thus we end up with a 122.069 Mbps true information rate which is about 78.5% of the nominal OC-3 capacity. And we still have not raised the issues of wasted reserved bandwidth and routing ease which were recently addressed very eloquently by Vadim Antonov when comparing connection based with packet based transport. Wolfgang Wolfgang Henke wolfgang(a)whnet.com . http://www.whnet.com/wolfgang/ WH Networks ... ftp.whnet.com /pub/wolfgang 2672 Bayshore Parkway Suite 503 ....... +1 415 390 9316 Mountain View CA 94043 ................... fax +1 415 390 9317

2 1

Re: cisco OC3 interfaces
by Dave Morton 20 Mar '96

20 Mar '96

>Gordon, > >The only OC3 interfaces we sell for the 75XX series of routers >are the single mode and multimode versions of the AIP (ATM interface >processor). > >I believe what Dorian is referring to is the use of several of these >routers (actually, they could be 4500s, 4700s, 70x0's or 75xx's) >connected to an ATM switch. Nothing too mysterious. > >If anyone has been discussing other OC3 interfaces with you, they >are potentially in violation of a non-disclosure agreement, and I >would suggest that such conversations shouldn't be happening. Dave, The cat is probably out of the bag wrt the above regardless of any NDAs - if cisco was not working on such a beast they would be pretty silly. Cheers, Dave

1 0

cisco OC3 interfaces
by Dave O'Leary 19 Mar '96

19 Mar '96

Gordon, The only OC3 interfaces we sell for the 75XX series of routers are the single mode and multimode versions of the AIP (ATM interface processor). I believe what Dorian is referring to is the use of several of these routers (actually, they could be 4500s, 4700s, 70x0's or 75xx's) connected to an ATM switch. Nothing too mysterious. If anyone has been discussing other OC3 interfaces with you, they are potentially in violation of a non-disclosure agreement, and I would suggest that such conversations shouldn't be happening. dave Date: Tue, 19 Mar 1996 11:02:19 -0500 (EST) >From: Gordon Cook <gcook(a)tigger.jvnc.net> Reply-To: cook(a)cookreport.com To: Dorian Kim <dorian(a)cic.net> Cc: David Miller <david(a)dirigo.mint.net>, Jasper(a)cloud9.net, inet-access(a)earth.com, nanog(a)merit.edu Subject: Re: MCI I am told that Cisco has an OC-3 interface to its 75XX series of routers. If so why would you need a cluster of routers around each ATM switch?

1 0

Re: MCI [ATM overhead]
by Paul Ferguson 19 Mar '96

19 Mar '96

At 07:51 PM 3/19/96 -0800, Jim Forster wrote: > >There's beginning to be some expectation that there will be a transmission >capacity crunch in the carrier's Sonet nets, and this ~25% ATM cell tax may >be looked at carefully as packet over Sonet solutions emerge. > I think it will be critically important, especially in long-haul interconnect scenarios. Historically speaking, as providers have replaced congested links with faster ones, they have also become quickly congested. And since these high-speed long-haul links are not cheap, you can bet that these organizations want to get the most bang-for-the-buck. I can't imagine that ~25% bandwidth overhead would be acceptable, especially when more efficient alternatives exist. Nice synopsis, Jim. - paul

1 0

Re: MCI [ATM overhead]
by avg＠postman.ncube.com 19 Mar '96

19 Mar '96

Jim Forster <forster(a)cisco.com> wrote: >He's talking about the overhead due to carrying variable length IP packets >in fixed length ATM cells. ... >There's beginning to be some expectation that there will be a transmission >capacity crunch in the carrier's Sonet nets, and this ~25% ATM cell tax may >be looked at carefully as packet over Sonet solutions emerge. Given the bimodailty of IP traffic size distribution (about 40% of packets are small, like TCP ACKs or telnet/rlogin keystrokes) the ATM "cell tax" is closer to 32%. I.e. a dual clearline DS-3 actually carries as much user data as OC-3c ATM. Which, incidentally, was why SprintLink backbone design is easily expandable to dual links (that includes carefully considering implications for routing). Sean presented that design on NANOG a year ago, BTW. Funny thing, the design is expandable beyond that, too, so OC-3 ATM is already obsolete. --vadim

1 0