home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / cellrel / 775 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  1.8 KB
  1. Path: sparky!uunet!pipex!warwick!uknet!pavo.csi.cam.ac.uk!mdh
  2. From: mdh@cl.cam.ac.uk (Mark Hayter)
  3. Newsgroups: comp.dcom.cell-relay
  4. Subject: Re: fat cells (was Re: Computers dont like ATM?)
  5. Message-ID: <1992Nov23.180730.22608@infodev.cam.ac.uk>
  6. Date: 23 Nov 92 18:07:30 GMT
  7. References: <sjdveq8@sgi.sgi.com>,<1992Nov20.122227.6002@infodev.cam.ac.uk> <1992Nov20.150333.17701@iscnvx.lmsc.lockheed.com> <1992Nov20.211632.18945@infodev.cam.ac.uk> <1992Nov23.135258.29925@merlin.dev.cdx.mot.com>
  8. Sender: news@infodev.cam.ac.uk (USENET news)
  9. Organization: U of Cambridge Computer Lab, UK
  10. Lines: 27
  11. Nntp-Posting-Host: forties.cl.cam.ac.uk
  12.  
  13. peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
  14. > I'm curious as to why you chose to aggregate all the cell headers at
  15. > the front of the packet, rather than just the first - did this design
  16. > predate AAL5?
  17.  
  18. Yes, our internetworking protocol and its datalink layers were in use
  19. well before AAL-5. The original version was designed by Derek McAuley
  20. as part of his thesis work in 1988-9, and this is based on an earlier
  21. SAR protocol. In this the SAR information is contained in the header, so
  22. we wish all headers to be carried to the end points (remember we are just
  23. doing cell forwarding at the ethernet-ATM boundary, this does not know
  24. anything about SAR). Clearly the end system on the ethernet is happier if
  25. all the data is contiguous (in the common case of no cell loss all that 
  26. needs to be done is scan the SAR to see it has the expected values and
  27. DMA the data to its IPC buffer). The SAR information contains the
  28. equivalent of the "user indication" bit. In fact we experimented with
  29. two bits (essentially start and end of block) but only one is actually
  30. required.
  31.  
  32. Mark
  33.  
  34. -- 
  35. ------------------------------------
  36. Mark Hayter
  37. Cambridge University Computer Lab
  38. Mark.Hayter@cl.cam.ac.uk
  39. Tel +44 223 334645
  40.