March 1996 - Test - lists.nanog.org

Re: cisco OC3 interfaces
by Dave O'Leary 21 Mar '96

21 Mar '96

Hi Dave, We've certainly been known to do some pretty silly things before, and some would say that a lot of things we're doing now are pretty silly :-) Regardless, an non-disclosure agreement is a non-disclosure agreement. We work very hard internally to avoid "leaking" information between the various providers we are under non-disclosure with, and we expect the customers who we work with under an NDA to also take the NDA seriously. While it might make complete sense that we are/should be working on a particular product or feature, that doesn't mean that we are, and details like how close we are to delivering a particular product or its specific features, etc. could clearly be of use to our competitors - which is why we execute an NDA. Thanks, dave

2 1

RE: MCI
by bajaj＠bellcore.com 21 Mar '96

21 Mar '96

> 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. Why is SONET a problem? An STS-3c has 2430 byte frame of which 90 bytes are management overhead. This is a fixed efficiency of 96.3%. Even if you increase the efficiency to 99+%, for bursty traffic like IP, are people going to wait til they have 95% link utilization before they increase their capacity? Of course not. Customers will be screaming long before then. While more efficiency is always better, will anything actually be gained by trying to squeeze an extra couple of percent out of SONET? (Though I can easily see how this would benefit telephony :-) ). I also don't understand how this technique would help anything in a WAN. Even if you play games with the path overhead, the SONET regenerators and cross connects in the carrier infrastructure are section and line terminating equipment, respectively. They don't care what the path overhead looks like and will still be expecting 2430 byte frames. Thus, you would have to do some sort of "fragmentation" at the network edges. It would also be interesting to see how they propose reconciling the fact that their frame time is no longer strictly 125 usec. Shikhar

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