home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / cellrel / 751 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.0 KB  |  74 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!sun-barr!ames!sgi!rigden.wpd.sgi.com!rpw3
  3. From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
  4. Subject: Re: Computers dont like ATM?
  5. Message-ID: <sjdveq8@sgi.sgi.com>
  6. Sender: rpw3@rigden.wpd.sgi.com
  7. Organization: Silicon Graphics, Inc.  Mountain View, CA
  8. Date: Fri, 20 Nov 1992 09:01:16 GMT
  9. Lines: 63
  10.  
  11. finn@dalek.isi.edu (Greg Finn) writes:
  12. +---------------
  13. |     ATM is politically very popular.  Arguments that ATM brings
  14. | about end-to-end compatibility do not impress me.  Most LAN traffic
  15. | stays within the LAN.  Forcing LANs to comply with WAN data-link
  16. | standards is putting the cart before the horse.
  17. +---------------
  18.  
  19. Especially when end-to-end "ATM compatibility" can be achieved *without*
  20. ATM-sized cells in the LAN! I have been harping on an idea I call "fat cells",
  21. which is basically that you switch AAL_PDU-sized packets in the LAN, with
  22. exactly one ATM header on the front of the AAL PDU. When the packet is to be
  23. routed out of the LAN via "real ATM", as it chops it up into real ATM-sized
  24. 53-byte cells, the gateway switch can replicate the prototype header onto the
  25. front of each cell. (For AAL5, it must also set the "end-of-frame" indication
  26. in the header of the last cell in the PDU.) Naturally, it is also the respon-
  27. sibility of the gateway switch to reassemble incoming cells into PDUs (leaving
  28. a prototype ATM header on the front), and switch these "fat cells" (complete
  29. AAL PDUs) into the LAN.
  30.  
  31. Think of it as transparent bridging between "cell relay" and "ATM-formatted
  32. frame relay".
  33.  
  34. Since AAL1 & AAL2 traffic don't have natural "PDU" boundaries, you could
  35. set an "aggregation ratio" at call-setup time, that says how many cells
  36. should be included in each "fat cell" on the LAN.
  37.  
  38. The fun thing about "fat cells" is that a native-mode ATM terminal at the
  39. far end of the circuit cannot tell that you are sending/receiving "fat cells"
  40. instead of 53-byte cells!
  41.  
  42. Another fun thing is that we could easily "tunnel" or encapsulate fat cells
  43. inside other protocols such as IP [the *inverse* of using ATM to encapsulate
  44. packets], to provide access to "native ATM" for many, many hosts without ATM
  45. interfaces! So much for "end-to-end ATM compatibility" requiring hardware
  46. changes...  ;-}
  47.  
  48. +---------------
  49. | I have great reservations about what ATM costs us in LANs.
  50. +---------------
  51.  
  52. Likewise, but more for the dampening effect it's already having on alternative
  53. technologies (such as PTM, or gigabit "frame relay", or "fat cells", etc).
  54.  
  55. +---------------
  56. | When ATM-based LAN performance exceeds PTM-based LAN performance/cost,
  57. | ATM proponents will have a much better argument than they now have. 
  58. | Frankly, I don't forsee that happening in the electrical domain.
  59. +---------------
  60.  
  61. Well, I do, actually. Sliding down the price/volume curve, and all that...
  62. Two-chip solutions that go from AAL PDUs to ATM cells to SONET line coding
  63. (and back) are not that far away, at least at 155 Mb/s.
  64.  
  65.  
  66. -Rob
  67.  
  68. -----
  69. Rob Warnock, MS-9U/510        rpw3@sgi.com
  70. Silicon Graphics, Inc.        (415)390-1673
  71. 2011 N. Shoreline Blvd.
  72. Mountain View, CA  94043
  73.  
  74.