Cell Relay Archive

[Network192 <Network192@aol.com>]

You should really think about what you write before you go to town with it.
See my comments below.

In a message dated 3/27/98 4:04:38 AM, you wrote:

>> One of the trade magazines recently published an article comparing
>> IP/ATM/SONET with just IP/SONET.  You can reach it by going to my
>> networking references site and looking on the communications page.
>
>If you think of "packet over sonet: ringing up Speed", Data
>Communications 3/98 by Victor R. Parente
>(http://www.data.com/tutorial/sonet.html) , then that definitely is
>no good point to start reading. The author makes a good point in
>describing fast protection switching as a advantage of SONET but on
>the other hand does not know how to do his math when comparing
>effective bitrates of IP over SONET and IP over ATM over SONET.
>
>The author does not take into account that even when using packet 
>over SONET as described in RFC 1619 the octet stream is maped in the 
>SONET SPE which means that the effective bandwidth on OC3 is reduced 
>by the factor of 260/270 (section and path overhead in SONET/SDH 
>framing) resulting in a effective bandwidth of 149,76 Mbps for SONET 
>over PPP in a STS-3c framing. Further on the author forgets to take 
>into account the overhead introduced by using the HDLC framing 
>(no address and control field compression defined in RFC 1619) while 
>on the other hand calculating the factor of 48/53 for the ATM 
>payload. It@s not that he is completly wrong in pointing out that 
>packet over SONET introduces less overhead than IP over ATM over 
>SONET, but by stating completely wrong numbers he disqualifies 
>himself in a way and introduces the impression of him beeing very 
>biased. 

First of all there was a mistake made in the publication of the article in
which the data from the raw transport column was placed in the frame capcity
column and the former column was removed. These kidns of mistakes do happen
frequently in technical publications. Myself and other had already previously
pointed out the errors.

>By the way, the author in figure 2 marks some links as beeing "OC3c". 
>This in my opinion is a typical error made in using the right names 
>for the right things. As stated in the specs OCn simply is the name 
>for a optical carrier level where STS-n is the correct naming for the 
>used framing. So the correct name in the figure would have been 
>either STS-3c (meaning concatenated SPE) or OC3.

Acutally circuits may be referred to by either naming convention. In the
particular case of pointing to the operational circuit and it's connection to
the router it is indeed an OC-3c.

>The author then points out that by using protection switching on a 
>full OC12 SONET ring all links are fully protected against circuit 
>failure. This is not only true for a SONET only network but can also 
>be used in combination with ATM by building a OC12 SONET ring with 
>STS-3 ADMs and then connecting ATM switches to the STS-3 tributary 
>links. Then the protection switching mechanism of SONET protects the 
>STS-3 tribs on the PHY layer transparently to the ATM equipment. 

Absolutely true and I never stated otherwise.
 
>be fair it should be stated that fast protection switching needs a 
>priori planning of protection trails through the SONET resulting in 
>need for double of the protected tribs bandwidth in the net. Or the 
>other way round you only can use half of the backbone@s bandwith as 
>protected tribs bandwidth. A protection concept based on redundant 
>ATM links and PNNI on the other hand would give slower recovery times 
>(tear down and reestablishment of SVCs by signalling) without the 
>need for a priori planning and thus waisting a lot of backbone 
>capacity.

This isn't a "waste" of backbone capacity. Anyone who designs SONET rings
without providing protect capacity doesn't get it. 

So how much SONET capacity (how many rings and of what capacity do you
personally oversee and manage? How many ATM systems have you designed and
managed?

Victor Parente

>Johannes
>---------------------------------------------------------------------------
>Pan Dacom GmbH
>Training/Consulting
>Johannes Krohn
>Robert-Bosch-Str. 32
>D-63303 Dreieich