home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / dcom / cellrel / 927 < prev    next >
Encoding:
Text File  |  1993-01-05  |  2.3 KB  |  52 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!mcsun!news.funet.fi!ajk.tele.fi!funic!nokia.fi!tnclus.tele.nokia.fi!hellstro
  3. From: hellstro@tnclus.tele.nokia.fi
  4. Subject: Re: two more questions re: SDH and ATM
  5. Message-ID: <1993Jan5.114627.1@tnclus.tele.nokia.fi>
  6. Lines: 39
  7. Sender: usenet@noknic.nokia.fi (USENET at noknic)
  8. Nntp-Posting-Host: tne01.tele.nokia.fi
  9. Organization: Nokia Telecommunications.
  10. References: <1993Jan4.173229.25170@sics.se>
  11. Date: Tue, 5 Jan 1993 09:46:27 GMT
  12.  
  13. craig@sics.se (Craig Partridge) writes:
  14.  
  15. .. 
  16. > notes that one could load the sync sequence (bytes A1 and A2) into the payload
  17. > of an ATM cell and screw up the SONET multiplexors.  They note that as a result
  18. > the data in the ATM cells have to be scrambled.  But it wasn't clear to me
  19. > that the scrambler would always provide protection.  Is the scrambler
  20. > guaranteed not to generate the two byte sequence 0xF6 0x28, or is some
  21. > fancy bitstuffing done too?
  22.  
  23. No bitstuffing will be done. The ATM cell payload scrambling is supposed to
  24. protect ONLY the ATM cell header against mimic patterns appearing in the
  25. cell payload. In addition to previous the entire STM-1 (STS-3) frame
  26. (excluding the synch sequence) containing the scrambled ATM cells will be
  27. scrambled again according another polynomial. So it's not worth trying
  28. to mess up the SDH/SONET equipment with ATM cells.      
  29.  
  30. .. 
  31. > Second, I'm getting conflicting information about how ATM cells get packed.
  32. > My understanding is that originally cells were packed into VC-4 payloads,
  33. > with bytes and octet boundaries in sync
  34.  
  35. This is precisely how it will be done.
  36.  
  37. > , but possibly offset within the
  38. > VC-4 payload (i.e. the H4 pointer may be non-zero).   Furthermore, in the
  39. > worst case, a cell could span two VC-4 payloads (end of one and start of
  40. > the next).  But more recently I'd been told that the rules have been
  41. > changed so that the ATM cells always start in the first byte of the VC-4
  42. > payload and there's no splitting cells across VC-4 payloads.
  43. ..
  44.  
  45. Take a look at this: The payload size reserved for ATM cells in VC-4
  46. will be 2340 bytes, which isn't any integer multiplied by 53. Thus,
  47. it doesn't matter wrether the cell starts in the first byte or not,
  48. the cells will always cross the VC-4 boundary. The cell delineation
  49. will be done by the means of HEC (CCITT Rec. I.432).
  50.  
  51. Jan
  52.