home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 686 < prev    next >
Encoding:
Text File  |  1992-11-09  |  4.2 KB  |  84 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!munnari.oz.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!augean.eleceng.adelaide.edu.AU!ksarkies
  3. From: ksarkies@augean.eleceng.adelaide.edu.AU (Ken W. Sarkies)
  4. Subject: Re: ATM "style" (was: Lockheed Switch)
  5. Message-ID: <1992Nov10.065059.3466@augean.eleceng.adelaide.edu.AU>
  6. Keywords: ATM switching traffic
  7. Organization: Electrical and Electronic Eng., University of Adelaide
  8. References: <ru9l3ps@sgi.sgi.com>
  9. Date: Tue, 10 Nov 1992 06:50:59 GMT
  10. Lines: 72
  11.  
  12. In article <ru9l3ps@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
  13. >myoung@force.ssd.lmsc.lockheed.com writes:
  14. >+---------------
  15. >| I had a request to post info on the Lockheed switch... We have proposed
  16. >| a bufferless control structure... A modified deflection routing scheme...
  17. >| at each network switch, a data packet must bid for an output link... by
  18. >| providing an ordered list of links for each packet... Conflicting bids
  19. >| for the same output port are nondeterministically solved.... implemented
  20. >| using technologies that are scalable both in speed and network configuration.
  21. >+---------------
  22. >
  23. >In further conversations with one of the researchers referred to me by Matt,
  24. >I found that this switching scheme is really quite clever. I wouldn't be at
  25. >all surprised if it could be used to build inexpensive multi-gigabit LANs.
  26. >
  27. >However, the "deflection routing" architecture inherently re-orders packets
  28. >(or frames, cells, whatever), very severely when put under a heavy load.
  29. >(After all, it handles congestion by routing packets "somewhere else" for
  30. >a while.) Using it in an ATM environment would be a real challenge. Using
  31. >it directly with unmodified AAL1, AAL2, or AAL5 would be impossible.
  32. >
  33. >This points up one of the really fallouts that I predict is about to
  34. >occur from our industry-wide rush towards ATM (and yes, I include myself
  35. >in that rush). There are many kinds of potentially useful network and
  36. >switch architectures which are going to be pushed aside because they are
  37. >incompatible with the ATM "style" (small cells, ordered delivery, bandwidth
  38. >declared at call setup, even the very requirement of "call setup").
  39. >
  40. ..... other stuff deleted
  41.  
  42. >
  43.  
  44. In this department we have been working on ATM switch architectures for a
  45. few years, and are now looking at performance aspects of various general
  46. structures. A few general considerations which need to be kept in mind are
  47.  
  48. 1. The BISDN is supposed to be a high speed network, so we do not want
  49. to be encumbered by the protocols. They should be simple and efficient.
  50. For that reason it is reasonable to look for switches which do not break
  51. up cell ordering.
  52.  
  53. 2. Switches must work at least as fast as the optical fibre links to which
  54. they are connected. This is not likely to be possible electronically
  55. without a great deal of hardware and parallelism. They should not be more
  56. complex than is necessary.
  57.  
  58. 3. Under normal conditions, switches will not be overloaded longer than
  59. the buffers can handle. Rarely, brief overloads may occur on selected outputs.
  60. A switch which recirculates blocked cells would be very useful, but not
  61. necessarily essential. However cell reordering can be done at the switch
  62. outputs, with little problem (probably in output buffers), to satisfy the
  63. standards.
  64.  
  65. 4. Under overload conditions (allowed by the traffic control in the network),
  66. switches can be overloaded for longer periods. In such cases it is expected
  67. that cells will be lost, in which case recirculation, deflection routing
  68. etc. will not help. It is important only that in the switch, innocent traffic
  69. is protected. Switches which have recirculation or other rerouting of overload
  70. traffic may have the potential for the overload traffic to cause cell loss
  71. on streams which are not passing to overloaded outputs. That in my opinion
  72. is where the real problem with such architectures lies.
  73.  
  74. I believe that ultimately the simpler switches will turn out to be preferred
  75. on the basis that they can be produced cheaper and faster and more flexible
  76. than the more
  77. complex architectures. Note that this is not a criticism of the Lockheed
  78. architecture, but a general comment.
  79.  
  80. -- 
  81.                                 Ken Sarkies
  82.  
  83. No disclaimer. My boss takes all responsibility for my big mouth.
  84.