home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / ST2 / 95APR.MIN < prev    next >
Encoding:
Text File  |  1995-06-26  |  8.0 KB  |  225 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 in both morning and afternoon sessions on 3
  12. April at the 32nd IETF meeting in Danvers, Massachusetts.  Lou Berger
  13. chaired the meeting with Steve Jackowski acting as Scribe.  Luca
  14. Delgrossi, the working group co-chair was unable to attend due to a new
  15. job.
  16.  
  17. Because the protocol specifications have been submitted as an RFC, the
  18. primary objective of the meeting was to review and discuss the draft of
  19. the State Machine document as well as to determine the future direction
  20. of the group.
  21.  
  22. During the meeting, Frank Kastenholtz introduced himself as one of the
  23. new Internet Area co-Directors.  Sue Thompson is the other new
  24. co-Director.
  25.  
  26.  
  27. Agenda
  28.  
  29.    o Agenda Bashing
  30.    o Status of Group
  31.    o State Machines
  32.       -  Status
  33.       -  Detailed Discussion
  34.    o Open Issues
  35.    o Wrap-up
  36.  
  37.  
  38. Working Group Status
  39.  
  40. The ST2 Working Group had two main chartered goals:
  41.  
  42.   1. Protocol Specification
  43.   2. State Machines
  44.  
  45. Over the mailing list, the group agreed to submit the ST protocol
  46. specification for publications as an Experimental RFC. The protocol
  47. specification, draft-ietf-st2-spec-04.fps,txtg, was submitted on 24
  48. March.  Publication is awaiting IESG action.
  49.  
  50. The State Machine draft, draft-ietf-st2-state-00.fps,txtg, is in
  51. progress with a targeted completion of June.  If the State Machine draft
  52. is indeed completed in this time frame, the working group may not meet
  53. in Stockholm.  The intent is to publish the State Machine document as an
  54. Informational RFC.
  55.  
  56.  
  57. Detailed Review of the State Machine Draft
  58.  
  59. The group began a detailed, section by section review of the State
  60. Machine draft and began to identify issues.  This discussion was led by
  61. Murali Rajagopal, the author of the State Machine draft.
  62.  
  63.  
  64. Sections 2, 3 and General Issues
  65.  
  66. Murali Rajagopal started his presentation of state machines by reviewing
  67. the current draft.  He presented this main design change from previous
  68. drafts which is to use FIFO queues between state machines.  He also
  69. reviewed the message/response table and a message direction table, which
  70. provide a good representation of protocol message relationships.
  71.  
  72. Eric Crawley pointed out a discrepancy between the State Machine
  73. document and the protocol specification in that the State Machine
  74. document refers to `Origin Side' and `Target Side' while the protocol
  75. specification uses `upstream' and `downstream' respectively.
  76.  
  77. It was agreed that the State Machine document would be updated to use
  78. the terms `previous hop' and `next hop' for neighbor dependent terms and
  79. `upstream' and `downstream' for general terms.
  80.  
  81.  
  82. Section 4:  Origin State Machines
  83.  
  84. It was agreed that references to a `State Machine per interface' would
  85. be changed to `State Machine per next hop.'  This clarification is
  86. required because it is likely that there is more than one next hop per
  87. interface.
  88.  
  89. After some discussion, it was agreed to add a reference to timeouts with
  90. respect to awaiting ACCEPTs or REFUSEs.  A timeout in this circumstance
  91. is an implicit REFUSE.
  92.  
  93. The issue of how the sending of data relates to the described states was
  94. discussed at some length.  This issues is described in greater detail
  95. below.
  96.  
  97. The group also discussed the issue of handling a REFUSE message from an
  98. unrelated target while in the middle of a sub-state machine?  It was
  99. agreed that all sub-state machines must process REFUSEs from unrelated
  100. targets.
  101.  
  102.  
  103. Section 5:  Router State Machines
  104.  
  105. The group agreed that the Router State Machine needs clarification as to
  106. when data is permitted and which state machine (upstream or downstream)
  107. controls distribution of data when the multicast group is in transition.
  108.  
  109. It was pointed out that both of the current Router State Machines may be
  110. needlessly complex:  that states to handle REFUSE, ACCEPT, etc., may be
  111. unnecessary.  Once in the Stream-established state, these messages are
  112. events that simply require an ACK. There should be no state transition.
  113.  
  114. It was reiterated that JOIN state does not need to be kept by the
  115. router.  This will be discussed off line and updated in the
  116. specification accordingly.
  117.  
  118.  
  119. Section 6:  Target State Machine
  120.  
  121. It was pointed out that there is an error in the draft, and ADD
  122. functionality should be removed from the Target State Machine.
  123.  
  124. The morning session was adjourned after agreeing to use the afternoon
  125. session to hit the key issues raised in the morning.
  126.  
  127.  
  128. Review of Open Issues
  129.  
  130. The afternoon session was used to begin to resolve the following issues
  131. which were identified in the morning session:
  132.  
  133.  
  134.    o Establish how to handle sending of data after first accept.
  135.    o Resolve where data is forwarded and where is it dropped.
  136.    o Is `E' bit handling on Refuse (refuse of change but do not take
  137.      down stream) included in the current diagrams?
  138.    o Interaction with Local Resource Management is not considered.
  139.    o How are Timeouts addressed?
  140.    o How do we include Error Conditions or failure detection.
  141.    o Do we need an API interface description?
  142.  
  143.  
  144. When Can We Send Data
  145.  
  146. The issue of the relationship between when data forwarding is allowed
  147. and related to specific states was discussed at some length.  It was
  148. agreed that there needs to be more definition of function within
  149. specific states.  In particular, in which states is data transmission
  150. allowed.  It was agreed that states could be eliminated in the Origin
  151. State diagram to allow existence of the stream and data transmission.
  152.  
  153. It was agreed that data forwarding should not be explicitly linked to a
  154. state change, and that data forwarding would be separated from control
  155. state machines.  This may also require a separate state machine for data
  156. forwarding which gets triggered on processing an ACCEPT message.
  157.  
  158. There was much discussion on null streams and JOINs.  It became clear
  159. that there needs to be a per-stream higher level view of the state for
  160. the Origin.  That is, we need state for each stream which includes the
  161. possibility of null streams and JOINs.  However, there still exists
  162. context on a per-next-hop basis.  This whole topic is taken as an action
  163. item to be resolved in the next version of the draft.
  164.  
  165.  
  166. `E' Bit
  167.  
  168. A general comment was made that the processing of the `E' bit in REFUSE
  169. messages must be added to all state diagrams.
  170.  
  171.  
  172. Local Resource Management (LRM)
  173.  
  174. It was agreed that the state machines are missing references to LRM
  175. functions.  While LRMs are not defined in the protocol specification,
  176. certain messages require processing by the LRM. These messages are:
  177. CONNECT, ACCEPT, CHANGE, REFUSE and DISCONNECT.
  178.  
  179. Diagrams will be updated to show LRM interfaces on processing these
  180. messages.
  181.  
  182.  
  183. Other Items
  184.  
  185. Several general points were made on:
  186.  
  187.  
  188.    o Timeouts Timeout handling will be added in the next draft by Sharon
  189.      Sergeant.
  190.  
  191.    o Failure detection State machines for failure processing need to be
  192.      added.  These are largely orthogonal to the control state machines.
  193.  
  194.    o API mapping It was agreed that we a mechanism to add API interfaces
  195.      to state machines.  This does not mean specifying an API, it will
  196.      just describe the suggested API interactions with the state
  197.      machine.  This will be based on the service model description of in
  198.      the protocol specification.
  199.  
  200.  
  201. In addition to simplification and consolidation of existing state
  202. machines, as well as inclusion of the state machines described above for
  203. Data Forwarding, Failure Detection, and APIs, there were two outstanding
  204. issues that must be resolved in the next draft with respect to the
  205. router state machines:
  206.  
  207.  
  208.   1. The handling of JOIN/JOIN REFUSE and upstream-oriented messages
  209.      must be revisited.
  210.  
  211.   2. The interfaces between origin and target sides of the router state
  212.      machines must be specified in more detail.
  213.  
  214.  
  215. Action Items
  216.  
  217. The next draft of State Machines is targeted for mid-May.  Tim O'Malley
  218. and Steve Jackowski agreed to assist Murali with the preparation of new
  219. state machines for the next draft.  Eric Crawley and Lou Berger will
  220. provide input and review these updates.
  221.  
  222. The decision to meet in Stockholm will be based on the status of the
  223. State Machine draft at that point.
  224.  
  225.