Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!accuvax.nwu.edu!nucsrl!telecom-request From: goldstein@carafe.enet.dec.com (Fred R. Goldstein) Newsgroups: comp.dcom.telecom Subject: Re: Questions About SONET Message-ID: <4297@accuvax.nwu.edu> Date: 23 Feb 90 17:17:20 GMT Sender: news@accuvax.nwu.edu Organization: Digital Equipment Corp., Littleton MA USA Lines: 70 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 10, Issue 124, Message 3 of 11 In article <4265@accuvax.nwu.edu>, HGSCHULZ@cs.umass.edu (Henning Schulzrinne) writes... >1. Are there any readily accessible papers (i.e., not just some >standard) containing details on SONET, beyond the paper in the March >1989 issue of the IEEE Communications Magazine? I am especially >interested in motivations of certain design decisions, not just >"that's how it is and there is nothing you can do about it". >2. Why was the row size set to 90 bytes? As it is, ATM packets will >have to be broken across rows. You have to remember that SONET and ATM are only distantly related. SONET predates ATM; it did not anticipate ATM. ATM does not require SONET; the B-ISDN crowd simply took pieces that the ATM fanatics wanted and pieces that the SONET fanatics wanted and glommed them together. They don't fit together particularly well. >3. How do ATM and SONET interact? What gets switched where? SONET is simply the physical medium that carries ATM (or other things). It's synchronous. The row size is based on a compromise between the US and Europe. Originally the US ran 50.02 Mbps (I think) STS-1 with 13 rows, but that's meaningless to the Europeans (whose hierarchy is different) so the compromise was to "meet" at STS-3 (STM-1 to CCITT), with 270 columns and 9 rows. The compromise fit together that way. ATM cell size is controversial. The Aussies pushing DQDB (802.6) had 69-octet cell silicon and the Americans agreed with that size (64 octet payload, 5 octet header). The French did the Prelude experiment in '82 using 18 octet (16+2) cells, and figured that they could go as high as 32 octet payloads without needing echo cancellers for voice. (Echo cancellers are needed if your packetization and propagation delays are excessive. In a country the size of the US, 32 octets of packetization delay, or 4 milliseconds, would have been excessive. So we Gringos are pretty much resigned to using echo cancellers over ATM.) CCITT struck a compromise last summer that nobody really liked: Split the difference and have a 48-octet payload (48+5 cell). Dividing 53 octets into the 260-column STM-1 (after 10 columns of overhead are subtracted) does not leave an integer, but you can hardly blame SONET for that! >4. What is the advantage of interleaving ``header'' information >throughout the frame, rather than concentrating it at the beginning of >a frame? Why are the payload pointers put a number of rows after the >beginning of the frame, so that I have to wait until I can determine >where the payload begins? In practice, I think you'll have to buffer a frame anyway; putting the overhead throughout the frame (actually, in the first columns) allows the rest of the columns to be used as virtual tributaries, undisturbed. It makes sense to me. >5. Why was the path overhead made part of the payload rather than the >header? SONET is layered. It requires a section layer overhead. The path is layered above section, as a path may run over many concatenated sections. fred (ANSI T1S1 rep) Fred R. Goldstein goldstein@carafe.enet.dec.com or goldstein@delni.enet.dec.com voice: +1 508 486 7388 opinions are mine alone. sharing requires permission.