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