Editor's note: These minutes have not been edited. Montreal IETF Proceedings Transport Service Area RSVP Working Group Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) Reported by: Steven Berson/USC ISI, Lixia Zhang/UCLA, and Bob Braden/USC ISI Monday June 24 RSVP Working Group Session A. LAST CALL STATUS -------------------- The first issue was the status of the "Last Call" for making RSVP a proposed standard. Bob Braden was advised by the Transport Area Director that RSVP needed support for security before going to proposed standard. As a result, the three documents: RSVP spec, MD5 Integrity Object spec, and RSVP IPsec (IP security) spec, will be submitted to the IESG as a package. Braden described the changes needed in the RSVP spec. (1) Several typos need fixing. (2) The statement in the spec that Policy Data objects (PDOs) are opaque to RSVP is wrong; PDOs may not be entirely opaque to RSVP. The solution is to remove the one sentence from the RSVP spec. (3) The spec references IPsec support for IPv4 only, but it should say IPv4 and IPv6. Lou Berger talked about changes in the RSVP IPsec document. There has been some reorganization and the addition of IPv6 support. Fred Baker talked about the MD5 document. Baker refined the document based on ISI's implementation experience, and extensions were made for IPv6. Future work will include coordination with Herzog's work on Policy Data objects. Braden then addressed three remaining issues with the current RSVP spec. First, a change is needed in the Reservation Error message to correctly do blockade state: reservation error messages for Wildcard Filter reservations should contain a PHOP object. The second issue was with how blockade state is organized. A possible problem occurs for a non-RSVP cloud or a broadcast network when reservations with different QoS arrive on the same interface. The spec was ambiguous, but blockade state should be associated with the Reservation State Block (RSB) and not the Traffic Control State Block (TCSB). The third issue concerns the calculation of a merged flowspec to be forwarded upstream. The spec currently says that an effective flowspec is computed for each outgoing interface with a reservation. These effective interface reservations are then combined to compute a merged reservation to forward upstream. What was proposed is to compute the merged reservation from the reservation state from all next hops rather than from the effective reservation on each outgoing interface. B. IMPLEMENTATION STATUS ------------------------- Reports were made by ISI and vendors on the status of implementation efforts. BayNetworks (Krawczyk) Bay has a subset of the ID12 code running at one customer site, interacting with QOSPF (see later). The early availability program for other RSVP developers is starting within a month. General release is expected in February, 1997. CISCO (Baker): A beta release is expected "real soon", with a product release around September. IBM (Dilip Kandlur): IBM is doing a multihomed host implementation with traffic management including buffers as well as bandwidth. They are prototyping traffic control for ethernet, token ring, and ATM. There are some differences in their API from the generic API in the spec. Intel (Raj Yavatkar): Intel is doing RSVP for Windows 95 and Windows NT platforms using the Winsock 2 QoS API. They are implementing the Subnet Bandwidth Manager (to be discussed in the ISSLL Working Group). They currently have a stable RSVP ID08 in beta test interoperating with Cisco routers and expect to be interoperating with Bay Networks routers soon. They have an ID12 in development and expect to be in beta test soon. They expect products in September. Sun (Don Hoffman): Sun currently is running a version of RSVP based on the ISI 4.0a4 code for Solaris 2.4 and 2.5, with mrouted 3.8. They also have CBQ for various Sun interfaces (be, le, ...). A prototype subnet bandwidth manager is expected soon (see Intel above). Availability is currently by request to hoffman@eng.sun.com. ISI (Braden): ISI is currently distributing version 4.0a4 based on ID12 of the RSVP spec. Various tools, plus support for vat and nv are included. Differences from the spec include: PATH messages are NOT sent with the original source address No IPv6 support No ADspec No key management for integrity No policy data object No support for encapsulated data in tunnels No IPsec No semantic fragmentation Japan (Masataka Ohta): Ohta reported that there were also couple of RSVP implementation efforts going on in Japan based on the ISI code. C. COMMERCIAL INTERNET MULTIMEDIA TRIAL ---------------------------------------- Mark Baugher of Intel spoke about a trial effort announced by Intel and MCI for testing a service based on IP, IP Multicast, RSVP, and RTP. Their goal is to have a commercial version of this service in 1997. Intel expects to have about 200 desktops connected to this trial by this fall. Security is a big issue, especially firewalls. There is expected to be user and application authentication, in addition to the firewall support. D. OPEN DOCUMENT STATUS ------------------------ Baker talked about the status of the MIB documents, including the RSVP MIB, Controlled Load Service MIB, and the Guaranteed Service MIB. Several issues were raised with the RSVP MIB. One set of issues concerned major areas of the MIB whose values would be directly available in some implementations but require significant computation in other implementations. It was suggested that at least some of these should be made optional. Those who had read the MIB and had comments agreed to talk with Baker after the meeting. Baker's plan to allow SNMP to create RSVP state was controversial. It was unclear how such manually configured state would interact with RSVP soft state created by normal RSVP messages (e.g., can SNMP- created state be deleted by RSVP teardown messages). Lixia Zhang discussed the status of the Diagnostic Message document. In the new revision, the MTU is carried in the message header. If at some point, a router finds the message is too big, a partial Diagnostic Message is returned. She reported that UCLA is working on an implementation of diagnostic messages on SunOS and is looking for separate implementations for debugging the spec and for interoperability testing. E. NEW WORKING GROUP CHARTER ----------------------------- Braden led a discussion of a new charter for the RSVP Working Group. There was general agreement that a new charter was needed, and several changes were suggested to his proposal. There was some controversy on whether ``advance reservations'', i.e., making a reservation now for some time in the future, should be part of the charter. There was general agreement that a BOF on advanced reservations would be useful. The result of the discussion was general agreement on the following objectives for major topics in the Working Group: IETF Meeting Dates: TOPIC 12/96 4/97 8/97 12/97 5/98 Diagnostic Msg Approve Tunnel Support Draft2 Approve AccCont Mechanism Draft3 Approve AccCont Framework Draft2 Draft3 Approve Version 2 RSVP Draft1 Draft2 Draft3 Approve ====================================================== ======================= Wednesday June 26 RSVP Working Group session II A. ISSUES FOR RSVP VERSION 2 ----------------------------- 1. IPv6 Several issues need to be addressed for IPv6. First, the Router Alert draft needs to be updated (this has apparently been done by Ran Atkinson in the IPng working group). There was some discussion over whether an IPv6 hop-by-hop option should be used for router alert messages. The consensus was that we should use whatever comes out of the IPng working group. There is a second issue about how to use the IPv6 flowid field. A third issue is whether the RSVP checksum should include a pseudo-header for IPv6, since IPv6 has no header checksum. Finally, there was a question of whether the RSVP for IPv6 should be a separate document. There seemed to be a consensus to defer any decision on separate IPv6 documents until there has been more implementation experience. 2. MTU Since Integrated Service generally assumes no fragmentation of data packets, there must be some way for a sender to learn the maximum path MTU, and this mechanism must work for multicasting. There are three possible classes of solutions: a. IP level - MTU discovery b. RSVP level c. Traffic control. as part of an ADspec Wroclawski said that the problem has been solved using solution (c) and will be discussed in the Integrated Services Working Group. 3. Session Groups Originally, session groups were intended just for hierarchically encoded signals. There is an additional need for session groups for mapping a selected set of sessions into the same shared reservation. Madhu Sudan presented a solution where sessions can be related by a session group ID. For example, there might be one audio session and several layered video sessions for a single video conference. Within a session group, the sessions must be ordered on a priority basis. Receivers can receive any consistent subset of sessions from a session group where a consistent subset means that for any layer in the subset, all lower layers must also be in the subset. Only one PATH message is sent per source per session group, and only one reservation message is sent per session group. The reservation message carries a bitmask that tells which layers are being reserved. This presentation received a number of comments. A major one is on the limitations of the proposed session group ID's: why not take the earlier approach of assuming all sessions in the same group take consecutive multicast addresses? Related to this was a concern that 16 bits for a (global) session group ID might not be enough. Another concern is the proposed constraint on admission control: assuming all sessions in a group are ordered, a router cannot admit the second session if it has not seen the first one. This constraint limits all the sessions of one group to be routed on the same tree. A final comment was that all sessions needed to have the same style. Often a video session will work best with a distinct reservation while an audio session will work best with a shared style. 4. Mobility While mobility poses a significant routing problem, there was a general question whether this is an RSVP problem. There are some possible RSVP issues about priorities between reservations. In this case, a ``high priority'' reservation would preempt a low priority one if necessary due to mobility. Another possible issue is to predict the course of a mobile host and attempt to create new reservations before they are needed. The consensus was that these issues are not RSVP protocol issues. 5. RSVP Tunneling John Krawczyk (JJ) of Bay Networks gave a brief summary on what has been proposed, and raised a new issue: the current proposal does not handle the case where the other end of the tunnel either does not speak RSVP or does not understand RSVP tunneling. As long as tunnels are manually configured, however, such issues are easily handled. However, the problem comes up when a tunnel is dynamically configured (e.g. in the case of mobile IP tunneling). Should we handle the case of dynamic tunnels with unknown degree of RSVP support at either end? An argument was presented that we should not, because (1) the tunneling proposal is moving forward together with the RSVP spec, and we expect RSVP-capable routers to support RSVP tunneling as well; and (2) RSVP will either become widespread or not, but the world is unlikely to be split evenly between RSVP and non-RSVP routers. Therefore, it is not worth the complexity to worry about how the two sides interoperate; in case of doubt, just don't do it. There was also some discussion about different encapsulations. The general consensus was that RSVP should be using existing encapsulations (and possibly allow for negotiating some encapsulation such as a new SPI for IPsec). 6. Route Management Eric Crawley of Bay Networks talked about the QOSPF protocol, an extension of MOSPF for QoS routing QOSPF uses resource availability as well as the shortest path to make routing decisions. Thus your QoS route need not take the shortest path. A more detailed presentation will be made at the QoS Routing BOF on Friday morning. A number of comments were received after the presentation. The main concerns are the scaling issue and the pinning issue. The scaling issue is whether it is reasonable to distribute resource information along with the shortest path information. The pinning issue is whether it is reasonable to pin a route based on a transient state of the network. Braden presented one slide on the status of work on route management by Daniel Zappala and Deborah Estrin at ISI, and in particular on alternate path joining and routing pinning mechanisms. A previous effort had used separate mechanisms for these two functions. The current effort is to base pinning on the alternate path joining mechanism. 7. Access Control and Accounting Shai Herzog talked about access control and accounting, which he lumps together under the term "policy". He has split his earlier Internet Draft into three separate documents, on the policy model, on the policy mechanism, and on related extensions required in RSVP. His policy models are based upon bilateral agreements between adjacent network domains, with a control granularity the same as RSVP's. Policies are assumed to be locally configured and controlled. His basic mechanism is a "Local Policy Module" or LPM, which is a separate functional box from RSVP. A number of issues were raised: (1) where do the policies live and who develops the policies; (2) which parts of policies need to be standardized; and (3) which parts of the policies are beyond the scope of the RSVP working group. Some of the issues discussed are clearly RSVP issues, while others are less directly related to RSVP. There was general agreement that the third document, containing RSVP extensions, should be handled by the RSVP working group in a timely manner. The action items include Policy Data object formats and semantic fragmentation rules. Action items also include a new RSVP message - Reservation Report for end-to- end acks - and RSVP/policy interface guidelines. It was suggested that the other topics should be addressed by a BOF.