home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rsvp / rsvp-minutes-93nov.txt < prev    next >
Text File  |  1994-02-01  |  8KB  |  194 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.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. that of a protocol such as ST-II. Lixia clarified this point, stating
  64. that it was the intention of the RSVP designers that the assurance
  65. quality of an RSVP guarantee be very robust.  However, they were of the
  66. opinion that RSVP should not contain mechanism to prevent ``route
  67. flapping,'' but that this ought to be a service of the routing protocol.
  68. More discussion followed, and this topic was noted for further
  69. discussion.  It was stressed from the floor that RSVP must architect its
  70. behavior on route loss.
  71.  
  72. The final discussion topic concerned whether RSVP could rapidly respond
  73. to network events, since it used timers to preserve its state.  The
  74. presenters clarified this point, stressing that while RSVP used timers
  75. and refresh messages to maintain state, this did not preclude the use of
  76. event-driven messages to trigger recovery to such things as lost links.
  77. It is in fact the intention of RSVP to use event-driven messages for
  78. this purpose.
  79.  
  80. A proposed working group agenda was presented, and there was general
  81. acceptance of forming a working group along those lines.
  82.  
  83.  
  84. Attendees
  85.  
  86. Andy Adams               ala@merit.edu
  87. Steve Alexander          stevea@lachman.com
  88. Anthony Alles            aalles@cisco.com
  89. Randall Atkinson         atkinson@itd.nrl.navy.mil
  90. William Barns            barns@gateway.mitre.org
  91. Tom Benkart              teb@acc.com
  92. Lou Berger               lberger@bbn.com
  93. Luc Boulianne            lucb@cs.mcgill.ca
  94. Robert Braden            braden@isi.edu
  95. Monroe Bridges           monroe@cup.hp.com
  96. David Bridgham           dab@epilogue.com
  97. Al Broscius              broscius@bellcore.com
  98. Steve Buchko             stevebu@newbridge.com
  99. Stephen Casner           casner@isi.edu
  100. Isidro Castineyra        isidro@bbn.com
  101. John Chang               jrc@uswest.com
  102. Ping Chen                ping@ping2.aux.apple.com
  103. J. Noel Chiappa          jnc@lcs.mit.edu
  104. David Clark              ddc@lcs.mit.edu
  105. James Davin              davin@thumper.bellcore.com
  106. Steve DeJarnett          steve@ibmpa.awdpa.ibm.com
  107. Luca Delgrossi           luca@ibmpa.awdpa.ibm.com
  108. Taso Devetzis            devetzis@bellcore.com
  109. Ed Ellesson              ellesson@vnet.ibm.com
  110. Dino Farinacci           dino@cisco.com
  111. Stefan Fassbender        stf@easi.net
  112. William Fenner           fenner@cmf.nrl.navy.mil
  113. James Forster            forster@cisco.com
  114. Paul Francis             Francis@thumper.bellcore.com
  115. Ron Frederick            frederick@parc.xerox.com
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123. Dan Frommer              dan@isv.dec.com
  124. Mark Garrett             mwg@faline.bellcore.com
  125. Fengmin Gong             gong@concert.net
  126. Ramesh Govindan          rxg@thumper.bellcore.com
  127. Joel Gyllenskog          jgyllens@hpdmd48.boi.hp.com
  128. John Hanratty            jhanratty@agile.com
  129. Dimitry Haskin           dhaskin@wellfleet.com
  130. Ken Hayward              Ken.Hayward@bnr.ca
  131. Juha Heinanen            juha.heinanen@datanet.tele.fi
  132. Shai Herzog              herzog@catarina.usc.edu
  133. Russ Hobby               rdhobby@ucdavis.edu
  134. Van Jacobson             van@ee.lbl.gov
  135. Ronald Jacoby            rj@sgi.com
  136. Matthew Jonson           jonson@ddn.af.mil
  137. Frank Kastenholz         kasten@ftp.com
  138. Yasuhiro Katsube         katsube@mail.bellcore.com
  139. David Kaufman            dek@magna.telco.com
  140. Lee Kilpatrick           leekil@bbn.com
  141. David Kristol            dmk@allegra.att.com
  142. Ted Kuo                  tik@vnet.ibm.com
  143. Jim Martin               jim@noc.rutgers.edu
  144. Thomas Maslen            maslen@eng.sun.com
  145. Donald Merritt           don@arl.army.mil
  146. Karen O'Donoghue         kodonog@relay.nswc.navy.mil
  147. Vijayaragavan Pandian    vjp@proteon.com
  148. Craig Partridge          craig@bbn.com
  149. Laura Pate               pate@gateway.mitre.org
  150. Maryann Perez            perez@cmf.nrl.navy.mil
  151. Drew Perkins             ddp@fore.com
  152. J. Mark Pullen           mpullen@cs.gmu.edu
  153. Bala Rajagopalan         braja@qsun.att.com
  154. Doris Roland             droland@ghost.darpa.mil
  155. Allyn Romanow            allyn.romanow@eng.sun.com
  156. Shawn Routhier           sar@epilogue.com
  157. Allan Rubens             acr@merit.edu
  158. Hal Sandick              sandick@vnet.ibm.com
  159. Eve Schooler             schooler@isi.edu
  160. Henning Schulzrinne      hgs@research.att.com
  161. Isil Sebuktekin          isil@nevin.bellcore.com
  162. Michael See              mikesee@vnet.ibm.com
  163. Kanan Shah               kshah@cmf.nrl.navy.mil
  164. Scott Shenker            shenker@parc.xerox.com
  165. Ming Sheu                msheu@vnet.ibm.com
  166. W. David Sincoskie       sincos@bellcore.com
  167. Karen Sollins            sollins@lcs.mit.edu
  168. Michael Speer            michael.speer@sun.com
  169. Louis Steinberg          louiss@vnet.ibm.com
  170. John Stewart             jstewart@cnri.reston.va.us
  171. Matsuaki Terada          tera@sdl.hitachi.co.jp
  172. Claudio Topolcic         topolcic@cnri.reston.va.us
  173. Jerry Toporek            jt@mentat.com
  174. Dono van-Mierop          dono_van_mierop@3mail.3com.com
  175. Abel Weinrib             abel@bellcore.com
  176. Taehwan Weon             weon@cosmos.kaist.ac.kr
  177.  
  178.                                    3
  179.  
  180.  
  181.  
  182.  
  183.  
  184. Richard Woundy           rwoundy@vnet.ibm.com
  185. John Wroclawski          jtw@lcs.mit.edu
  186. Jean Yao                 yao@cup.hp.com
  187. Shinichi Yoshida         yoshida@sumitomo.com
  188. Jessica Yu               jyy@merit.edu
  189. Lixia Zhang              lixia@parc.xerox.com
  190.  
  191.  
  192.  
  193.                                    4
  194.