home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / ST2 / 94JUL.MIN < prev    next >
Encoding:
Text File  |  1994-08-13  |  10.3 KB  |  254 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. Date: Fri, 12 Aug 1994 12:37:34 -0400
  4. From: Lou Berger <lberger@bbn.com>
  5.  
  6.  
  7.      Minutes for Toronto IETF ST-II Working Group Meeting
  8.                July 26th and 28th, 1994
  9.  
  10. Reported by: Steve Jackowski (with edits by Lou Berger)
  11.  
  12. The ST-II working group met on Tuesday July 26th and Thursday July 28th
  13. from 1:30 to 3:30 p.m. Luca Delgrossi and Lou Berger chaired the meeting
  14. with Steve Jackowski acting as Scribe.  The objective of these meetings
  15. was to resolve all outstanding issues in the revision to ST-II so that
  16. new internet working drafts could be completed by the end of September
  17. 1994.
  18.  
  19. The Tuesday meeting began with a review of working group actions to
  20. date.  This included some substantial protocol simplification and the
  21. issuing of new drafts.  The rest of the meeting was focused on reviewing
  22. the existing draft documents.
  23.  
  24. In the latest revision two of the drafts were combined.  There are now
  25. two documents rather than three.  The are:
  26.         Introduction to ST-II
  27.     ST Protocol Specification
  28.  
  29. It was agreed that the Introduction Document just required editing and
  30. no technical issues need to be resolved.  So the Working Group focused
  31. on review of the ST Protocol Specification (dated 7/24/94).  
  32.  
  33. The second draft includes many updated ares.  Some areas still need
  34. to be written, which is the reason why the drafts have not been issued
  35. as Internet Drafts.  There are also some new areas.  It was pointed out
  36. that the draft still needs a good introduction.
  37.  
  38. The group discussed the name of the revised protocol.  It was agreed
  39. that the new name would be ST-2+, and that it will be distinguished from
  40. ST-II by having a version number one greater than the current ST-II value.
  41.  
  42. The rest of the meeting was spent reviewing the current draft.  Key
  43. areas of change and clarification were highlighted.  Areas discussed
  44. were:    
  45.  
  46. o    User service description
  47.  
  48. This section was updated per previously agreed upon changes.  Key issues
  49. were when data can be sent and when messages may be processed.  (Data
  50. will not be sent until at least one ACCEPT has been received by the
  51. origin.)  It was agreed that drop messages will be added to the service
  52. model state machine to reflect the 'no change' of state in established,
  53. change, or add states.
  54.  
  55. o    Stream set-up
  56.  
  57. This section was updated for clarity.  The only change was that ACKs are
  58. required in response to CONNECT messages.  The section will be updated
  59. to indicated that if a joining target cannot support minimum flowspec,
  60. it should refuse.
  61.  
  62. o    Data transfer
  63.  
  64. This section was updated per previously agreed upon changes and mirrors
  65. the changes in the user service description.  The additional topic of
  66. MTU was covered.  MTU is now in the CONNECT and ACCEPT messages and is
  67. updated on a hop by hop basis.  Maximum message size is obtained from
  68. the ACCEPT message.
  69.  
  70. o    Stream modification
  71.  
  72. This section will be based on IBM's implementation.  The basis of this
  73. section can be found in ibminet.awdpa.ibm.com:pub/st/st2-recv.ps.  An
  74. open issue was identified that was discussed in the second session.  It
  75. was also pointed out that the SID is missing in the JOIN packet format.
  76.  
  77. o    Stream tear-down
  78.  
  79. No Changes were made to this section.
  80.  
  81. o    Stream set-up: exceptional cases
  82.  
  83. Sections on time-out handling and path convergence need to be updated.
  84. Time-out handling will be updated to include 2 time-out periods, one
  85. pre-ACK and one post, rather than one per message type.  Path
  86. convergence has been removed for simplicity.  Source Routing as an
  87. operational option will be dropped.  Lastly it was agreed that Section
  88. 6.3 is in the wrong place and will be moved to stream setup section.
  89.  
  90. o    Failure detection and recovery
  91.  
  92. This section was updated for clarity.  It was agreed that precedence
  93. will be the chosen word to replace StreamImportance, and that the
  94. section on recovery timeout needs to be clear about stream teardown.
  95. Stream preemption will also be clarified to allow intermediate nodes to
  96. optionally rebuild a stream after preemption.  In this case, if
  97. successful, a REFUSE is not sent to the upstream node.
  98.  
  99. o    Groups of streams
  100.  
  101. Previously agreed upon changes were documented.
  102.  
  103. o    Ancillary functions
  104.  
  105. This section still needs to be updated.
  106.  
  107. o    FlowSpec
  108.  
  109. Previously agreed upon changes were documented.  This included the
  110. definition of the Null FlowSpec for SCMP testing.  The use of a uniform
  111. FlowSpec across single stream, and the introduction of QoS classes.
  112. Allocation implication of QoS classes were discussed in Thursday's
  113. session.  This section will also be updated to cover FlowSpec
  114. reconciliation. 
  115.  
  116. o    State machines
  117.  
  118. The state machines were updated by Murali Rajagopal.  They are available
  119. in postscript and were handed out in the meeting.
  120.  
  121.  
  122. Second session, July 28th
  123.  
  124. The goal of the Thursday meeting was to resolve all major outstanding
  125. issues.  The session began by listing all sections needing to be written
  126. or updated, but not containing any technical issues.  Those sections
  127. are:        
  128.     -      2.2.1    Empty target list
  129.         -      2.6[new]    MTU discovery
  130.         -      4.1         The origin adding new targets  
  131.             FlowSpec handling on stream expansion
  132.         -      4.2         A target joining a stream (import)
  133.         -      6.1         Setup failures
  134.                     Time-out handling
  135.         -      6.2         Further issues
  136.                     Path convergence
  137.         -      6.3.3    Join authorization (import)
  138.         -      7.1         Failure detection    
  139.  
  140. The rest of the meeting was spent reviewing issues to be resolved.  The
  141. issues were:
  142.         -      SCMP fragmentation
  143.         -      CHANGE-REQUEST message
  144.         -      STATUS / HELLO messages
  145.         -      Groups of stream
  146.         -      FlowSpec
  147.                >>     Jitter / latency range
  148.                >>     Definition of parameters with predictive QoS
  149.         -      Sub-network usage
  150.         -      IP encapsulation / IP multicast
  151.         -      Sub-streams / drop priorities
  152.         -      Reason codes
  153.  
  154. o      SCMP fragmentation
  155.  
  156. The issue discussed was handling of the case where SCMP messages are
  157. larger than the path MTU.  Two alternatives were discussed: generic SCMP
  158. fragmentation and multiple messages and truncation.  The group decided
  159. to maintain procedure of sending multiple messages and truncating
  160. long SCMP messages or parameters as currently specified in RFC1190.
  161.  
  162. o      CHANGE-REQUEST message   
  163.  
  164. This discussion centered around the issue of are CHANGE-REQUEST messages
  165. end-to-end messages or can they be generated by intermediate agents.  It
  166. was agreed that as currently specified, CHANGE-REQUESTs are only
  167. end-to-end and can be supported out of band.  Therefore this message
  168. will be eliminated.  It was also agreed that if sub-streams were ever
  169. added this type of message may be needed by intermediate agents.
  170.  
  171. o      STATUS / HELLO messages
  172.  
  173. Two separate issues were discussed.  The first issue was if these
  174. messages should be combined.  These messages share a very similar
  175. format but serve very different functions.  It was agreed that these
  176. messages should be kept separate.
  177.  
  178. The second issue discussed was the question of can HELLO be sent when
  179. no streams exist.  Since HELLO is really designed to be a stream
  180. failure detection mechanism, it was decided to not allow HELLO message
  181. exchange when no streams exist.  It was also pointed out that STATUS
  182. messages can be used to detect/poll neighbor ST agents.
  183.  
  184. o      Groups of stream
  185.  
  186. The issue discussed was really if sub-set implementations are to be
  187. allowed.  It was felt that sub-set implementations should not be
  188. included in the new spec, and that this was a major problem with
  189. RFC-1190.  It was therefore agreed that support of groups of streams
  190. will be required.
  191.  
  192. o      FlowSpec
  193.  
  194. Two separate issues were discussed.  The first issue was addressing
  195. the inability to specify an acceptable latency range.  A proposal was
  196. put forward to add a latency range field.  The origin would set
  197. maximum acceptable latency range.  Each intermediated agent would add
  198. to minimum and maximum delay and check to see if maximum is exceeded.
  199. The possible latency range is maximum less minimum.  This proposal was
  200. accepted.
  201.  
  202. The second issue discussed was FlowSpec interpretation with predictive
  203. QoS.  A proposal was put forward and was rejected.  An alternative was
  204. accepted.  The alternative was to use current size and rate fields as
  205. peak values, and to add new fields for average size and rate values.  It
  206. was also agreed to investigate the viability of using other published
  207. FlowSpecs and not defining an ST specific FlowSpec.
  208.  
  209. o      Sub-network usage
  210.  
  211. The issue discussed was the definition of expected resource and
  212. multicast address management services provided by sub-networks.  It was
  213. agreed that all services are to be provided solely by each sub-network,
  214. and that sub-net issues are outside scope of document.  References to
  215. sub-network issues will be eliminated from the document.  It is expected
  216. that sub-network issues will be addressed in future documents, e.g. ST
  217. over ATM or ST over ethernet.
  218.  
  219. o      IP encapsulation / IP multicast
  220.  
  221. The definition of IP encapsulation of ST was reviewed.  Some
  222. implications of RFC-1190 will be clarified in the new spec.  A new field
  223. will also be added to count the number of IP encapsulated hops along a
  224. path.  The spec will be clarified to state that the predictive
  225. capabilities are lost when IP encapsulation is used.  The spec will also
  226. be updated to state that if the multicast parameter is used in the
  227. CONNECT message, the receiving agent must be able to receive on the
  228. specified address in order to accept the connection.
  229.  
  230. o      Sub-streams / drop priorities
  231.  
  232. Sub-streams and drop priorities are separate issues.  It was agreed that 
  233. drop priorities will be preserved.
  234.  
  235. The sub-streams issue was that sub-streams have been brought up
  236. repeatedly in working group sessions, but no definition has yet been
  237. agreed upon.  It was agreed that sub-streams will not be specified.  The
  238. remaining bits will be left unspecified.  These bits will not be set,
  239. not examined, and passed through by routers.  This allows for possible
  240. future extensions to the protocol, even to support sub-streams.
  241.  
  242. o      Reason codes
  243.  
  244. Reason codes still need to be reexamined and updated.
  245.  
  246. The meeting concluded (about an 1 hour late) with a review of action
  247. items: 
  248.         -      Investigate other FlowSpecs
  249.         -      Update introduction
  250.         -      Document finite state machine diagrams
  251.         -      Complete draft specification
  252.  
  253. With no further business to discuss, the session was adjourned.
  254.