- Test - lists.nanog.org

Re: MCI [ATM overhead]
by jogden＠merit.edu 21 Mar '96

21 Mar '96

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, ... -Jeff Ogden Merit At 9:26 AM 3/21/96, Shikhar Bajaj wrote: >> 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 >> > >If OC-3 is obsolete, what does that make DS-1s and DS-3s? > > >Shikhar

1 0

Re: MCI [ATM overhead]
by salo＠msc.edu 21 Mar '96

21 Mar '96

> Date: Thu, 21 Mar 96 08:48:40 GMT > From: "William Allen Simpson" <wsimpson(a)greendragon.com> > To: nanog(a)merit.edu > Subject: Re: MCI [ATM overhead] > > > From: salo(a)msc.edu (Tim Salo) > > > From: Wolfgang Henke <wolfgang(a)whnet.com> > > > 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 > > > [...] > > > > I think your 122 Mbps "ATM" number could be a bit confusing, even knowing > > the assumptions you described in earlier mail. (Also, more bandwidth seems > > to be available to "TCP/IP" than appears to be available from ATM...) > > > I believe that the number is for TCP/IP carrying capacity _without_ ATM. I don't know. It doesn't look right. > > One could remove the ATM overhead, but then one has a point-to-point > > link, rather than a link over which data from many sources can be > > multiplexed. > > > Rather, that leaves us with the excellent (very desirable) option of a > link where data from many sources are multiplexed by TCP/IP.... You are correct in observing that IP traffic can be multiplexed across a point-to-point link. As shown below, ATM provides link-layer multiplexing of data from multiple [link-layer] geographic locations. Of course, IP traffic can be multiplexed over ATM virtual channels, just as it can across point-to-point links. > I do not see what ATM buys in this situation. I believe that we have at least one mid-level using ATM to connect to multiple NAPs in roughly the following configuration: NAP NAP NAP | | | | | | ........................... . . . . . ATM Wide-Area Service . . . . . ........................... | | Mid-Level There are also several production wide-area IP networks which are using a similar configuration, including parts of ESNet and NASA NREN. While I have not been privy to the economic analysis which justified these networks, I suspect that ATM wide-area networks provided a useful price/performance point. I also believe that a number NSPs are using ATM as a multiplexing technology, or are using carrier services which use ATM as a multiplexing technology. -tjs [These arguments sound a bit like the Cray [the supercomputer person/company] approach to memory: "real computers have real memory." I guess those who couldn't afford or didn't need gigabytes of real memory made do with virtual memory.]

1 0

Re: PPP over SONET (RFC-1619)
by bajaj＠bellcore.com 21 Mar '96

21 Mar '96

> > 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. > Interesting. If this happens, I can see lots of fun when trying to do intercarrier interconnects. Of course, they will first have to reconcile these issues with their current SONET infrastructures. Shikhar (Standard Disclaimer: the opinions expressed are strictly my own and are not those of Bellcore)

1 0

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

21 Mar '96

> > > One could remove the ATM overhead, but then one has a point-to-point > > link, rather than a link over which data from many sources can be > > multiplexed. > > > Rather, that leaves us with the excellent (very desirable) option of a > link where data from many sources are multiplexed by TCP/IP.... > > I do not see what ATM buys in this situation. Like any technology, ATM will not be all things to all people. If all you are looking for is a "big, fat pipe" below IP, you will look at all your available options in addition to ATM. (You will be looking at all options regardless). In the end, you will choose whatever makes sense technologically AND ECONOMICALLY. Shikhar

1 0

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

21 Mar '96

> 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 > If OC-3 is obsolete, what does that make DS-1s and DS-3s? Shikhar

1 0

Re: MCI [ATM overhead]
by salo＠msc.edu 21 Mar '96

21 Mar '96

> From: Wolfgang Henke <wolfgang(a)whnet.com> > Subject: Re: MCI [ATM overhead] > To: johnc(a)msc.edu > Date: Wed, 20 Mar 1996 08:38:08 -0800 (PST) > Cc: nanog(a)merit.edu > a [...] > 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 > [...] I think your 122 Mbps "ATM" number could be a bit confusing, even knowing the assumptions you described in earlier mail. (Also, more bandwidth seems to be available to "TCP/IP" than appears to be available from ATM...) If it helps, the following numbers are from John Cavanaugh's paper: Line Rate 155.520 Mbps Available to ATM 149.760 (SONET payload) Available to AAL 135.632 (ATM payload) John then computes the overhead for three MTUs, and yields rates available to IP and TCP: MTU 576 9180 65527 Available to IP 125.198 135.102 135.547 Available to TCP 116.504 134.513 135.464 These are the maximum available rates, namely they assume MTU-sized packets. The reader can apply their favorite packet size distributions to these numbers. Having said all that, I am not sure where that leaves us. One could theoretically remove the SONET overhead, but then one looses the ability to manage the SONET link. One could remove the ATM overhead, but then one has a point-to-point link, rather than a link over which data from many sources can be multiplexed. -tjs

2 1

Re: MCI [ATM overhead]
by William Allen Simpson 21 Mar '96

21 Mar '96

> From: salo(a)msc.edu (Tim Salo) > > From: Wolfgang Henke <wolfgang(a)whnet.com> > > 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 > > [...] > > I think your 122 Mbps "ATM" number could be a bit confusing, even knowing > the assumptions you described in earlier mail. (Also, more bandwidth seems > to be available to "TCP/IP" than appears to be available from ATM...) > I believe that the number is for TCP/IP carrying capacity _without_ ATM. > One could remove the ATM overhead, but then one has a point-to-point > link, rather than a link over which data from many sources can be > multiplexed. > Rather, that leaves us with the excellent (very desirable) option of a link where data from many sources are multiplexed by TCP/IP.... I do not see what ATM buys in this situation. 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 [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