home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 722 < prev    next >
Encoding:
Text File  |  1992-11-13  |  2.9 KB  |  65 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!stanford.edu!kronos.arc.nasa.gov!iscnvx!news
  3. From: myoung@force.ssd.lmsc.lockheed.com
  4. Subject: Reverse Multiplexing
  5. Message-ID: <1992Nov13.153648.1194@iscnvx.lmsc.lockheed.com>
  6. Sender: news@iscnvx.lmsc.lockheed.com (News)
  7. Reply-To: myoung@force.ssd.lmsc.lockheed.com
  8. Organization: LMSC, Sunnyvale, California
  9. Date: Fri, 13 Nov 92 15:36:48 GMT
  10. Lines: 53
  11.  
  12. Reverse Multiplexing:
  13.  
  14. OK, I will attempt to define a reverse multiplexing procedure for
  15. cell relay.
  16.  
  17.  
  18. Reverse multiplexing over cell relay should be able to distribute a cell
  19. stream over disjoint parallel paths toward a common destination, where
  20. the cell stream is re-ordered and delivered to the desktop.  The 
  21. algorithm for finding the total common flow over parallel paths to
  22. a common point has two phases; 1) Find the parallel paths going in
  23. the forward direction, and 2) Augmenting these paths with local flows 
  24. which go operate in the backward direction but contribute to the overall
  25. flow. (See any text on graph theory).  To simplify the discussion let
  26. us consider only the parallel, forward flows.
  27.  
  28. Place some embedded reverse multiplexing processors at common regions
  29. of the wide area network, and connect these with some set of virtual
  30. paths used for out of band communication.  Any of the distributed
  31. processes can find a set of parallel flows to any other using a wave
  32. which operates similar to the wave based source routing, but splits
  33. in parallel at each node during the search process, and collects all
  34. parallel routes, returning them in the wave syntax for further operation.
  35.  
  36. The reverse multiplexors then present these parallel paths as a single
  37. path to some higher order process.  Any desktop, (or another protocol 
  38. specific router) can find virtual paths using the reverse multiplexors. 
  39.  
  40. Upon usage, the reverse multiplexors using their pre computed paths would 
  41. reserve bandwidth on each of the parallel routes, using the same bandwidth 
  42. reservation process mentioned in a previous post.  Simultaneously, the 
  43. virtual path tables would be updated, (unless the paths are permanently 
  44. connected).
  45.  
  46. Over the out of band control net, the multiplexors would exchange an 
  47. ordering table which lets the receiver re-order the cells incoming over
  48. multiple paths, then forward the cell stream to the final destination.
  49. This re-ordering table would be exchanged after the bandwidth reservation
  50. process since some off the pre-computed paths may not have available
  51. bandwidth and would be left out of the current message exchange.
  52.  
  53. The entire process operates at the cell level, never assembling the
  54. message to look at the network layer as an embedded router would do.
  55.  
  56. Key components:
  57.  
  58.   * Use of an embedded processor.
  59.   * Out of band control system.
  60.   * Use of wave to implement distributed protocol and gain access to
  61.     path tables.
  62.   * Re-use of the serial path and bandwidth control schemes in a parallel
  63.     algorithm.
  64.   * Helps the cell relay to expand into sub-T1 market.
  65.