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 >
Wrap
Text File
|
1994-02-01
|
8KB
|
194 lines
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