home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / ST2 / 94DEC.MIN < prev    next >
Encoding:
Text File  |  1995-06-26  |  10.8 KB  |  279 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Steven Jackowski/Syzygy Communications
  5.  
  6. Minutes of the Internet Stream Protocol V2 Working Group (ST2)
  7.  
  8.  
  9. Introduction
  10.  
  11. The ST2 Working Group met on 6 and 7 December 1994 at the 31st IETF
  12. meeting in San Jose, California.  Lou Berger chaired the meeting with
  13. Steve Jackowski acting as Scribe.  Luca Delgrossi, the working group
  14. co-chair, was unable to attend.  The objective of the meeting was to
  15. finalize all outstanding issues with the current Internet-Draft to
  16. prepare it for submission as an RFC, and to set the direction for the
  17. rest of the working group's activities.
  18.  
  19. Lou first introduced the group's Area Director, Stev Knowles, who had a
  20. few comments for the group.  Steve indicated that the IESG is not
  21. looking favorably on certain press statements about ST or ST-2+.  The
  22. primary point was that some press has indicated that ST-2 is a new
  23. Internet Standard.  As stated in the working group's charter, ST is on
  24. the experimental track and will not be a ``Internet Standard.''  Stev
  25. requested that those involved with ST make sure that they, and their
  26. respective organizations, properly represent the work on ST in the IETF.
  27.  
  28.  
  29. Agenda
  30.  
  31. The agenda for the rest of sessions was:
  32.  
  33.  
  34.    o Agenda bashing
  35.    o Status of draft
  36.    o Overview of changes
  37.    o Detailed review of draft
  38.    o Discussion on open issues
  39.    o Wrap up
  40.  
  41.  
  42. Status of the Draft
  43.  
  44. The current draft is draft-ietf-st2-spec-01.fps, txtg.  It is the second
  45. draft issued since the Toronto meeting.  The next version is in progress
  46. and will be issued in January.  It is expected that this will be a
  47. complete draft.  Originally, the working group had planned to produce
  48. three RFCs:
  49.  
  50.  
  51.   1. Introduction to ST technology
  52.   2. Design of ST2 protocol
  53.   3. Protocol message formats
  54.  
  55.  
  56. At the Toronto meeting it was agreed to merge the message formats into
  57. the Design document.  In this meeting it was agreed to consolidate the
  58. key portions of the Stand-alone Introduction with the Introduction of
  59. the Design Document (Section 1).  Thus, the main output of this working
  60. group will be published as one document.
  61.  
  62. Since the State Diagrams section has not been reviewed to the same level
  63. as the rest of the draft, it was agreed that the diagrams will be
  64. finalized and published separately.
  65.  
  66.  
  67. Overview of Changes
  68.  
  69. An overview on changes in the draft since Toronto was given.  A list of
  70. sections that had been updated or written was review.  The group also
  71. reviewed which sections still need updating.
  72.  
  73.  
  74. Detailed Review of Draft
  75.  
  76. Moving on to other sections of the current document, the group reviewed
  77. changes to the current Internet-Draft section by section and discussed
  78. and resolved any outstanding issues:
  79.  
  80.  
  81. Section 1
  82.  
  83. The merge of the introduction draft into Section 1 is still in progress.
  84. The current draft now has an introductory section, but it is not yet
  85. complete.
  86.  
  87.  
  88. Section 2
  89.  
  90. There were no changes to Section 2.
  91.  
  92.  
  93. Section 3
  94.  
  95. SCMP Functional Description (3) needs an introduction of types of
  96. streams and impact on states.  This section may also serve as a place
  97. for examples of applications using the various types of streams such as
  98. when different levels of Join authorization are used.
  99.  
  100. In Section 3.1.4.1, text will be updated to indicate that excess
  101. resources should be released when processing ACCEPT.
  102.  
  103. In 3.2.2 and 3.4.2, Join Authorization was introduced based on the IBM
  104. implementation.  Their implementation included a level that the group
  105. agreed (at GMU) could be implemented by using an out-of-band message.
  106. This level, known as `Ask Origin' will be deleted from the next version
  107. of the draft.
  108.  
  109. It was also pointed out that state is a critical aspect of the Join
  110. authorization.  That is, if the origin is not notified of the Join,
  111. state information is not complete, and recovery is not possible.
  112.  
  113. An issue related to join level 2 (OK, do not notify origin) was
  114. discussed next.  The issue is that with level 2 streams an origin may
  115. not be able to disconnect specific targets because full state is not
  116. maintained in all ST agents.  A method to support this type of
  117. disconnect was proposed at GMU by one of the attending students.  The
  118. method is to flood the disconnect to all next hop agents when the join
  119. level is 2 and the specified target is unknown.  The group unanimously
  120. agreed that this solution provides uniformity at the application level
  121. and therefor should be used.
  122.  
  123. Two issues were discussed relating to Section 3.4.2.  The first was that
  124. the Join FlowSpec is not needed and references will be removed from the
  125. document.  The second issue was that a JOIN-REJECT message type had been
  126. discussed but was not in the latest draft.  It was agreed that this
  127. message should still be added.
  128.  
  129. In Section 3.4.4 a description of Refuse handling under different join
  130. levels will be added.
  131.  
  132. The next issue related to Section 3.4.5.  The issue is that while
  133. processing a CHANGE message, an agent may interrupt the flow of data.
  134. It was agreed that this is not preferred behavior, and that by default
  135. the processing of a CHANGE message should not interrupt data delivery.
  136. This implies that CHANGE messages that require interruption of data flow
  137. to satisfy the request must be rejected.  It was also agreed that an
  138. `interruptible' flag will be added to the change message that indicates
  139. its is acceptable to interrupt data flow while processing the change
  140. request.
  141.  
  142.  
  143. Section 4
  144.  
  145. Two issues were discussed related to Sections 4.1.1 and 4.1.2.  The
  146. first issue was that the handling of the case of where a CONNECT message
  147. is acknowledged but an ACCEPT is never received.  This case needs to be
  148. added.  The second issue is that these sections still need to be made
  149. consistent with Section 7.3.
  150.  
  151. In Section 4.2.2, there is an issue with path convergence in the case of
  152. a `diamond' or loop topology:  It is possible that a given agent will
  153. receive two connects for the same stream from two different previous hop
  154. agents.  This problem has been seen in operational networks using ST.
  155. Lou proposed that this case can be handled by having the agent at the
  156. point of convergence send a refuse with a reason code of `path
  157. convergence' and include the target address of a valid target on the
  158. pre-existing stream to be used as a `hint target.'  Each upstream agent
  159. receiving the REFUSE will check to see if the listed `hint target'
  160. exists in the agents stream state.  If the `hint target' is not known,
  161. the REFUSE is propagated upstream.  If the `hint target' is known, then
  162. the agent is the agent that split the stream.  This agent can then use
  163. the next hop of the `hint target' as the next hop for the new target.
  164. This method handles the `stream-divergence' for all cases for full state
  165. streams.  For streams that do not have full state maintained (join type
  166. `OK') this solution may not succeed.  The group accepted the proposal.
  167.  
  168.  
  169. Section 5
  170.  
  171. Two issues were discussed related to Section 5.2.  The first issue was
  172. that it is not always clear when recovery should be attempted.  It was
  173. agreed to add a NoRecovery flag to the Refuse message, and that agents
  174. set the flag when they wish to indicate that recovery is not possible or
  175. has been tried too many times.  The second issue is that the current
  176. draft has an error related to stream tear-down at the target.  It was
  177. agreed to have the application tear down streams that have errors; they
  178. should not wait for a possible recovery.
  179.  
  180.  
  181. Section 6
  182.  
  183. Section 6 needs a minor update:  in Section 6.1, GroupID and GroupName
  184. fields need to be fully specified.
  185.  
  186.  
  187. Section 7
  188.  
  189. A minor update is needed in Section 7.1.  The stream ID generation
  190. function needs to be specified.  This is basically the same as group
  191. name generation function.
  192.  
  193. In Section 7.3 two variable names must be defined.
  194.  
  195. Section 7.5 needs to be completed.  This is a very simple section that
  196. will recommend discarding of lower priority traffic in the event of
  197. network congestion.
  198.  
  199. One of the readers of the current draft pointed out that the draft does
  200. not cover handling of the case where next hop agents can not handle the
  201. indicated IP multicast address.  Section 7.7 will be updated that when
  202. the next hop cannot handle a given IP multicast address (on IP
  203. encapsulated segments), the next hop agent should send a Refuse with
  204. appropriate reason code.  A question was raised as to whether an IP
  205. multicast address could be included in a standard targetlist.  It was
  206. pointed out that this would require significant state changes for the
  207. origin agents.
  208.  
  209.  
  210. Section 9
  211.  
  212. State machines need to be reviewed and updated.  They will be published
  213. separately.  Murali Rajagopal, the author of the state diagrams, gave a
  214. brief introduction to the state diagrams and agreed to coordinate the
  215. publishing of the state diagram document.
  216.  
  217. One of the participants mentioned that he has a contractor that will be
  218. modeling both the RFC 1190 and current versions of ST. He agreed to make
  219. the results of this work available to the group.  This should be very
  220. helpful in validating the new version.
  221.  
  222.  
  223. Section 10
  224.  
  225. Three issues were discussed related to Section 10.  The first issue was
  226. that the SID, which is currently split in the ST header, needs to be
  227. made contiguous.  The second issue is that in Section 10.3.2, the IPHops
  228. field will be added to the FlowSpec.  The last issue is that reason
  229. codes will be reviewed via the mailing list.
  230.  
  231.  
  232. Section 11
  233.  
  234. It was pointed out that a number of changes that had been discussed
  235. during the sessions would require minor changes to the packet formats
  236. listed in Section 11.  Additionally, one new issue was raised.  The
  237. ErroredPDU parameter is only used in the ERROR message.  Since this
  238. parameter is used by only one message, this parameter will be combined
  239. with the error message.
  240.  
  241.  
  242. Section 12
  243.  
  244. A list of suggested protocol constants needs to be created.
  245.  
  246.  
  247. Discussion on Open Issues
  248.  
  249. The group discussed the idea of making the ST header compatible with the
  250. IP header.  It was agreed that there were no real technical advantages
  251. to this as IP processing would have to be done in any case at ST-IP
  252. boundary agents.
  253.  
  254. It was agreed that a delta between RFC 1190 and ST-2+ would be added to
  255. the current document.  Steve Batsell will complete this and submit it to
  256. the chairs.
  257.  
  258. Mark Pullen suggested the possibility of having one of his grad students
  259. create an implementation of ST-2+ if he could start with a solid version
  260. of ST. Steve Jackowski stated that he would explore the possibility of
  261. getting Mark a copy of Syzygy's code as a base.
  262.  
  263. Lou Berger agreed to pass the FlowSpec by Craig Partridge for comments.
  264.  
  265.  
  266. Wrap Up
  267.  
  268. A final version of the Internet-Draft will be published for review in
  269. mid January.  Once review is complete the draft will be submitted to be
  270. published as an RFC.
  271.  
  272. The next pass at a State Diagrams will be made available by January
  273. 1995.  The target completion date of the state diagrams draft is March
  274. 1995.  It is expected that the state diagram draft will be reviewed at
  275. the next IETF, and then the draft will be updated and submitted to be
  276. published as an RFC. Once state diagrams are complete the working
  277. group's efforts will be complete.
  278.  
  279.