CURRENT MEETING REPORT Reported by Bob Braden, Information Sciences Institute and Lixia Zhang, Xerox Palo Alto Research Center Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) Summary The first session was devoted to reports and discussion. During the second session resolution was reached on the open issues, and the working group agreed that the Version 1 RSVP protocol specification, after final revisions, should be undergo working-group-last-call, followed by submission to the IESG. Agenda for the Monday, December 4 Session: o Report on Interop demo of RSVP/intserv: Mark Baugher, Intel o Report on interim RSVP WG Meeting -- Bob Braden, ISI o Diagnostic message: Lixia Zhang, PARC o Discussion of open issues Report on Interop demo of RSVP/intserv: Mark Baugher Mark Baugher reported on the successful multi-vendor interoperability demo of RSVP implementations at the Atlanta Interop in September. The vendors involved were Bay Networks, cisco, SGI, Sun, Intel, and Starlight. The applications included ShowMe-TV (Sun), nv (SGI), Startworks, Eviewer, and HQV/NFS. The realtime support was a single level controlled-load service. The host vendors used RSVP implementations ported from the ISI prototype RSVP daemon rsvpd. A carefully defined subset of the protocol was used, including WF and FF styles, but excluding SE style, the SCOPE object (the demo topology had no loops), advertising, dynamic flowspec adjustment, and security. Baugher played a short video tape made during the demo, showing convincingly the beneficial effect of a reservation on audio and video streams. More trial and demo's are planned early next year. Agenda -- Wednesday 6 December Session: o Resolution of open issues o Last-Call action o RSVP Authentication: Fred Baker, Cisco o Accounting and access control: Shai Herzog, ISI o Future Working Group priorities Resolution of open issues The Working Group agreed on resolutions for the outstanding issues, in order to complete action on the Version 1 protocol spec and submit it to the IESG. o Diagnostic message Agreed to publish RSVP diagnostic message specification separately. o Soft ACKs Agreed to accept the CONFIRM mechanism as defined in the current spec. o Error Actions Following the Monday session, the trio of Lee Breslau, Bruce Davie, and Shai Herzog outlined a proposed solution to the denial-of- service problem posed in the first session by Fred Baker. This was the result of many hours of work on their part. Lixia Zhang presented a slide outlining a much simplified version of the above, which solves the Baker problem but does not support persistent reservation request forwarding. A concensus of the Working Group accepted Lixia's mechanism in preference to that developed by Breslau, Davie, and Herzog. John Wroclawski then observed that there are multiple classes of error conditions, and that an application may wish to have its request forwarded for some error classes and receive an error message for other classes. He proposed to use an "error-vector" to let users choose, for each of the failure classes, between sending an error and forwarding a failed request. The error-vectors of all merged requests would be ANDed together to produce the merged error-vector (that is, the merged request will stop and trigger an error message if any of the users requested so). The Working Group accepted Wroclawski's proposal. o Tunnels John Wroclawski suggested that (1) the recursive application of RSVP is the right solution to this problem, and (2) this can, and should, be documented separately from the RSVP spec itself. The demuxing field was not discussed further. It was agreed to postpone further discussion of these issues. Last Call Action The Working Group reached a consensus to proceed with the version 1 protocol spec with the agreed revisions. Following the update there will be a working-group last-call sometime in early January. After working group consensus is reached, we will forward the RSVP spec to IESG for consideration to move to Proposed Standard. RSVP Authentication: Fred Baker, Cisco Fred Baker reported briefly that RFC1826 appears to provide the same security functionality as the Keyed MD5 INTEGRITY mechanism that he had proposed in his draft -rsvp-md5-01.txt. He agreed to investigate this further; it implies that the INTEGRITY object is unneeded and should be dropped. Accounting and access control: Shai Herzog, ISI Shai Herzog made a presentation on how accounting and access control can be added to RSVP. In his model, some routers are "policy gateways" that verify and rewrite credentials based upon bilateral agreements between neighbors, and do not rely on any global information or agreements. He proposes to add a Local Policy Module (LPM) that interacts with RSVP and with traffic control, and he presented generic interfaces between RSVP and the LPM. Herzog also proposed a new type of RSVP message, named Reservation Report. The report can include a simple ack or a more sophisticated policy based feedback (like the cost of a reservation). Report messages flows from the source host downstream to receivers, forwarded hop-by-hop only along those reserved branches where receivers have requested a report (by setting a Report-request bit in their reservation requests). The working group voted to make the accounting interface a high priority action item. Herzog Shai will prepare an internet-draft proposal and a document suggesting the modification to the RSVP spec for supporting the LPM architecture. Future Working Group Activities There was a very brief discussion of priorities for future Working Group activities. The highest priority was given to accounting models and standards. Second priority was split among diagnostic and management capabilities--the MIB and the diagnostic message--and support for active-QoS link layers. With respect to the last, it was announced that there will be a joint meeting of the RSVP, Int-Serv, and IP-ATM Working Groups at the next IETF meeting. Other future Working Group activities should include: (1) protocol extensions e.g., new styles, multi-session reservations, CIDR- knowledgable filtering, and traffic splitting; (2) tunnels; (3) security; and (4) more advanced treatment of error conditions.