home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 93nov / rsvp-minutes-93nov.txt < prev    next >
Text File  |  1994-02-23  |  8KB  |  170 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Robet Braden/Information Sciences Institute
  6.  
  7. Minutes of the Resource Reservation Setup Protocol BOF (RSVP)
  8.  
  9. This BOF introduced a new protocol, RSVP, designed for setting up
  10. resource reservations in the Internet.  It is a necessary component of a
  11. proposed extension of the Internet architecture to support integrated
  12. service, i.e., to support delay-sensitive applications.
  13.  
  14. Dave Clark introduced the speakers, noting that Bob Braden and Deborah
  15. Estrin had returned to LA to deal with the risk of fire to their homes.
  16. The talk that Braden was going to give was instead given by John
  17. Wroclawski, Scott Shenker and Lixia Zhang.  John gave the introduction,
  18. Scott discussed the RSVP model, and Lixia Zhang discussed the RSVP
  19. protocol itself.  John returned to discuss the future direction of the
  20. working group.
  21.  
  22. There were questions confirming the basic paradigm that RSVP lives on
  23. top of multicast routing, and that the PATH message serves the purpose
  24. of assuring that RSVP can know the reverse path of the multicast route.
  25.  
  26. Merging, a complex topic, received some clarifying discussion.
  27.  
  28. Noel Chiappa proposed that a flow identifier would be a better means of
  29. classifying packets.  There was considerable discussion concerning flow
  30. IDs.  It was proposed that while a flow ID is a dandy optimization, it
  31. was a mistake to make it a requirement.
  32.  
  33. It was noted that security may hide some of the fields in the packet
  34. that might be used for packet classifying, but there must be some field
  35. in the packet used to select the proper decryption key, which would
  36. equally serve to classify a packet.  It was noted that on a fragmented
  37. packet, some of the fields may be missing on all but the first
  38. fragments.  Currently, MTU discovery is being used to avoid this
  39. problem.  This is consistent with the current trend in the Internet away
  40. from fragmentation.
  41.  
  42. There was discussion of the design decision within RSVP that the
  43. receiver rather than the sender should make the reservation.  Some
  44. situations were proposed in which the sender might be in a better
  45. position than the receiver to make the reservation.  The distinction was
  46. made that while in some cases it may be more direct for the sender to
  47. make the actual request, even in those cases it was the receiver that
  48. starts the process, and that understands what the request should be.
  49.  
  50. There was a discussion of ``route pinning,'' which describes the
  51. objective of fixing the paths alone which resource reservations have
  52. been made, in order to assure that the reservation remains in place.
  53. Some members of the audience had concluded that RSVP did not intend to
  54. achieve this sort of functionality, which led to the conclusion that the
  55. ``quality'' of the assurance that RSVP would achieve would be less than
  56. that of a protocol such as ST-II. Lixia clarified this point, stating
  57. that it was the intention of the RSVP designers that the assurance
  58. quality of an RSVP guarantee be very robust.  However, they were of the
  59. opinion that RSVP should not contain mechanism to prevent ``route
  60. flapping,'' but that this ought to be a service of the routing protocol.
  61. More discussion followed, and this topic was noted for further
  62. discussion.  It was stressed from the floor that RSVP must architect its
  63. behavior on route loss.
  64.  
  65. The final discussion topic concerned whether RSVP could rapidly respond
  66. to network events, since it used timers to preserve its state.  The
  67. presenters clarified this point, stressing that while RSVP used timers
  68. and refresh messages to maintain state, this did not preclude the use of
  69. event-driven messages to trigger recovery to such things as lost links.
  70. It is in fact the intention of RSVP to use event-driven messages for
  71. this purpose.
  72.  
  73. A proposed working group agenda was presented, and there was general
  74. acceptance of forming a working group along those lines.
  75.  
  76.  
  77. Attendees
  78.  
  79. Andy Adams               ala@merit.edu
  80. Steve Alexander          stevea@lachman.com
  81. Anthony Alles            aalles@cisco.com
  82. Randall Atkinson         atkinson@itd.nrl.navy.mil
  83. William Barns            barns@gateway.mitre.org
  84. Tom Benkart              teb@acc.com
  85. Lou Berger               lberger@bbn.com
  86. Luc Boulianne            lucb@cs.mcgill.ca
  87. Robert Braden            braden@isi.edu
  88. Monroe Bridges           monroe@cup.hp.com
  89. David Bridgham           dab@epilogue.com
  90. Al Broscius              broscius@bellcore.com
  91. Steve Buchko             stevebu@newbridge.com
  92. Stephen Casner           casner@isi.edu
  93. Isidro Castineyra        isidro@bbn.com
  94. John Chang               jrc@uswest.com
  95. Ping Chen                ping@ping2.aux.apple.com
  96. J. Noel Chiappa          jnc@lcs.mit.edu
  97. David Clark              ddc@lcs.mit.edu
  98. James Davin              davin@thumper.bellcore.com
  99. Steve DeJarnett          steve@ibmpa.awdpa.ibm.com
  100. Luca Delgrossi           luca@ibmpa.awdpa.ibm.com
  101. Taso Devetzis            devetzis@bellcore.com
  102. Ed Ellesson              ellesson@vnet.ibm.com
  103. Dino Farinacci           dino@cisco.com
  104. Stefan Fassbender        stf@easi.net
  105. William Fenner           fenner@cmf.nrl.navy.mil
  106. James Forster            forster@cisco.com
  107. Paul Francis             Francis@thumper.bellcore.com
  108. Ron Frederick            frederick@parc.xerox.com
  109. Dan Frommer              dan@isv.dec.com
  110. Mark Garrett             mwg@faline.bellcore.com
  111. Fengmin Gong             gong@concert.net
  112. Ramesh Govindan          rxg@thumper.bellcore.com
  113. Joel Gyllenskog          jgyllens@hpdmd48.boi.hp.com
  114. John Hanratty            jhanratty@agile.com
  115. Dimitry Haskin           dhaskin@wellfleet.com
  116. Ken Hayward              Ken.Hayward@bnr.ca
  117. Juha Heinanen            juha.heinanen@datanet.tele.fi
  118. Shai Herzog              herzog@catarina.usc.edu
  119. Russ Hobby               rdhobby@ucdavis.edu
  120. Van Jacobson             van@ee.lbl.gov
  121. Ronald Jacoby            rj@sgi.com
  122. Matthew Jonson           jonson@ddn.af.mil
  123. Frank Kastenholz         kasten@ftp.com
  124. Yasuhiro Katsube         katsube@mail.bellcore.com
  125. David Kaufman            dek@magna.telco.com
  126. Lee Kilpatrick           leekil@bbn.com
  127. David Kristol            dmk@allegra.att.com
  128. Ted Kuo                  tik@vnet.ibm.com
  129. Jim Martin               jim@noc.rutgers.edu
  130. Thomas Maslen            maslen@eng.sun.com
  131. Donald Merritt           don@arl.army.mil
  132. Karen O'Donoghue         kodonog@relay.nswc.navy.mil
  133. Vijayaragavan Pandian    vjp@proteon.com
  134. Craig Partridge          craig@bbn.com
  135. Laura Pate               pate@gateway.mitre.org
  136. Maryann Perez            perez@cmf.nrl.navy.mil
  137. Drew Perkins             ddp@fore.com
  138. J. Mark Pullen           mpullen@cs.gmu.edu
  139. Bala Rajagopalan         braja@qsun.att.com
  140. Doris Roland             droland@ghost.darpa.mil
  141. Allyn Romanow            allyn.romanow@eng.sun.com
  142. Shawn Routhier           sar@epilogue.com
  143. Allan Rubens             acr@merit.edu
  144. Hal Sandick              sandick@vnet.ibm.com
  145. Eve Schooler             schooler@isi.edu
  146. Henning Schulzrinne      hgs@research.att.com
  147. Isil Sebuktekin          isil@nevin.bellcore.com
  148. Michael See              mikesee@vnet.ibm.com
  149. Kanan Shah               kshah@cmf.nrl.navy.mil
  150. Scott Shenker            shenker@parc.xerox.com
  151. Ming Sheu                msheu@vnet.ibm.com
  152. W. David Sincoskie       sincos@bellcore.com
  153. Karen Sollins            sollins@lcs.mit.edu
  154. Michael Speer            michael.speer@sun.com
  155. Louis Steinberg          louiss@vnet.ibm.com
  156. John Stewart             jstewart@cnri.reston.va.us
  157. Matsuaki Terada          tera@sdl.hitachi.co.jp
  158. Claudio Topolcic         topolcic@cnri.reston.va.us
  159. Jerry Toporek            jt@mentat.com
  160. Dono van-Mierop          dono_van_mierop@3mail.3com.com
  161. Abel Weinrib             abel@bellcore.com
  162. Taehwan Weon             weon@cosmos.kaist.ac.kr
  163. Richard Woundy           rwoundy@vnet.ibm.com
  164. John Wroclawski          jtw@lcs.mit.edu
  165. Jean Yao                 yao@cup.hp.com
  166. Shinichi Yoshida         yoshida@sumitomo.com
  167. Jessica Yu               jyy@merit.edu
  168. Lixia Zhang              lixia@parc.xerox.com
  169.  
  170.