CURRENT_MEETING_REPORT_ Reported by Robet Braden/Information Sciences Institute Minutes of the Resource Reservation Setup Protocol BOF (RSVP) This BOF introduced a new protocol, RSVP, designed for setting up resource reservations in the Internet. It is a necessary component of a proposed extension of the Internet architecture to support integrated service, i.e., to support delay-sensitive applications. Dave Clark introduced the speakers, noting that Bob Braden and Deborah Estrin had returned to LA to deal with the risk of fire to their homes. The talk that Braden was going to give was instead given by John Wroclawski, Scott Shenker and Lixia Zhang. John gave the introduction, Scott discussed the RSVP model, and Lixia Zhang discussed the RSVP protocol itself. John returned to discuss the future direction of the working group. There were questions confirming the basic paradigm that RSVP lives on top of multicast routing, and that the PATH message serves the purpose of assuring that RSVP can know the reverse path of the multicast route. Merging, a complex topic, received some clarifying discussion. Noel Chiappa proposed that a flow identifier would be a better means of classifying packets. There was considerable discussion concerning flow IDs. It was proposed that while a flow ID is a dandy optimization, it was a mistake to make it a requirement. It was noted that security may hide some of the fields in the packet that might be used for packet classifying, but there must be some field in the packet used to select the proper decryption key, which would equally serve to classify a packet. It was noted that on a fragmented packet, some of the fields may be missing on all but the first fragments. Currently, MTU discovery is being used to avoid this problem. This is consistent with the current trend in the Internet away from fragmentation. There was discussion of the design decision within RSVP that the receiver rather than the sender should make the reservation. Some situations were proposed in which the sender might be in a better position than the receiver to make the reservation. The distinction was made that while in some cases it may be more direct for the sender to make the actual request, even in those cases it was the receiver that starts the process, and that understands what the request should be. There was a discussion of ``route pinning,'' which describes the objective of fixing the paths alone which resource reservations have been made, in order to assure that the reservation remains in place. Some members of the audience had concluded that RSVP did not intend to achieve this sort of functionality, which led to the conclusion that the ``quality'' of the assurance that RSVP would achieve would be less than 1 that of a protocol such as ST-II. Lixia clarified this point, stating that it was the intention of the RSVP designers that the assurance quality of an RSVP guarantee be very robust. However, they were of the opinion that RSVP should not contain mechanism to prevent ``route flapping,'' but that this ought to be a service of the routing protocol. More discussion followed, and this topic was noted for further discussion. It was stressed from the floor that RSVP must architect its behavior on route loss. The final discussion topic concerned whether RSVP could rapidly respond to network events, since it used timers to preserve its state. The presenters clarified this point, stressing that while RSVP used timers and refresh messages to maintain state, this did not preclude the use of event-driven messages to trigger recovery to such things as lost links. It is in fact the intention of RSVP to use event-driven messages for this purpose. A proposed working group agenda was presented, and there was general acceptance of forming a working group along those lines. Attendees Andy Adams ala@merit.edu Steve Alexander stevea@lachman.com Anthony Alles aalles@cisco.com Randall Atkinson atkinson@itd.nrl.navy.mil William Barns barns@gateway.mitre.org Tom Benkart teb@acc.com Lou Berger lberger@bbn.com Luc Boulianne lucb@cs.mcgill.ca Robert Braden braden@isi.edu Monroe Bridges monroe@cup.hp.com David Bridgham dab@epilogue.com Al Broscius broscius@bellcore.com Steve Buchko stevebu@newbridge.com Stephen Casner casner@isi.edu Isidro Castineyra isidro@bbn.com John Chang jrc@uswest.com Ping Chen ping@ping2.aux.apple.com J. Noel Chiappa jnc@lcs.mit.edu David Clark ddc@lcs.mit.edu James Davin davin@thumper.bellcore.com Steve DeJarnett steve@ibmpa.awdpa.ibm.com Luca Delgrossi luca@ibmpa.awdpa.ibm.com Taso Devetzis devetzis@bellcore.com Ed Ellesson ellesson@vnet.ibm.com Dino Farinacci dino@cisco.com Stefan Fassbender stf@easi.net William Fenner fenner@cmf.nrl.navy.mil James Forster forster@cisco.com Paul Francis Francis@thumper.bellcore.com Ron Frederick frederick@parc.xerox.com 2 Dan Frommer dan@isv.dec.com Mark Garrett mwg@faline.bellcore.com Fengmin Gong gong@concert.net Ramesh Govindan rxg@thumper.bellcore.com Joel Gyllenskog jgyllens@hpdmd48.boi.hp.com John Hanratty jhanratty@agile.com Dimitry Haskin dhaskin@wellfleet.com Ken Hayward Ken.Hayward@bnr.ca Juha Heinanen juha.heinanen@datanet.tele.fi Shai Herzog herzog@catarina.usc.edu Russ Hobby rdhobby@ucdavis.edu Van Jacobson van@ee.lbl.gov Ronald Jacoby rj@sgi.com Matthew Jonson jonson@ddn.af.mil Frank Kastenholz kasten@ftp.com Yasuhiro Katsube katsube@mail.bellcore.com David Kaufman dek@magna.telco.com Lee Kilpatrick leekil@bbn.com David Kristol dmk@allegra.att.com Ted Kuo tik@vnet.ibm.com Jim Martin jim@noc.rutgers.edu Thomas Maslen maslen@eng.sun.com Donald Merritt don@arl.army.mil Karen O'Donoghue kodonog@relay.nswc.navy.mil Vijayaragavan Pandian vjp@proteon.com Craig Partridge craig@bbn.com Laura Pate pate@gateway.mitre.org Maryann Perez perez@cmf.nrl.navy.mil Drew Perkins ddp@fore.com J. Mark Pullen mpullen@cs.gmu.edu Bala Rajagopalan braja@qsun.att.com Doris Roland droland@ghost.darpa.mil Allyn Romanow allyn.romanow@eng.sun.com Shawn Routhier sar@epilogue.com Allan Rubens acr@merit.edu Hal Sandick sandick@vnet.ibm.com Eve Schooler schooler@isi.edu Henning Schulzrinne hgs@research.att.com Isil Sebuktekin isil@nevin.bellcore.com Michael See mikesee@vnet.ibm.com Kanan Shah kshah@cmf.nrl.navy.mil Scott Shenker shenker@parc.xerox.com Ming Sheu msheu@vnet.ibm.com W. David Sincoskie sincos@bellcore.com Karen Sollins sollins@lcs.mit.edu Michael Speer michael.speer@sun.com Louis Steinberg louiss@vnet.ibm.com John Stewart jstewart@cnri.reston.va.us Matsuaki Terada tera@sdl.hitachi.co.jp Claudio Topolcic topolcic@cnri.reston.va.us Jerry Toporek jt@mentat.com Dono van-Mierop dono_van_mierop@3mail.3com.com Abel Weinrib abel@bellcore.com Taehwan Weon weon@cosmos.kaist.ac.kr 3 Richard Woundy rwoundy@vnet.ibm.com John Wroclawski jtw@lcs.mit.edu Jean Yao yao@cup.hp.com Shinichi Yoshida yoshida@sumitomo.com Jessica Yu jyy@merit.edu Lixia Zhang lixia@parc.xerox.com 4