- Test - lists.nanog.org

Re: SONET Interconnect (was RE: MCI)
by Sean Doran 29 Mar '96

29 Mar '96

Someone suggested to me that it's because so much money has been spent on developing the technology that it HAS to be used in order to recover the investment. This may be somewhat apocryphal, but it's eminently believable. Sean.

2 1

Re: SONET Interconnect (was RE: MCI)
by Paul Ferguson 29 Mar '96

29 Mar '96

At 10:48 AM 3/26/96 -0500, Shikhar Bajaj wrote: > >Currently, the only way of doing this is the "traditional way" of using >SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into >an STS-12 and then mux the 12's into a STS-48. This is what we are doing >in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA and DoD. >(see http://www.atd.net/atdnet.html) > >As per our previous discussion, the trend seems to be putting the switching >and transport functions in one box so that you may be able to buy an >ATM switch that also does SONET protection switching. > I fail understand, however, why ATM over SONET is desirable when there is such a loss to overhead, especially when viable alternatives may exist to get more bang-for-the-buck. Perhaps someone could enlighten me on this particular datapoint? - paul

3 2

Re: SONET Interconnect (was RE: MCI)
by bajaj＠bellcore.com 26 Mar '96

26 Mar '96

Bharat, > Has there been any thought given to How the OC-3c signal from a router > will be connected to a OC-48 or 192 signal in a typical SONET ring? Currently, the only way of doing this is the "traditional way" of using SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into an STS-12 and then mux the 12's into a STS-48. This is what we are doing in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA and DoD. (see http://www.atd.net/atdnet.html) As per our previous discussion, the trend seems to be putting the switching and transport functions in one box so that you may be able to buy an ATM switch that also does SONET protection switching. > I would think that the SONET vendors (Alcatel, Fujitsu, etc) would have to > work with the router vendors to ensure that SONET overhead information > is passed properly to the higher level signal. This overhead provides > data on performance, net management, etc. The kicker here is that SONET > contains undefined overhead bytes that many vendors have used for > proprietary services. This is the reason why different vendors' > equipment cannot be mixed within the same ring. The CMISE set of > standards is supposed to take care of incompatibilities, but as with any > other standard, it will be complete years from when it is needed. The SONET standards (at least for frame and overhead) generation are well documented so that router vendors, theoretically, should not need to work with traditional SONET vendors to get transport and framing functionality. For ATM over SONET, there are also a number of chips/chipsets which will perform SONET framing. PMC-Sierra (which FORE Systems uses) and IGT immediately come to mind (and I know that I have missed some others). Of course, if a router and SONET vendor want to work together to also offer some value-added functionality, that is an issue. You are entirely correct that many vendors have used the undefined overhead for proprietary services. The most common overhead used are the growth bytes (Z-bytes) and DCC bytes (D-bytes). In many cases, those bytes are used to pass proprietary messages for network element control and maintainance. That is a major reason why you don't see multiple vendors on the same ring. More than likely the transport would work fine but the OAM would be a nightmare. If and when the vendors fully implement CMISE, that would solve a lot of headaches. Until then, we have to deal with a mixture of partial CMISE support, proprietary interfaces, and TL-1 (Transmission Language-1, an old Bell System management protocol). In lieu of this (and other factors), it is not surprising that strategic partnerships between carriers and vendors are so common. Shikhar

1 0

SONET Interconnect (was RE: MCI)
by Bharat Ranjan 26 Mar '96

26 Mar '96

Has there been any thought given to How the OC-3c signal from a router will be connected to a OC-48 or 192 signal in a typical SONET ring? I would think that the SONET vendors (Alcatel, Fujitsu, etc) would have to work with the router vendors to ensure that SONET overhead information is passed properly to the higher level signal. This overhead provides data on performance, net management, etc. The kicker here is that SONET contains undefined overhead bytes that many vendors have used for proprietary services. This is the reason why different vendors' equipment cannot be mixed within the same ring. The CMISE set of standards is supposed to take care of incompatibilities, but as with any other standard, it will be complete years from when it is needed ;-) 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

ATM ABR service
by Kent W. England 25 Mar '96

25 Mar '96

