RSVP Minutes 43rd IETF in Orlando, FL Steven Berson Thursday December 10 1300-1500 RSVP Working Group Minutes A. WORKING GROUP STATUS ------------------------ Three documents still need to go to Working Group Last Call: the Diagnostics draft, the tunnels draft, and the Integrity draft. The Diagnostics and Integrity drafts should be ready to go to last call after this meeting. A problem that has come up with the tunnels spec will be discussed. The Opengroup has published the RAPI interface. An HTML version is available on the web as http://www.opengroup.org/publications/catalog/c809.htm Postscript and printed versions are available for a nominal charge. B. DIAGNOSTICS DRAFT --------------------- Lixia Zhang talked about draft-ietf-rsvp-diagnostics-05.txt on RSVP Diagnostic messages. There were some minor text changes and lots of polishing since the last IETF. The only technical change is an added description of the limitation of the current approach. To get around the ``black holes'' caused by RSVP routers that do not support Diagnostic functions, RSVP diagnostic design uses traceroute to find the next RSVP+diagnostic node after the blackhole; this approach works well with multicast reservations but breaks in case of asymmetric unicast routes. These limitations are described in the draft. There is an implementation available at UCLA at: http://irl.cs.ucla.edu/ The meeting agreed to advance this specification to Working Group Last Call. C. INTEGRITY DRAFT ------------------- Bob Lindell talked about draft-ietf-rsvp-md5-07.txt on RSVP cryptographic authentication. RSVP provides integrity and authentication (but not confidentiality), with protection against replays. Lindell summarized key management issues: (1) keys have lifetimes, (2) the key identifier names both the key and the algorithm, (3) keys are distributed Out-Of-Band (OOB), and (4) keys need to be distributed to all next hops. The last issue affects large LANs. Changes in the draft include: (1) Key ID now need only be unique per sender, not globally unique, (2) a handshake-OK flag has been added, (3) the spec now defines a key-management abstract interface, and (4) challenge and response messages are now distinct. The new handshake-OK flag is set by a sender that is prepared to respond to a challenge from the receiver; this handshake is needed to securely establish an initial sequence number for integrity objects. If the handshake-OK bit is not set, the receiver can avoid waiting a full timeout period for a response that will never come. There are several competing design goals, particularly auto-configuration, that make in-band key distribution desirable. The issue that held back the draft was the key replay problem, which is now addressed. Some people also want the document to include some key management provisions, which the current draft leaves for other documents (and probably for other WGs). The meeting consensus was that a combined draft would be better, but that the WG should go ahead with a last call on the current draft if it takes too long to write the combined draft. The decision was to give Fred Baker and Tim Moore two months to update the draft; otherwise, the current draft will go to last call, and key management will be in a separate draft. D. TUNNELS ----------- John Wroclawski (representing the int-serv working group, as well as being a co-author) has noted one problem in draft-ietf-rsvp-tunnel-01.txt. The problem concerns the dynamic binding of end-to-end RSVP sessions to pre-configured RSVP sessions over an IP-in-IP tunnel. The current draft assumes that the end-to-end PATH messages carry enough information to choose among multiple tunnel sessions. John pointed out, however, that RSVP semantics requires that the receving end be able to make this binding decision dynamically. That is to say, the binding should be determined only when the reservation message from the receiver arrives. Discussion centered around whether the current draft can go to last call with only a description of the issue, or whether a solution for the issue is required at this stage. Lixia pointed out that the design goal is *simple* support for RSVP reservations over IP tunnels; because the RSVP sessions over the tunnel are set up through a management interface, the policies regarding which end-to-end session can use which tunnel session are presumably made at the same time. Hence the current design does not go as far as providing the receiver the ability to dynamically change the binding. The consensus was that it was OK to go to last call with a clear description of the issues, but it would be desirable to solve the problem if a simple solution exists. The decision was that Lixia Zhang and Andreas Terzis at UCLA would have up to two months to revise the draft to solve these problems; otherwise, the draft will go to last call with only an added description of the issues. E. RSVP AND DIFF-SERV --------------------- John Wroclawski talked about the relationship of RSVP and Int-Serv to Diff-Serv. This issue was initially raised in the diffserv WG (and in the aggregation work presented in this working group in Chicago), but parts of the work are being transferred to the RSVP and the ISSLL WGs. The current work is in the following drafts: draft-ietf-diffserv-rsvp-01.txt draft-bernet-diffedge-01.txt draft-berson-rsvp-aggregation-00.txt draft-guerin-aggreg-rsvp-00.txt In one model, a diff-serv cloud can simply be treated as a single logical link. It was agreed that ISSLL WG will undertake the design of this approach and the definition of mappings of Int-Serv services onto Diff-Serv services that it requires. This approach also has two short-term issues that are specific to the RSVP WG: how to pass RSVP messages without processing through parts of a diffserv cloud, and how to use the DCLASS object to pass diffserv class information. However, this model has important restrictions with respect to support for multicast and heterogeneous reservations, issues that have been central to Int-Serv and RSVP. Resolving these issues appears to involve protocol design in which limited amounts of RSVP-like flow state will be required at points inside the cloud. This design ought to take place within the RSVP WG. Another RSVP WG issue is how (and if) to do admission control within the cloud as suggested in the aggregation drafts. There was general consensus that the RSVP working group should be looking at aggregated flows, using diff-serv as one mechanism. However, the WG charter will need to be updated. There was some confusion about what the DCLASS object is. It is supposed to be like the TCLASS object used in the SBM draft (draft-ietf-issll-is802-sbm-07.txt), but Yoram Bernet took an action item to write up the DCLASS/TCLASS objects and mail it to the WG. F. MPLS -------- Lou Berger talked about draft-ietf-mpls-rsvp-lsp-tunnel-00.txt, which discusses extending RSVP for use with MPLS. Basically, there will be a large number of RSVP messages in a large MPLS cloud, and message processing might take up too much router time. This draft proposes a series of changes to RSVP to reduce message load. These changes include having message IDs, ACKing all messages by message ID, and using HELLO messages to verify that neighboring routers are alive. It uses these facilities to provide local hard state for RSVP signaling. There was no general consensus on this proposal. Some felt that these proposed changes add a lot of complexity without a clear need. Others felt that it is the right direction to move. G. PARAMETER-BASED ADMISSION CONTROL (PBAC) -------------------------------------------- Marc Greis talked about draft-greis-aggregation-with-pbac-00.txt which uses measurements as well as aggregate reservation data to do admission control for an aggregated RSVP. He showed simulation data that showed a more conservative admission control at a cost of a small number of extra messages. H. SCRAPI ---------- Bob Lindell talked about draft-lindell-rsvp-scrapi-01.txt which describes a simplified API for RSVP, based on RAPI. SCRAPI does not require an application to specify detailed flow specs or callbacks. SCRAPI uses two main calls, scrapi_sender() and scrapi_receiver(), which take simpler parameters than RAPI and use defaults for other parameters. SCRAPI provides no detailed error messages; instead, it returns a 3-valued reservation status, green (success), yellow (pending), or red (error). Several applications using SCRAPI are distributed as part of ISI's RSVP applications release (see http://www.isi.edu/rsvp/release.html). There are still some issues: CONFIRM messages are not reliable, and the error model for multicast can still be complex.