- Test - lists.nanog.org

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 was 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

Address "portability"
by Eric Kozowski 21 Mar '96

21 Mar '96

What is the general consensus of this group regarding the "portability" of addresses in the 204/8 and 205/8 range? -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

2 1

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

21 Mar '96

salo(a)msc.edu (Tim Salo) wrote: > I don't know. It doesn't look right. Tim, please note that I keep the page updated to whatever I perceive the current consensus is. http://www.whnet.com/wolfgang/sonet.html Thank you for posting! Wolfgang

1 0

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