At 12:18 PM 3/25/96 -0500, Curtis Villamizar wrote: > >Due to some poor initial choices in equipment (mostly due to a lack of >useful ATM choices at the time) PacBell got an early reputation for >moderate loss at very low throughput. They put their customers >requiring "high speed" on a single FDDI ring, which is the same things >causing trouble at MAE-West, soon to be upgraded. Curtis; The Newbridge ATM switch was selected over three years ago. The new Stratacom BPX (10Gbps) switches are now in place and working for NAP service. The Newbridges are still in service for other applications. > >Perhaps after the transition to the ABR capable switch, assuming also >that the router adapters will respect the RM cells and can all agree >on RFC1483 (and in addition RFC1577 would be nice), the PacBell NAP >will be a technically viable alternative. I think it's a bit optimistic to expect ABR routers real soon (the standard is still pretty fresh), but the BPX will emit EFCI notification, so the routers can use that if they want. > >On a technical note, I'm not excited about ABR's concept of fainess. >I don't see the value to giving the VC to some small provider a fair >share of bandwidth outbound from the NAP as is given a large provider >with 2-3 orders of maginitude more TCP flows on the VC. It is not >technically feasible to set up a VC per large provider flow, and there >is no way to weight the VC. I'd prefer EPD/PPD since someone is >likely to be congested. > >For example, consider traffic to provider A. Provider B and C each >provides 25% of the egress traffic. There are 10 other providers >pushing 5% each when things get congested. Provider B and C will be >losing 80% of their traffic before the others see any loss, even if >those providers only have a handful of users some of which are doing >wasteful things like running multiple unicast CuSeeMe flows. If >provider A is a small provider with a low speed link, the problem >isn't due to provider B and C. Provider A has too little egress >bandwidth, yet only traffic from B and C is affected. > If what you want is an "admit all with best effort" quality of service then we should configure the NAP for UBR service and let each connection or path fight for bandwidth "fairly" according to WFQ (if available in the routers) or FIFO and TCP congestion avoidance. If what you want is a "allocate minimums, share the rest" quality of service then we should use ABR and set the minimum cell rate according to what the parties to each circuit want. What do NAP customers want? WFQ/FIFO sharing or pre-allocated ABR? >This is a fundamental problem due to the need for hard state (separate >VC per actual user flow) to affect ABR (as opposed to no state at all >for EPD) and the infeasibility of setting up this hard state. > >Curtis It might make sense to map each flow onto a separate VC when that flow is a campus network flow, but I don't think that scales to something the size of the NAP. --Kent

1 0

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

25 Mar '96

> Date: Thu, 21 Mar 1996 15:09:51 +0800 > From: avg(a)postman.ncube.com (Vadim Antonov) > To: jogden(a)merit.edu, nanog(a)merit.edu > Subject: Re: MCI [ATM overhead] > [...] > 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). > [...] Hmmm... Does that imply that the NSP that can take advantage of underpriced services, (perhaps including ATM, if you are correct), will have a competitive advantage? -tjs

1 0

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

25 Mar '96

> From: jon(a)branch.com (Jon Zeeff) > Subject: Re: MCI [ATM overhead] > To: salo(a)msc.edu (Tim Salo) > Date: Thu, 21 Mar 1996 09:04:44 -0500 (EST) > Cc: wolfgang(a)whnet.com, nanog(a)merit.edu > > > Line Rate 155.520 Mbps > > Available to ATM 149.760 > > Available to AAL 135.632 > > > The reader can apply their favorite packet size distributions to these > > numbers. > > Having said all that, I am not sure where that leaves us. > > That leaves us with the throughput of two DS3 links. It doesn't seem worth > the effort given how short term a solution it is. I am not sure I follow your arithmetic. The line rate on a DS-3 is 44.736 Mbps. You need to subtract several overheads from that: at least some DS-3 and some PPP overhead. How does that add up to half of the throughput of an OC-3c IP/ATM link? As long as I took this opportunity to inquire, what to you mean by "given how short term a solution it is?" -tjs

1 0

RE: UUNET stops peering at MAE-West
by Jim Browning 25 Mar '96

25 Mar '96

Why haven't more networks taken advantage of the PacBell NAP facility in San Francisco?? -- Jim Browning ---------- From: Roy[SMTP:garlic@garlic.com] According to the night shift at UUNET's NOC, they have stopped peering at MAE-West. <snip> The fellow I spoke with said this will remain until the GigaSwitch is installed at MAE West scheduled for this week. <snip>

3 2

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

25 Mar '96

This is betting on ATM prices being low for a long time -- long enough for investments to ATM equipment to pay off. >From the point of view of ISPs which get lines at cost this is a no-brainer choice. --vadim >From salo(a)msc.edu Mon Mar 25 14:49 PST 1996 Return-Path: <salo(a)msc.edu> Received: from postman.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA28341; Mon, 25 Mar 1996 14:49:36 +0800 Received: from noc.msc.edu by postman.ncube.com (4.1/SMI-4.1) id AA08921; Mon, 25 Mar 96 14:50:57 PST Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA12387; Mon, 25 Mar 96 16:50:22 -0600 Received: (salo@localhost) by uh.msc.edu (8.7.1/8.6.6) id QAA04516; Mon, 25 Mar 1996 16:50:29 -0600 (CST) From: salo(a)msc.edu (Tim Salo) Date: Mon, 25 Mar 1996 16:50:29 -0600 (CST) Message-Id: <199603252250.QAA04516(a)uh.msc.edu> To: avg(a)postman.ncube.com Subject: Re: MCI [ATM overhead] Cc: nanog(a)merit.edu Content-Type: text Content-Length: 667 Status: R > Date: Thu, 21 Mar 1996 15:09:51 +0800 > From: avg(a)postman.ncube.com (Vadim Antonov) > To: jogden(a)merit.edu, nanog(a)merit.edu > Subject: Re: MCI [ATM overhead] > [...] > 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). > [...] Hmmm... Does that imply that the NSP that can take advantage of underpriced services, (perhaps including ATM, if you are correct), will have a competitive advantage? -tjs

1 0

Pac Bell NAP [Was: RE: UUNET stops peering at MAE-West]
by Paul Ferguson 25 Mar '96

25 Mar '96

At 10:35 PM 3/23/96 -0800, Jim Browning wrote: >Why haven't more networks taken advantage of the PacBell NAP facility in San Francisco?? >-- >Jim Browning > ATM? :-) - paul

2 1