Editor's note: These minutes have not been edited. San Jose2 IETF Proceedings Transport Service Area RSVP Working Group Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) Reported by: Bob Braden/USC ISI Monday December 9, 1930-2200 A. Document Status The Montreal document agreed to submit the Version 1 RSVP protocol specification (level 13), MD5 Integrity check, and RSVP/IPSEC documents together to the IESG for Proposed Standard status. Accordingly, they were submitted to the Transport Area Director on September 3, 1996. She subsequently asked for some changes to the RSVP protocol spec, which were made and released. One change was to make the Message Processing Rules a separate document, intended to be Informational at present. Although some members felt that there would be benefits in retaining the integrity of the original spec, the working group decided to accept this division. Therefore, the requested Last Call now applies to the four Internet Drafts: Version 1 RSVP Specification: draft-ietf-rsvp-spec-14.txt Message Processing Rules: draft-ietf-rsvp-procrules-00.txt RSVP Cryptographic Authentication: draft-ietf-rsvp-md5-02.txt RSVP Extensions for IPSEC: draft-berger-rsvp-ext-04.txt B. Transition to rsvp-use-01 The data formats for Integrated Services objects have changed in the latest RSVP-usage specification. It was agreed that all vendors with RSVP implementations must have implemented the new spec before the end of January 1997. C. RSVP MIB Fred Baker introduced the latest versions of the RSVP MIB and two Integrated Service MIBs (see slides). The Sender Session Table (which records received Path messages) and the Reservation Requests Table (which records received Resv messages) may be writable. Here "writable" implies that SNMP can insert a shadow Path or Resv message into RSVP, as if the message had been received from another node. The semantics are that the message has an infinite refresh time and therefore any state that it creates locally does not time out. The Reservations Requested table, which records Resv messages sent upstream, is optional; implementations that do not otherwise save this information do not have to implement this table. The working group agreed that these specification should be submitted for Proposed Standard, after changes agreed upon at this meeting are incorporated. D. RSVP Diagnostic Message Lixia Zhang reported on progress in Diagnostic message implementation. A prototype implementation has been completed jointly by UCLA and ISI. The Diagnostic Message specification has been slightly revised according to this implementation experience (and it was submitted as a new I-D before San Jose IETF). The implementation will be made available after running more tests with more complex network topologies. UCLA will also work on adding a GUI interface to RSVP diagnosis to display the results. One main issue identified from the implementation effort is that RSVP routers that have not implemented the diagnostic extension do not know how to forward diagnostic messages. Therefore, the Diagnostic message extension can become fully useful only when it is universally implemented by all RSVP-capable nodes. Fortunately, several router vendors promised to add the Diagnostic message to their implementations as soon as the prototype implementation becomes stable. The working group agreed on the objective of sending the Diagnostic message to Last Call after the next IETF meeting. E. New RSVP Spec Issues Bob Braden summarized some small issues that have arisen in the Version 1 RSVP spec. 1. Remove the requirement that SCOPE list be sorted? Agreed. 2. Add broadcast-media-specific optimizations to protocol? Agreed not. 3. WF reservations policed even when there is no merging? Not settled. 4. UDP encapsulation use well-known multicast group for multicast path messages? Not settled. 5. Default value for blockade multiplier Kb? Not settled. F. Policy Shai Herzog briefly summarized the Policy BOF that he ran earlier. Discussion with the RSVP Working Group led to a consensus: we should prototype the policy facility and try a range of policies before it is standardized. A strategy was developed to allow prototyping within an environment of production RSVP-capable routers: policy processing and the policy database will be off-loaded from routers into distinct policy server hosts. This will allow rapid prototyping on the servers without further modifications to the router software. Herzog will refine the Policy Data object spec and processing rules, to facilitate this off-loading. For the present, we will use proprietary router/Policy server interface definitions. Herzog then explained his suggested approach to fragmentation of policy data objects. G. RSVP API Definition Don Hoffman reported that a group of vendors has been working on a standard prototype RSVP API specification. This definition will be more detailed than the generic API in the RSVP protocol spec; in particular, it will include the data structures to be passed in calls. It is generally modeled on the specific API distributed with the ISI RSVP implementation, but with Unix-isms removed. The API definition is expected to provide a format for Integrated Service data structures that is less complex than the format used on the wire, more like the "extended legacy" format of the ISI code. It is currently undecided whether or not to support transparently passing Integrated Service structures as well. Hoffman will shortly publish a draft of the API definition Draft. H. Interoperability Testing Several of the vendors indicated interest in a new round of interoperability testing, soon after the specification is finally stable. It was suggested that this be organized on the rsvp-test@isi.edu mailing list. I. Future Work Bob Braden briefly went through the current open tasks for the Working Group. 1. Writing an Applicability Document The most important is to write an Applicability document; the Area Director indicated that this was a requirement for the RSVP spec to actually reach Last Call. 2. Designing Routing support for Reservations This topic may pass to a QOSR working group. 3. Designing Policy extensions 4. Completing specification on using RSVP across tunnels Lixia Zhang promised to help resolve all the remaining issues concern RSVP tunnels. 5. Incorporating Link Layer interface issues These are mostly being handled in the ISSLL working group, but there may be some feedback into the RSVP spec itself. 6. Developing aggregation models and mechanisms 7. Gathering information on specific RSVP implementations