home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / 94MAR / TRANSPRT < prev    next >
Encoding:
Text File  |  1994-06-07  |  7.8 KB  |  180 lines

  1.  
  2. Transport Area
  3.  
  4. Director:
  5.  
  6.  
  7.    o Allison Mankin:  mankin@cmf.nrl.navy.mil
  8.  
  9.  
  10. Area Summary Reported by Allison Mankin/NRL
  11.  
  12. The Transport Area Directorate is comprised of the following members:
  13. Dave Borman, Sally Floyd, Jim Hughes, Matt Mathis, Greg Minshall, Eve
  14. Schooler, and John Wroclawski.
  15.  
  16. The Transport Services Area deals with protocols and algorithms that
  17. provide end-to-end transmission services in the Internet.  We maintain
  18. the notion of transport services, not just transport protocols, because
  19. of the increasing variety of end-to-end requirements that the Internet
  20. is meeting, or will be expected to meet, in the near future.
  21.  
  22. In the month after the Seattle IETF, two working groups were added to
  23. Transport Services because of the closing down of the Service
  24. Applications Area:  ONCRPC and THINOSI. They are covered in the SAP
  25. report for Seattle, but they fit well into the Transport Area Director
  26. and Directorate's sense of the scope of the Transport Services Area.
  27.  
  28. Since the last report, we have increased the directorate, reflecting
  29. both the increase in the number of our active working groups and the
  30. area director's temporary assignment to co-direct the IP: Next
  31. Generation Area (with Scott Bradner).  The directorate is primarily
  32. responsible for quality review of the working groups.  They also
  33. contribute to our planning with their diverse and far-sighted
  34. perspectives on the Internet.
  35.  
  36. Among the future issues for TSV that we are thinking on are:  improving
  37. distributed file systems, fully documenting as standards TCP's adaptive
  38. algorithms (for the moment, Sally Floyd reports that the account in
  39. Richard Steven's TCP/IP Illustrated 2nd Edition will be correct and
  40. complete), completing selective acknowledgment in TCPLW, and developing
  41. an informational activity on the integrated layer processing technique,
  42. which is strongly related to transport services implementation issues.
  43.  
  44. The Transport Services Area working groups that met in Seattle offer
  45. their brief summaries below.  INT-SERV met as a BOF in Seattle, but it
  46. has since become a working group.  ONCRPC is included in the SAP report
  47. for Seattle.
  48.  
  49.  
  50. Audio/Video Transport Working Group (AVT)
  51.  
  52. The meeting began with a brief report on the status of the Real-time
  53. Transport Protocol (RTP). The draft RTP specification was submitted with
  54. a request for Last Call just before the previous IETF meeting in
  55. November.  The review by the Transport Area Directorate called for
  56. several changes so that RTP would more closely follow the principles of
  57. application level framing.  In two discussions between Steve Casner, Ron
  58. Frederick and Van Jacobson in which the vat and nv programs were taken
  59. as design examples, the following list of proposed changes was
  60. constructed:
  61.  
  62.  
  63.    o Carry the control and data traffic on separate ports
  64.  
  65.    o Move the application-level multiplexing of the channel ID to an
  66.      encapsulation, for the cases where it is needed
  67.  
  68.    o Minimize the use of options
  69.  
  70.    o Make the definition of some fields application-specific (in
  71.      particular, the timestamp clock rate and sync marker)
  72.  
  73.    o Use global rather than local IDs, to be able to detect loops
  74.  
  75.    o Specify more precisely how reception reports should be provided
  76.  
  77.  
  78. The first 90 minutes of the first session, and the beginning of the
  79. second session were occupied by a presentation of these changes.  The
  80. attendees generally agreed with the changes, and in particular agreed
  81. that the global identifiers would always be 32-bit random numbers rather
  82. than allowing the IPv4 address to be used as an identifier; as a
  83. consequence, the identifier of the synchronization source will always be
  84. included in a new field added to the fixed RTP header.  There are
  85. several details remaining to be defined, in particular the mechanisms
  86. for padding the message to a multiple of the encryption block size, and
  87. for carrying the authentication information, and the exact structure of
  88. the control packet.
  89.  
  90. Our task now is to complete the design to address these details, update
  91. the specification and get consensus from the working group via e-mail.
  92. Steve Casner will take responsibility for sending out a more complete
  93. draft of the proposed changes to start the discussion.  The goal is to
  94. submit the draft for Last Call after review at the July IETF meeting in
  95. Toronto.
  96.  
  97.  
  98. Integrated Services Working Group (INTSERV)
  99.  
  100. The first meeting was an organizational meeting, describing the
  101. motivations for the group, its organization, and timeline.  The goal of
  102. INTSERV is to make the Internet friendly to real-time applications
  103. (e.g., multimedia conferencing) by enhancing the Internet architecture
  104. to support integrated services.
  105.  
  106. The proposed working group organization calls for Craig Partridge to be
  107. the working group chair, and John Wroclawski, Scott Shenker and Dave
  108. Clark to be co-chairs.  It was explained that the large management team
  109. is intended to ensure that the necessary outreach to various affected
  110. communities is made.
  111.  
  112. The working group timeline calls for delivery of several RFCs over the
  113. next two years.
  114.  
  115. The second session was devoted to trying to investigate what
  116. requirements integrated services might place upon IPng.  Craig explained
  117. that this was definitely putting the cart before the horse, given that
  118. the group had barely had a chance to talk about proposed integrated
  119. services architectures, but at the request of the IPng Directorate, a
  120. discussion was held.
  121.  
  122. At the end of the meeting, the proto-working group concluded that there
  123. were two requirements it would like to place on IPng:
  124.  
  125.  
  126.    o That an IPng have some mechanism to locate per-datagram
  127.      classification information (e.g., flow state) and that the
  128.      mechanism should be consistent with forwarding at the media speeds
  129.      expected in the future.
  130.  
  131.    o That an IPng should have mechanisms to hinder Bob from using or
  132.      disrupting resources that Alice has been granted and is using.
  133.  
  134.  
  135. Craig Partridge was tasked to write up these points and circulate a
  136. draft to the working group, for consideration as submission as a white
  137. paper to the IPng directorate.
  138.  
  139.  
  140.  
  141. Multiparty Multimedia Session Control Working Group (MMUSIC)
  142.  
  143.  
  144. During the Seattle meetings of the MMUSIC Working Group, there appeared
  145. to be a convergence of ideas about the general framework and protocols
  146. required for session control in the Internet, and a readiness to take
  147. steps toward interoperability of existing applications.  The group
  148. identified at least two services that system builders might need and
  149. use; CCCP, a bus-based protocol that could provide an API-level
  150. messaging abstraction, and the agreement algorithm on which a session
  151. service could be built.  In addition, there was interest in trying to
  152. understand, in the present context of the Internet/MBone/WWW, what
  153. constitutes a session and what are the functions that can be performed
  154. on sessions once they exist.  Thus, a variety of session rendez-vous
  155. mechanisms were described.  A final discussion focused on the relevance
  156. of reliable multicast to a membership management protocol.  From formal
  157. and informal conversations with working group participants, it was clear
  158. that these ideas are ready to be codified and written down.
  159.  
  160.  
  161.  
  162. Resource Reservation Setup Protocol Working Group (RSVP)
  163.  
  164. The RSVP Working Group met twice during the Seattle IETF. The first
  165. session was devoted to an overview of the protocol and a report on the
  166. status of an initial implementation.  Several issues were raised and
  167. discussed.  The second session was largely devoted to further discussion
  168. of a number of basic issues.
  169.  
  170. The working group plans to hold an MBone conference before the next IETF
  171. meeting (the MBone meeting has been scheduled for 23 June), and to
  172. conduct further discussion by e-mail.  There were several action items
  173. to prepare position papers on particular issues.  The draft
  174. specification will be updated with some additions suggested at the
  175. meeting.
  176.  
  177. Many of the hard issues under discussion concerned functional
  178. modularity, especially between resource reservation and routing.
  179.  
  180.