CURRENT_MEETING_REPORT_ Reported by Bob Braden/USC ISI and Lixia Zhang/Xerox PARC Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) Agenda - Wednesday Session o Implementation reports - RSVP daemon, API: Steve Berson and Don Hoffman - CSZ kernels for SunOS 4.x and PC, packet classifier: John Wroclawski/MIT - LBL/UCL/Sun CBQ kernel: Don Hoffman/Sun - UCL packet classifier: Ian Wakeman/UCL - sd/tcl invoking RSVP: John Wroclawski o Interaction between routing and RSVP - Long-term architecture: Deborah Estrin/ISI - Short-term approach: Lixia Zhang/Xerox PARC Implementation Reports Steve Berson and Don Hoffman described work on an RSVP daemon, which is running in both the SunOS 4.x and Solaris operating systems. This daemon implements all the major features of the current RSVP protocol specification. Two more significant changes are in the works. o RSVP hooks are being added (at PARC) to the new pruning version of mrouted. This will allow the RSVP daemon to directly query mrouted for multicast routes. It is expected to appear in a multicast release later this summer. o The current protocol specification contains a simplified generic API, and Don Hoffman has implemented a corresponding UNIX library call interface. Does the kernel have to be changed to use RSVP? Hosts only need to add multicast routing to their kernels; routers must change anyway to add packet scheduling. Is there any access control on reservations? RSVP includes a user identification/authorization field for this purpose, but its contents and meaning are not yet specified. Some feel that access control is useless without full encryption-based authentication, but others believe that even a simple ad hoc mechanism (e.g., manually configured access lists) can be very useful for administrative control in the short term. The chair invited someone interested in the administrative model for access control to work on the problem. John Wroclawski described a packet scheduling kernel he has been developing at MIT, based on the CSZ (Clark/Shenker/Zhang) approach. He can make it available for a PC/BSD and/or a DARTnet SunOS 4.1 platform; he asked the meeting which is more useful to release. Hoffman has interfaced RSVP to a Solaris kernel containing the CBQ packet scheduler that was originally developed by Van Jacobson and Sally Floyd and repackaged as a streams module at UCL. RSVP provides dynamic setup of CBQ classes. Ian Wakeman described a new packet classifier he is developing at UCL. Finally, Wroclawski explained how MIT has added RSVP calls to sd, vat, and nv. Interaction Between Routing and RSVP Deborah Estrin presented a discussion of the long-term architectural issues in the interaction between routing and reservation setup (see slides). There are compelling reasons to keep routing protocols distinct from the reservation setup protocol; however, they must interact. The routing protocol is used to distribute reservation requests along the appropriate path, while the reservation protocol may need to give feedback to influence the routing decision. The general approach that Estrin described is as follows. RSVP obtains a (``default'') route and tries to set up a reservation along it; if that fails, RSVP asks for an alternate route and tries it, repeating this if necessary. In asking for a route, RSVP may ask for a route that satisfies some very rough QoS criteria (e.g., ``low delay''); these criteria define the QoR (``Quality of Route''). RSVP sets up the desired specific QoS (e.g., a specific numeric delay bound) along the route(s) provided to it. Estrin pointed out an ugly problem due to heterogeneity of requests: a larger reservation trying to graft onto an existing distribution tree may force rerouting of existing upstream reservations. There was an extensive discussion from the floor. There was some distaste expressed about alternate routing; however, it was pointed out that we do not yet know how important alternate routing will be, although we need to understand its cost and mechanisms, should it be necessary. One suggestion was that a QoS used by an application should choose from a small set of specific values, and that the routing protocols can then compute routes to provide exactly the desired QoS. This approach would essentially remove the distinction between QoR and QoS; if acceptable, it would greatly simplify the interaction between routing and RSVP. There was considerable debate on whether this approach is sufficiently general; it appears that QoR cannot completely assume the role of QoS, implying that the present complication is necessary. Lixia Zhang then presented a proposal for how the working group should proceed with the routing/RSVP interaction in the short term (This talk was actually deferred to the beginning of the Thursday session). She made the following proposals for the short term: o Orientation of routes: RSVP will work with existing routing protocols that provide only forward routes (handled by path messages). o Quality of routes: Route selection by QoR will not be possible. o Stability of reservation: Defer the design of ``route pinning,'' or ``smooth transition,'' which would keep reservations stable when routes change. As a result, there may be gaps in QoS when routes change. o Reservation repair: RSVP provides periodic refresh messages to trigger repair after a route fails. Defer the design of local repair mechanisms. There appeared to be general acceptance of this proposal. Agenda - Thursday Session o Reservation model: Scott Shenker/PARC o Open issue in RSVP protocol: Lixia Zhang/PARC o Release plans o Future meetings Reservation Model Scott Shenker presented a talk on the reservation model, part two of the talk he delivered in the Integrated Services Working Group (INTSERV). He explained the mechanism to implement his proposed ``one-pass with advertising'' (OPWA) reservation model. In this model, information is gathered hop-by-hop along the path(s) from sender(s) to receiver, and delivered to the receiver application as an ``advertisement.'' This information tells the receiver application the end-to-end delay bounds that will result from each possible hop/hop reservation request. Implementation of the OPWA model requires little additional machinery in RSVP. Path messages would carry the ``advertising'' information forward to the receivers. There was a lively discussion of this proposal. Issues included the necessity for end-to-end guarantees, how to make it more efficient (e.g., advertizing on demand), the importance of end-to-end delay knowledge for an application, the difficulty of transparent rerouting using OPWA and the use of worst-case versus current values for the bounds. Open Issues Lixia Zhang discussed the major open issues in RSVP. Following her presentation, individual working group members volunteered to track each of the items and report at the next meeting. The list is: o Negotiation model: Scott Shenker o Interface with routing: Deborah Estrin, ``X'' from the Nimrod group (``X'' to be designated by Noel Chiappa) o Access control: ``Y'' (``Y'' to be designated by Dave Clark) o Filter specification representation: John Wroclawski, Bob Braden o ``Killer reservations'': Steve Berson o Firewall architecture: Don Hoffman o Multicast groups versus RSVP filters: Lixia Zhang, Deborah Estrin, Noel Chiappa Release Plans Braden presented the plans for releasing initial versions of resource reservation code. This will include RSVP, two different packet scheduling kernels, and modified vat, nv, and sd tools to invoke RSVP. He asked for a few sites to volunteer to test the first release, which is projected for later in August. It was pointed out that testing over the MBone would be useful. Braden agreed to discuss this with Deering. Future Meetings The group agreed to hold an interim teleconference on Thursday 27 October. Steve Casner noted that we hope to be able to demonstrate RSVP during the Multimedia '94 conference, 19-20 October in San Francisco.