home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 91jul / cbnrbof-minutes-91jul.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  4.0 KB  |  103 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Andy Nicholson/Cray Research, Inc.
  6.  
  7. CBNR BOF Minutes
  8.  
  9. Description:
  10.  
  11. We held a BOF on this subject at the 20th IETF in St.  Louis, and this
  12. is a continuation of that interchange.  However, the only attendees from
  13. the St.  Louis meeting present at this meeting were the Cray Research,
  14. Inc.  representatives.
  15.  
  16. While working with circuit-switched T3 networks, developers at Cray
  17. Research, Inc., determined that there would be advantages to defining a
  18. standard way to control certain classes of network resources through the
  19. internet.  In the case of a circuit-switched T3 line, the line should be
  20. switched on only when there are active transport connections which can
  21. fully utilize the service.  Due to the high cost of the resource,
  22. under-utilization would be particularly undesirable.  The developers
  23. believe that this capability might have other applications in the
  24. internet and that an effort should be made to define a standard
  25. protocol.
  26.  
  27. Minutes:
  28.  
  29. Due to the small size and informality of the meeting, no formal Minutes
  30. were taken.  This record is believed to be reasonably accurate and
  31. proper credit given to the originators of the ideas and concepts
  32. presented.  Andy Nicholson, who is preparing this report, apologizes for
  33. any errors or omissions.
  34.  
  35. A variety of new issues were brought up at this meeting, and it was
  36. encouraging to note that there were as many non-Cray people as Cray
  37. employees.  Most of the discussion centered around the concrete example
  38. of the Circuit-Switched T3 services being prototyped by Cray Research,
  39. Inc.
  40.  
  41. The first issue raised centered on local routing to the T3 adapter.
  42. This would include routing to any controlled device.  The prototypes
  43. assume that a particular network link will be used for transfer of data
  44. packets, thus static routing is implied.  There is concern that this
  45. perspective may lead to the use of static routing between the requesting
  46. host and the controlled resource.  There was general agreement that this
  47. should not happen.
  48.  
  49. Another issue concerned recursive conditioning of resources.  A host in
  50. control of a link might need to pass a request to another host through
  51. the controlled link so that further downstream links may be conditioned.
  52. This should be possible.
  53.  
  54. Fred noted that some comparisons could be made with regard to this
  55. capability.  For example, this is similar to the switching which takes
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. place through the telco fabric as calls are routed.  There is also a
  64. similarity to X.25.  For example, TP0 will create a link over x.25 when
  65. a connection is established.
  66.  
  67. Matt did not think that this could be a widely deployed function;
  68. however, Fred noted that this might be useful in any kind of
  69. fundamentally switched service, i.e.  ISDN or mobile hosts.  This seems
  70. like something that is in the future.
  71.  
  72. In the Cray Research, Inc.  prototype, most of the support code is in
  73. the kernel.  Matt and Fred were concerned that perhaps this should all
  74. reside in user space.  This leads to two fundamentally different
  75. approaches.  For everything to be in user space, either special commands
  76. must be executed to condition the network before running applications,
  77. or the applications must make special library calls.  If everything is
  78. in the kernel, then these services can be transparent to users and
  79. applications.
  80.  
  81. These discussions led us to a very different conclusion from the last
  82. meeting.  All agreed that I would finish an informational RFC relating
  83. our experiences with the switched T3 services in time for review by the
  84. community before the next IETF. If possible, I will also document the
  85. protocol we are using.
  86.  
  87. At the 22nd IETF we will once again hold a BOF to gauge interest in
  88. these facilities.  At that meeting we will determine whether to continue
  89. any work through the IETF.
  90.  
  91. Attendees
  92.  
  93. Fred Baker               fbaker@emerald.acc.com
  94. David Borman             dab@cray.com
  95. Matt Mathis              mathis@psc.edu
  96. Andy Nicholson           droid@cray.com
  97. John Seligson            johns@ultra.com
  98. Jeff Young               jsy@cray.com
  99.  
  100.  
  101.  
  102.                                    2
  103.