Munich IETF Proceedings Transport Area RSVP Working Grouip Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) Reported by: Bob Braden/USC-ISI Tuesday August 12, 1997 I. Status Report: Bob Braden, Scott Bradner The Transport Area director Scott Bradner briefly presented the current status of the RSVP Internet Drafts. Contrary to previous report, the IESG approval of these documents as Proposed Standards had been held up by a few minor issues. The only issue still open at the time of the meeting concerned the IPSEC Extension document: the IESG requested a more explicit statement of how the VDstPort field should be assigned. The proposed fix was to include an "IANA Considerations" section, specifying a division of the field values into fixed and dynamically assigned ranges, with directions to the IANA on how to assign values from the fixed range. There being no objection from the document authors or from the Working Group, this proposal was adopted. As a result, the RSVP documents should all advance into the standards track. The RAPI application interface, defined in the ISI interface, has been submitted to XOPEN for possible standardization by that body. This was initiated and is being pursued by Don Hoffman of Sun. An XOPEN draft has been produced and is awaiting editing. A first stage of a survey of current and planned implementations of RSVP and integrated services has been completed. This initial effort was substantial, and has more than 20 entries. We are grateful to Gene Gaines and Luca Salgarelli for the work they have put into this. The draft has been distributed on the rsvp-test mailing list, and it is planned to be available on a Web page. II. Status of Tunneling and Diagnosis Drafts: Lixia Zhang The diagnostic message specification has gone through another cycle of cleanup and has two new object types added: - In response to comments received from Menphis meeting, a new SELECT object is defined to allow a diagnostic requester to specify the types of RSVP objects to be collected in the diagnostic reply. This new SELECT object consists of a list of [C-Class, C-type] pairs. - In order to be able to perform diagnosis recursively over an RSVP tunnel, a new TUNNEL object is defined that consists of two session objects. This object is used when the path of an RSVP session contains one or more IP-in-IP tunnels and both ends of a tunnel support RSVP tunneling. The first session object specifies the end-to-end RSVP session S1, and the second one specifies the RSVP session over the tunnel S2 that S1 maps to (that is, over the tunnel S1's flow is supported by S2's reservation). When an RSVP diagnostic request is received by an Rexit router, Rexit attaches to the DREQ a TUNNEL object. Thus the diagnostic client can easily identify the existence of RSVP tunneling, and invoke RSVP diagnosis over the RSVP tunnel session whenever needed. Lixia Zhang also reported the status of specification and implementation of RSVP over IP-in-IP tunnels. We are finishing a new version of the specification taking into account the input from Memphis IETF, in particular some valuable comments from Tim O'Malley. UCLA is finishing the first prototype implementation that runs on freeBSD 2.2.2, with IP- in-IP tunnel code from University of Portland, and using CBQ for packet scheduling. Our implementation supports both automatic RSVP tunnel session setup by end-to-end RSVP sessions and configured RSVP sessions over the tunnel for aggregate traffic flow. We plan to release the code before December IETF. We also learned recently that KDD R & D Lab in Japan has carried out a second, independent implementation for RSVP over IP tunnels. The implementation runs on freeBSD 2.2.1, using a simplified version of WFQ for packet scheduling. III. Future of RSVP Working Group: Discussion As co-chair, Bob Braden reviewed the history, goals, and accomplishments of the RSVP working group. In summary, the goals of the working group have basically been met, and most of the protocol documents under development will soon be Proposed Standards. The Working Group then agreed to go dormant, until the time comes to consider the documents for Draft Standard. The rsvp and rsvp-test mailing lists will remain in place for discussion of the protocols and implementations. IV. Routing and Reservations: Roch Guerin Roch Guerin summarized the Internet Draft: "Extended RSVP-routing Interface" (draft-guerin-ext-rsvp-routing-intf-00.txt). He suggested that RSVP should support service differentiation by path, i.e., the path should be determined in part by the service requested. For this purpose, he suggested that the RSVP/routing interface be broadened, so that (1) RSVP will pass *all* information that might possibly be relevant to QoS routing, including the IP and transport headers, T_specs, and Adspecs, and (2) there will be a more general event notification mecahnism between RSVP and routing. Guerin also discussed the draft "Setting up Reservations on Explicit Paths Using RSVP (draft-guerin-expl-path-rsvp-00.txt). RSVP can be extended to support explicit routing of data, by carrying opaque routing objects. Brief audience discussion pointed out that RSVP may not always be in use when service differentiation by path is required. It was also suggeted that higher-level architectural issues should be considered before detailed RSVP-specific features are defined. V. RSVP Experience in Commercial Internet Trials: Mark Baugher Mark Baugher gave a very interesting report on a joint effort by cisco, Intel, and MCI to evaluate commercial feasibility of Internet multimedia services. These tests were conducted over the MCI SMDS service and over the internal Intel ATM testbed. During these trials, RSVP was successfully tested on the MCI SMDS testbed. A total of 6 application tools from 3 vendors/sources were converted to use RSVP. They found that about one person-month was typically required to design,implement, and test RSVP support in an application. He noted that application developers often implemented the wrong data rate for their applications, so that some mechanism for rate adjustment is necessary. Among his conclusions were: (1) better workload generators and tools are needed for testing end-to-end delay; and (2) multicasting through firewalls in a major problem.