CURRENT_MEETING_REPORT_ Reported by Craig Partridge/BBN Minutes of the Integrated Services Working Group (INTSERV) This group met as a BOF in Seattle. First Meeting The first meeting was an organizational meeting, describing the motivations for the group, its organization, and timeline. The goal of the working group (which is still awaiting approval) is to make the Internet friendly to real-time applications (e.g., multimedia conferencing) by enhancing the Internet architecture to support integrated services. The proposed working group organization calls for Craig Partridge to be the working group chair, and John Wroclawski, Scott Shenker and Dave Clark to be vice-chairs. It was explained that the large management team is intended to ensure that the necessary outreach to various affected communities is made. The working group timeline calls for delivery of several RFCs over the next two years. The question was raised about whether anything with delivery two years into the future was ``research'' and thus not within IETF scope. The consensus answer seemed to be yes, it sometimes takes that long, and that this agenda was appropriately conservative (i.e., we might finish faster) rather than wildly optimistic. Second Meeting This meeting was devoted to trying to investigate what requirements integrated services might place upon IPng. Partridge explained that this was definitely putting the cart before the horse, given that the group had barely even had a chance to talk about proposed integrated services architectures, but at the request of the IPng Directorate, it was agreed to hold a discussion. To launch discussion, two working group co-chairs gave talks. John Wroclawski gave a talk about flow IDs. One of John's key points was that there is a range of tradeoffs involved in how to identify a flow. The problem is locating some state in a router that tells you what special handling a particular packet requires. (A series of packets which receives special treatment is what constitutes a flow.) John also pointed out that we already do this state lookup or classification today -- when we look up a route. What is making the future different is that we will want to do several classifications on a single packet (finding state based on issues such as security, accounting, flow control, and destination), and that while there are logically several lookups being done here into multiple databases, for efficient forwarding, in practice all these virtual lookups need to be reduced to one actual lookup. At one extreme one can locate the state by looking at enough fields in a packet header (e.g., IP source, destination, protocol ID, protocol ports, TOS field, etc.). to uniquely identify a particular flow of packets. This may well be what we do for IPv4, since it lacks any specific flow IDs. At the other extremely, there is a flow ID in each packet which points to some state. Another issue is what to do if, after you look up the flow ID, you find you do not have state. If one examines the header, one might be able to figure out what state should be given to the packet. If one uses flow IDs, the flow ID can either be a hint (if missing, you can probably puzzle out from the headers what to do with the packet), or as Noel Chiappa suggested, it can be a ``key'' which if missing means a router should discard the packet because it will probably do the ``wrong thing'' (e.g., route to the wrong place). John's conclusions were: o It is highly desirable for IPng to support a mechanism for fast multi-axis classification of all packets. This requirement is general, not just required for integrated services. o The mechanism chosen for the IPng protocol should not assume any particular definition of flow or choice of classification criteria. John's talk engendered a long discussion, with various people debating which type of flow ID semantics were really desired, whether multiple applications' traffic should be combined into one flow, or if a single application's traffic might be split into multiple flows and even if flows were needed. (For an example of multiple applications in one flow, consider several video channels aggregated together, perhaps to yield a flow with less variable bandwidth demands. For an example of multiple flows for one application, consider multi-layer encoded video, where different receivers may only want certain layers, and thus different layers are sent as different flows.) Dave Clark then gave a talk based on part of the IAB retreat report that discussed authentication issues for IPng and flows in particular. It is clearly undesirable for an entity ``Bob'' to be able to access the resources reserved for a flow that has been established for ``Alice,'' provided Alice is actually using the resources. (If Alice is not using them, we would presumably like to see the resources available to others, as needed.) Dave talked about a number of ways that one could try to inexpensively authenticate packets as belonging to a particular flow. Dave pointed out that, unlike the needs in some security contexts, the authentication mechanisms do not have to be perfect, they simply need to keep unauthorized access to a manageable level. (For details of the various proposed mechanisms, see the IAB retreat report, available as an Internet-Draft.) After Dave's talk, there was some discussion of how to relate authentication needs to the flow ID issues raised by John's talk. At the end of the meeting, the proto-working group concluded that there were two requirements it would like to place on IPng: 1. That an IPng have some mechanism to locate per-datagram classification information (e.g., flow state) and that the mechanism should be consistent with forwarding at the media speeds expected in the future. 2. That an IPng should have mechanisms to hinder Bob from using or disrupting resources that Alice has been granted and is using. Craig Partridge was tasked to write up these points and circulate a draft to the working group, for consideration as submission as a white paper to the IPng Directorate. Attendees Brian Adamson adamson@itd.nrl.navy.mil Kevin Altis altis@ibeam.intel.com Randall Atkinson atkinson@itd.nrl.navy.mil Richard Bantel rb@mtsol.att.com William Barns barns@gateway.mitre.org Stephen Batsell batsell@itd.nrl.navy.mil Steven Berson berson@isi.edu Richard Binder rbinder@cnri.reston.va.us David Borman dab@cray.com 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 John Burruss jburruss@wellfleet.com Ken Carlberg Carlberg@tieo.saic.com John Carlson johnc@cac.washington.edu Greg Celmainis gregc@newbridge.com Wun Chao wun@doelztc.timeplex.com Ping Chen ping@apple.com Luo-Jen Chiang ljc@lsnhbu1.lincroftnj.ncr.com Eric Chin-Li-Sun ericc@tera.com Chris Chiotasso chris@lightstream.com Richard Cogger R.Cogger@cornell.edu Richard Cornetti cornetti@wg.com Jon Crowcroft jon@cs.ucl.ac.uk David Crowe crowed@osshe.edu Sandip Dasgupta sandip@cup.hp.com Bruce Davie bsd@bellcore.com Farokh Deboo fjd@synoptics.com Stephen Deering deering@parc.xerox.com Chuck deSostoa chuckd@cup.hp.com Bruce Dugan bld@nwet.net Julio Escobar jescobar@bbn.com Roger Fajman raf@cu.nih.gov Robert Fink rlfink@lbl.gov William Fink bill@wizard.gsfc.nasa.gov Sally Floyd floyd@ee.lbl.gov Paul Francis francis@cactus.slab.ntt.jp Mark Garrett mwg@faline.bellcore.com Shawn Gillam shawn@timonware.com Ramesh Govindan rxg@thumper.bellcore.com William Haggerty haggerty@ctron.com Mark Handley mhandley@cs.ucl.ac.uk Dimitry Haskin dhaskin@wellfleet.com Marco Hernandez marco@cren.net Greg Hill ghill@atmsys.com Don Hoffman hoffman@eng.sun.com Kathy Huber khuber@wellfleet.com Jim Hughes hughes@network.com Phil Irey pirey@relay.nswc.navy.mil Kimio Ishii ishii@sfc.wide.ad.jp Ronald Jacoby rj@sgi.com Kyungran Kang krkang@cosmos.kaist.ac.kr Frank Kastenholz kasten@ftp.com David Katinsky dmk@pilot.njin.net John Krawczyk jkrawczy@wellfleet.com Padma Krishnaswamy kri@cc.bellcore.com Mark Laubach laubach@hpl.hp.com Fong-Ching Liaw fong@eng.sun.com Arthur Lin yalin@srv.pacbell.com Paul Lu lu@pmel.noaa.gov Charles Lynn clynn@bbn.com Andrew Malis malis@maelstrom.timeplex.com Tracy Mallory tracym@3com.com Allison Mankin mankin@cmf.nrl.navy.mil Matt Mathis mathis@psc.edu Keith McCloghrie kzm@cisco.com David Meyer meyer@ns.uoregon.edu Greg Minshall minshall@wc.novell.com Steve Minzer minzer@bellcore.com Erik Nordmark nordmark@eng.sun.com Joseph Pang pang@bodega.stanford.edu Craig Partridge craig@bbn.com Amy Pearl amy.pearl@eng.sun.com John Penners jpenners@advtech.uswest.com Drew Perkins ddp@fore.com K. K. Ramakrishnan rama@erlang.enet.dec.com Ram Ramanathan ramanath@bbn.com Robert Reschly reschly@brl.mil Allyn Romanow allyn@eng.sun.com Hal Sandick sandick@vnet.ibm.com Dallas Scott scott@fluky.mitre.org Joshua Seeger jseeger@bbn.com Scott Shenker shenker@parc.xerox.com Ming-Jye Sheu msheu@vnet.ibm.com William Simpson bsimpson@morningstar.com Henry Sinnreich hsinnreich@mcimail.com Jim Solomon solomon@comm.mot.com Michael Speer michael.speer@sun.com Martha Steenstrup msteenst@bbn.com John Stewart jstewart@cnri.reston.va.us Dan Tappan tappan@lightstream.com Fumio Teraoka tera@csl.sony.co.jp Susan Thomson set@bellcore.com Claudio Topolcic topolcic@bbn.com Aleks Totic atotic@ncsa.uiuc.edu Curtis Villamizar curtis@ans.net Abel Weinrib abel@bellcore.com Rick Wilder wilder@mcimail.com Linda Winkler lwinkler@anl.gov John Wroclawski jtw@lcs.mit.edu Lixia Zhang lixia@parc.xerox.com