CURRENT_MEETING_REPORT_
Reported by Bob Braden/ISI and Lixia Zhang/Xerox PARC
Minutes of the Resource Reservation Setup Protocol Working Group (RSVP)
Agenda - Tuesday Session
o Organization of Working Group
o Introduction to RSVP
o Implementation Status
This was the first meeting of the RSVP Working Group, whose objective is
to standardize the specification of the Resource Reservation Setup
Protocol (RSVP). RSVP will operate within the framework of the
integrated services architecture that is under development by the
INTSERV Working Group. Therefore, some protocol/implementation details
will have to be developed in parallel or jointly between the two working
groups (in particular, the FlowSpec and the interface to admission
control). However, the urgency of deploying real time service in
support of multimedia across the Internet forces this course of action.
The planned approach is to do phased development of RSVP specifications
through successive versions as the integrated service requirements
develop.
Bob Braden presented an introduction to the current draft RSVP design.
(See overheads following these minutes.) This presentation covered the
assumptions and fundamental ideas behind RSVP, its service model, and
its protocol mechanisms. Steve Berson then gave a short presentation on
a prototype implementation of the current RSVP specification, which is
being tested and developed in DARTnet.
Issues Raised
A number of important questions were raised by the attendees.
1. Reservation Model
RSVP uses a `one pass' reservation model, which is intrinsically
unable to perform fine grain `delay budget' allocation across the
routers in the path, as does by Berkeley Tenet group proposal. The
question that was raised was whether this is adequate. One
response is that such fine grain delay allocation is not especially
useful in general, and the issue was tabled for further discussion
at the second session.
2. Recovery from Reservation Failure
RSVP is currently designed to be as nearly as possible decoupled
from routing, to achieve the advantages of modularity. This means
that RSVP tries to establish a new reservation using a (primary)
route given by the routing protocol at the request time. The
question is then: what happens if there is not enough capacity to
satisfy the request along the primary route, but an alternative
route does have the capacity; how can the secondary route be used?
Braden suggested that this situation requires some
source-controlled routing mechanism to find and install secondary
routes, and that such source-demand routing protocols are being
developed (e.g., IDRP, SDRP) and will be used by RSVP when they
become available. However, the general area of the interface
between RSVP and routing does need to be considered and architected
in this working group.
3. Mobility, Route Flapping, and Load-Dependent Routing
A concern was expressed that RSVP would be unable to handle
mobility. However, it appears that mobile hosts are only a special
case of the general problem of changing routes. This is an
important issue, and this working group must convince itself that
RSVP will work satisfactorily in the presence of mobility.
We may categorize route changes into three types: absolute (where
the old route is unusable), permissive (where the current path is
not broken, but a ``better'' path is now available), and ``route
flapping'' (routes constantly switching between alternate paths).
Permissive route changes are stable (i.e., the route changed for a
reason and will not go back to the previous one spontaneously),
while route flapping is unstable. RSVP currently adapts to route
changes by reserving resources on a new route after it is
established. This may create a brief gap in the reservation
protection for a flow's data. These gaps may be unavoidable for
absolute route changes, but they are undesirable for permissive
route changes and will almost certainly be a problem in the case of
route flapping.
It was also suggested that the routing used by RSVP should be
constantly adjusted according to the available capacity. Those who
were aware of early ARPANET experience with load-dependent routing
were less than enthusiastic about this approach, which could easily
cause routing instability.
4. Path Messages
It was asked how we can be sure that path messages follow the same
path through the multicast trees as the corresponding data. Braden
noted that whatever information in a packet may be used to
determine the multicast routing of the data packets (e.g., QOS
bits) must also be contained in path messages, which must follow
the same routes.
The question was raised of whether or not path messages are needed
at all. This is a complex issue that was tabled.
Agenda - Thursday Session
o Packet classifier: theory and measurements
o Open technical issues
o Specification document
o Implementation and testing strategies
Classifier
John Wroclawski described the function of packet classification and
presented experimental results on a Patricia tree-based classifier. The
most significant result was that Patricia tree classification requires a
roughly constant CPU time as a function of the number of classes is
roughly constant (i.e., the logarithmic term has a very small
multiplier). The time per packet (in usec) was measured to be:
Hit Rate DEC 3000/600 Sun SPARCstation 1+
100% 10 usec/pkt 47 usec/pkt
50% 11 usec/pkt 62 usec/pkt
Technical Issues
In response to issues (2) and (3) raised at the first session, Deborah
Estrin made a brief presentation of proposed routing protocol
enhancements to aid RSVP. These include:
o Reverse Path Routing - a future routing protocol will be able to
give a receiver the ``shortest path from'' the sender.
o Route Pinning - stable routes over the lifetime of flows.
o Alternate path routing if setup attempt fails.
o Route selection based on configured capabilities (e.g., IDRP QOS
routing).
o Route selection based on estimate of resource availability (e.g.,
SDRP path explorer and reject information used). (Admission
control gives information to routing protocol.)
She concluded with the remark that people working in the routing area
are well aware of the requirements to better support applications and
protocols such as RSVP, and progress is underway.
With respect to the one pass reservation model used by RSVP (issue 1 at
the first session), Bob Braden and Scott Shenker took an action item to
prepare a short summary of the tradeoffs that this implies.
Lixia Zhang then made a presentation on two open design issues in RSVP:
route pinning and the tradeoff between using multiple multicast
addresses vs. filters to select subflows. (The presentation slides
follow these minutes.)
o Route Pinning
During the RSVP BOF held at the last IETF (Houston), a concern
voiced by several people was the impact of route flapping on RSVP
reservations. Because RSVP reservations are made along the routes
given by routing protocols, constant route flapping between
alternate paths would lead to unstable service. Although we firmly
believe that route (in)stability is a routing protocol problem and
should be solved there, nevertheless a ``route pinning'' scheme was
proposed and presented for the working group's evaluation (see
Lixia Zhang's presentation slides for details).
No detailed comments about the scheme were received during the
discussion. John Wroclawski raised the related issue of permissive
route changes: should RSVP should ensure a graceful transition
from an old route to a new one when the route has permanently
changed (e.g., by pinning the data flow on the old route until a
reservation has been made along the new route)? This would address
the ``mobile host and route transition'' concern raised at the
first meeting. John noted that addressing this issue may take care
of route flapping as a side effect. This issue deserves further
discussion by the working group.
Considering the issue of route flapping, Curtis Villamizar argued
that, based on his observation from NSF backbone routing table,
route flapping is not a serious threat in today's networks.
Moreover, Van Jacobson argued strongly that we must take a firm
stance in favor of fixing routing problems in the routing
protocols, rather than by adding complexity to RSVP.
The consensus taken from the working group is to not include the
route pinning in the current RSVP specification or implementation,
though we may table it as an appendix item.
o Multiple Multicast Groups vs. Filters
RSVP separates reservations from usage by a packet filter scheme.
The filter associated with each reservation determines which
packets can use the reserved resources. Two different functions of
the packet filter can be identified: distinguishing packets from
different sources, and distinguishing packets from different
substreams from the same source to meet heterogeneous receiver
requests.
Recently, Deering, Estrin, and others have suggested a modification
to RSVP filter usage. Their proposal would use separate multicast
groups, instead of filters, to distinguish substreams within a
single session. Although the filter function would still be needed
to distinguish different senders (for dynamic filter style
reservations), the proposal would simplify the FilterSpec, because
it would only need to distinguish data sources. However, this
proposal has a drawback: if sources use different encoding
schemes, and if a receiver wants to receive different numbers of
substreams from different sources (this can happen even with
homogeneous encoding), then this request cannot be met using
separate multicast groups for different substreams (but without
distinction of sources). It also requires that the different
multicast addresses belonging to different substreams of the same
session must be ``bundled'' in routing so that they will be
guaranteed to have the same multicast trees.
During the discussion, Van Jacobson commented that if multicast
routing implemented per-source pruning (as well as reverse path
routing), then the filter scheme could be completely eliminated
from RSVP. Because RSVP reservations ride ``on top'' of the routing
protocol, under Van's scheme, multicast route pruning would also
prune any temporarily unused reservation that a DF reservation
wished to keep. Van later suggested a solution to this problem:
use a separate multicast group address for DF reservation messages,
separate from the multicast group used for data delivery. Then the
routing protocol could prune specific sources that no one was
currently listening to, without pruning DF reservations. This
approach would also require bundling of multicast routes, to ensure
that both groups (the one used by reservations and the one used to
forward data) have the same multicast trees.
There was a short discussion of the current RSVP functional
specification document, and an outline of the changes that have been
incorporated recently or will be incorporated soon.
The group agreed to hold an MBone conference before the next IETF
meeting (Toronto). The date will be determined on the mailing list.
Attendees
Brian Adamson adamson@itd.nrl.navy.mil
Edward Allen eallen@wellfleet.com
Anthony Alles aalles@cisco.com
Richard Bantel rb@mtsol.att.com
William Barns barns@gateway.mitre.org
Stephen Batsell batsell@itd.nrl.navy.mil
Lou Berger lberger@bbn.com
Steven Berson berson@isi.edu
Tony Bogovic tjb@bellcore.com
David Borman dab@cray.com
Carsten Bormann cabo@informatik.uni-bremen.de
Ute Bormann ute@informatik.uni-bremen.de
Robert Braden braden@isi.edu
Michael Bradley bradley@mdd.comm.mot.com
David Bridgham dab@epilogue.com
Scott Brim swb1@cornell.edu
Theodore Brunner ted.brunner@tek.com
Steve Buchko stevebu@newbridge.com
Jerry Burchfield burchfiel@bbn.com
Joesph Burrescia burrescia@es.net
John Burruss jburruss@wellfleet.com
Stephen Casner casner@isi.edu
Isidro Castineyra isidro@bbn.com
Paul Chang pchangmac@asante.com
Luo-Jen Chiang ljc@lsnhbu1.lincroftnj.ncr.com
J. Noel Chiappa jnc@lcs.mit.edu
Eric Chin-Li-Sun ericc@tera.com
David Clark ddc@lcs.mit.edu
Wayne Clark wclark@cisco.com
Richard Cogger R.Cogger@cornell.edu
Eric Crawley kaufman@scrc.symbolics.com
Jon Crowcroft jon@cs.ucl.ac.uk
David Crowe crowed@osshe.edu
Sandip Dasgupta sandip@cup.hp.com
Farokh Deboo fjd@synoptics.com
Luca Delgrossi luca@ibmpa.awdpa.ibm.com
Chuck deSostoa chuckd@cup.hp.com
Donald Eastlake dee@lkg.dec.com
Julio Escobar jescobar@bbn.com
Deborah Estrin estrin@usc.edu
Dino Farinacci dino@cisco.com
William Fink bill@wizard.gsfc.nasa.gov
Sally Floyd floyd@ee.lbl.gov
Mark Garrett mwg@faline.bellcore.com
Eugene Geer ewg@cc.bellcore.com
Mark Handley mhandley@cs.ucl.ac.uk
Ken Hayward Ken.Hayward@bnr.ca
Greg Hill ghill@atmsys.com
Don Hoffman hoffman@eng.sun.com
Eric Hoffman hoffman@cmf.nrl.navy.mil
Kathy Huber khuber@wellfleet.com
Christian Huitema Christian.Huitema@sophia.inria.fr
Phil Irey pirey@relay.nswc.navy.mil
Steven Jackowski stevej@syzygycomm.com
David Jacobson dnjake@vnet.ibm.com
Ronald Jacoby rj@sgi.com
Merike Kaeo mkaeo@cisco.com
Kyungran Kang krkang@cosmos.kaist.ac.kr
Frank Kastenholz kasten@ftp.com
Yasuhiro Katsube katsube@mail.bellcore.com
Percy Khabardar percyk@cisco.com
John Krawczyk jkrawczy@wellfleet.com
Padma Krishnaswamy kri@cc.bellcore.com
Robert Kummerfeld bob@cs.su.oz.au
Paul Leach paulle@microsoft.com
John Leong john.leong@andrew.cmu.edu
Fong-Ching Liaw fong@eng.sun.com
Arthur Lin yalin@srv.pacbell.com
Charles Lynn clynn@bbn.com
Chris Maeda cmaeda@cs.washington.edu
Andrew Malis malis@maelstrom.timeplex.com
Allison Mankin mankin@cmf.nrl.navy.mil
Ken Masica masic@es.net
Yosi Mass yosi@ubique.co.il
Matt Mathis mathis@psc.edu
Jun Matsukata jm@eng.isas.ac.jp
Keith McCloghrie kzm@cisco.com
Daniel McDonald danmcd@itd.nrl.navy.mil
Donald Merritt don@arl.army.mil
David Meyer meyer@ns.uoregon.edu
Greg Minshall minshall@wc.novell.com
Steve Minzer minzer@bellcore.com
Dennis Morris morrisd@cc.ims.disa.mil
Osamu Nakamura osamu@wide.ad.jp
William Nowicki nowicki@sgi.com
Joseph Pang pang@bodega.stanford.edu
John Penners jpenners@advtech.uswest.com
Drew Perkins ddp@fore.com
Rex Pugh pugh@hprnd.rose.hp.com
J. Mark Pullen mpullen@cs.gmu.edu
Thomas Pusateri pusateri@cs.duke.edu
Murali Rajagopal murali@mitre.org
K. K. Ramakrishnan rama@erlang.enet.dec.com
Ram Ramanathan ramanath@bbn.com
Robert Roden roden@roden.enet.dec.com
Allyn Romanow allyn@eng.sun.com
Hal Sandick sandick@vnet.ibm.com
Sibylle Schaller schaller@ibmpa.awdpa.ibm.com
Eve Schooler schooler@isi.edu
Dallas Scott scott@fluky.mitre.org
Katsuhiro Sebayashi sebayasi@tnlab.ntt.jp
Isil Sebuktekin isil@nevin.bellcore.com
Joshua Seeger jseeger@bbn.com
Paul Serice serice@cos.com
Scott Shenker shenker@parc.xerox.com
Ming-Jye Sheu msheu@vnet.ibm.com
Chi Shue chi@casc.com
Michael Speer michael.speer@sun.com
John Stewart jstewart@cnri.reston.va.us
Sally Tarquinio sallyt@gateway.mitre.org
Kevin Thompson kev@gateway.mitre.org
Susan Thomson set@bellcore.com
Claudio Topolcic topolcic@bbn.com
Robert Ullmann rullmann@crd.lotus.com
Dono van Mierop Dono_van_Mierop@3Mail.3Com.com
Gary Veum veum@boa.gsfc.nasa.gov
Curtis Villamizar curtis@ans.net
Jost Weinmiller jost@prz.tu-berlin.de
Abel Weinrib abel@bellcore.com
Linda Winkler lwinkler@anl.gov
Dan Wood dwood@bbn.com
John Wroclawski jtw@lcs.mit.edu
Suguru Yamaguchi yamaguti@wide.ad.jp
Shinichi Yoshida yoshida@sumitomo.com
Jessica Yu jyy@merit.edu
Lixia Zhang lixia@parc.xerox.com