home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rsvp / rsvp-minutes-95dec.txt < prev    next >
Encoding:
Text File  |  1996-06-03  |  6.3 KB  |  161 lines
  1. CURRENT MEETING REPORT
  2.  
  3. Reported by Bob Braden, Information Sciences Institute and Lixia 
  4. Zhang, Xerox Palo Alto Research Center
  5.  
  6. Minutes of the Resource Reservation Setup Protocol Working Group 
  7. (RSVP)
  8.  
  9.  
  10. Summary
  11.  
  12. The first session was devoted to reports and discussion.  During the 
  13. second session resolution was reached on the open issues, and the 
  14. working group agreed that the Version 1 RSVP protocol specification, 
  15. after final revisions, should be undergo working-group-last-call, 
  16. followed by submission to the IESG.
  17.  
  18.  
  19. Agenda for the Monday, December 4 Session:
  20.  
  21. o  Report on Interop demo of RSVP/intserv: Mark Baugher, Intel
  22. o  Report on interim RSVP WG Meeting -- Bob Braden, ISI
  23. o  Diagnostic message: Lixia Zhang, PARC
  24. o  Discussion of open issues
  25.  
  26. Report on Interop demo of RSVP/intserv: Mark Baugher
  27.  
  28. Mark Baugher reported on the successful multi-vendor interoperability 
  29. demo of RSVP implementations at the Atlanta Interop in September.  
  30. The vendors involved were Bay Networks, cisco, SGI, Sun, Intel, and 
  31. Starlight.
  32.  
  33. The applications included ShowMe-TV (Sun), nv (SGI), Startworks, 
  34. Eviewer, and HQV/NFS.  The realtime support was a single level 
  35. controlled-load service.  The host vendors used RSVP implementations 
  36. ported from the ISI prototype RSVP daemon rsvpd.  A carefully defined 
  37. subset of the protocol was used, including WF and FF styles, but 
  38. excluding SE style, the SCOPE object (the demo topology had no loops), 
  39. advertising, dynamic flowspec adjustment, and security.
  40.  
  41. Baugher played a short video tape made during the demo, showing 
  42. convincingly the beneficial effect of a reservation on audio and video 
  43. streams.  More trial and demo's are planned early next year.
  44.  
  45.  
  46. Agenda -- Wednesday 6 December Session:
  47.  
  48. o  Resolution of open issues
  49. o  Last-Call action
  50. o  RSVP Authentication: Fred Baker, Cisco
  51. o  Accounting and access control: Shai Herzog, ISI
  52. o  Future Working Group priorities
  53.  
  54.  
  55. Resolution of open issues
  56.  
  57. The Working Group agreed on resolutions for the outstanding issues, in 
  58. order to complete action on the Version 1 protocol spec and submit it to 
  59. the IESG.
  60.  
  61. o  Diagnostic message
  62.  
  63. Agreed to publish RSVP diagnostic message specification 
  64. separately.
  65.  
  66. o  Soft ACKs
  67.  
  68. Agreed to accept the CONFIRM mechanism as defined in the current 
  69. spec.
  70.  
  71. o  Error Actions
  72.  
  73. Following the Monday session, the trio of Lee Breslau, Bruce Davie, 
  74. and Shai Herzog outlined a proposed solution to the denial-of-
  75. service problem posed in the first session by Fred Baker.  This was 
  76. the result of many hours of work on their part.
  77.  
  78. Lixia Zhang presented a slide outlining a much simplified version of 
  79. the above, which solves the Baker problem but does not support 
  80. persistent reservation request forwarding.  A concensus of the 
  81. Working Group accepted Lixia's mechanism in preference to that 
  82. developed by Breslau, Davie, and Herzog.
  83.  
  84. John Wroclawski then observed that there are multiple classes of 
  85. error conditions, and that an application may wish to have its 
  86. request forwarded for some error classes and receive an error message 
  87. for other classes.  He proposed to use an "error-vector" to let users 
  88. choose, for each of the failure classes, between sending an error and 
  89. forwarding a failed request.  The error-vectors of all merged requests 
  90. would be ANDed together to produce the merged error-vector (that 
  91. is, the merged request will stop and trigger an error message if any of 
  92. the users requested so).  The Working Group accepted Wroclawski's 
  93. proposal.
  94.  
  95.  
  96. o  Tunnels
  97.  
  98. John Wroclawski suggested that (1) the recursive application of 
  99. RSVP is the right solution to this problem, and (2) this can, and 
  100. should, be documented separately from the RSVP spec itself.  The 
  101. demuxing field was not discussed further.  It was agreed to postpone 
  102. further discussion of these issues.
  103.  
  104.  
  105. Last Call Action
  106.  
  107. The Working Group reached a consensus to proceed with the version 1 
  108. protocol spec with the agreed revisions.  Following the update there 
  109. will be a working-group last-call sometime in early January.  After 
  110. working group consensus is reached, we will forward the RSVP spec to 
  111. IESG for consideration to move to Proposed Standard.
  112.  
  113.  
  114. RSVP Authentication: Fred Baker, Cisco
  115.  
  116. Fred Baker reported briefly that RFC1826 appears to provide the same 
  117. security functionality as the Keyed MD5 INTEGRITY mechanism that 
  118. he had proposed in his draft -rsvp-md5-01.txt.  He agreed to 
  119. investigate this further; it implies that the INTEGRITY object is 
  120. unneeded and should be dropped.
  121.  
  122.  
  123. Accounting and access control: Shai Herzog, ISI
  124.  
  125. Shai Herzog made a presentation on how accounting and access control 
  126. can be added to RSVP.  In his model, some routers are "policy 
  127. gateways" that verify and rewrite credentials based upon bilateral 
  128. agreements between neighbors, and do not rely on any global 
  129. information or agreements.  He proposes to add a Local Policy Module 
  130. (LPM) that interacts with RSVP and with traffic control, and he 
  131. presented generic interfaces between RSVP and the LPM.  Herzog also 
  132. proposed a new type of RSVP message, named Reservation Report.  The 
  133. report can include a simple ack or a more sophisticated policy based 
  134. feedback (like the cost of a reservation).  Report messages flows from 
  135. the source host downstream to receivers, forwarded hop-by-hop only 
  136. along those reserved branches where receivers have requested a report 
  137. (by setting a Report-request bit in their reservation requests).
  138.  
  139. The working group voted to make the accounting interface a high 
  140. priority action item.  Herzog Shai will prepare an internet-draft 
  141. proposal and a document suggesting the modification to the RSVP spec 
  142. for supporting the LPM architecture.
  143.  
  144. Future Working Group Activities
  145.  
  146. There was a very brief discussion of priorities for future Working Group 
  147. activities.  The highest priority was given to accounting models and 
  148. standards.  Second priority was split among diagnostic and management 
  149. capabilities--the MIB and the diagnostic message--and support for 
  150. active-QoS link layers.  With respect to the last, it was announced that 
  151. there will be a joint meeting of the RSVP, Int-Serv, and IP-ATM 
  152. Working Groups at the next IETF meeting.
  153.  
  154. Other future Working Group activities should include: (1) protocol 
  155. extensions e.g., new styles, multi-session reservations, CIDR-
  156. knowledgable filtering, and traffic splitting; (2) tunnels; (3) security; 
  157. and (4) more advanced treatment of error conditions.
  158.  
  159.  
  160.  
  161.