CURRENT_MEETING_REPORT_ Reported by Lixia Zhang/Xerox PARC and Robert Braden/USC-ISI Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) Agenda -- Tuesday's Session o Summarize status of RSVP specification: Bob Braden o Discussion of RSVP specification o RSVP integrity: Fred Baker Summarize Status of RSVP Specification Bob Braden stated the goal at this IETF: examining the protocol specification in detail to determine its feasibility to move forward to Proposed Standard. The meeting started with the revision of the specification since the last IETF. Bob then went through the changes in the protocol specification that were made after Danvers IETF. o Interface to routing: A separate Internet-Draft has been published on the RSVP and routing interface. Someone from the floor pointed out that the Internet-Draft did not cover cases where the underneath multicast protocols are CBT-like instead of per source trees. Another issue regarding routing is inter-working with hierarchical multicast routing. Given the latter is coming out soon, it must be accommodated in RSVP Version 1. o Session groups: Recent discussions on support for distributed simulation revealed a need for sharing one reservation by multiple sessions, a case that we have not thought through much. Further study is warranted and therefore the concept and handling of session groups have been postponed to Version 2. o Drop-Flag in PATH messages is permanently removed. o IPv6 support for bigger addresses and flow label have been specified. o Filter specification format has been changed to protocol-specific format following the consensus from the Danvers IETF. o Reservation styles now consist of WF, FF, and SE (Shared Explicit). No merging is allowed between shared reservation (WF, SE) and distinct reservations (FF). o Negotiation Models: OPWA support has been incorporated into the current specification. Bob then went on with a couple of hot issues that have been discussed lately. The first was the format of flowspec to be used in the real-time service demonstration at the September Interop. The current plan is to use the one defined in the INTSERV template document. As co-chair of the INTSERV Working Goup, Wroclawski explained that INTSERV plans to do two things: recommend flowspec format, as well as an abstract form for people who want to store the information in different ways. The details should all be nailed down by the Thursday INTSERV meeting. The second issue discussed lately is how to fragment RSVP messages (see Bob's long message to the RSVP list on the pros and cons of different approaches). There are three possibilities: 1. RSVP performing semantic fragmentation itself 2. Relying on IP fragmentation 3. RSVP level linear fragmentation The first choice will be most robust against segment losses, but also with a high implementation and complexity cost. The second one is the easiest way out, however, due to the concern with inadequate support for IP fragmentation in both hosts and routers today, it does not make a feasible option. Balancing all the gains and costs, the current choice is the third one. Discussion of RSVP Specification Lixia Zhang led a discussion on several design issues. o RSVP support over mobile IP tunneling Some believe that there is a more general issue of how to forward RSVP messages over IP tunnels (e.g., in mobile tunnels, or MBone tunnels), and make reservations along the way. Consensus from the floor was that tunneling support seems doable, it is just another piece of work to be done. The only immediate question is whether tunneling support should be part of Version 1, and we agreed to wait till tomorrow to see what would be the timeframe to move the specification to Proposed Standard. o Handling of reservation failures Upon a RESV message failure, the current draft allows routers to both forward the message that triggered the failure and send an error message to the originator of the RESV message. This can lead to two poor protocol behavior, (1) one RESV message can trigger a flood of error messages along the way, especially when it branches out to multiple senders, and (2) worse yet, because RESV messages are sent periodically, one might end with persistent flood of error messages. While Lee Breslau had a presentation schedule for the second working group session to talk about semantic issues of failure handling, Lixia tried to make a more general statement that a protocol design should not allow persistent error messages. One should either forward a request or report an error but should not do both at the same time. A rich set of functionalities can be supported without persistent error messages. There was a lively discussion on this issue. The desired functionalities include: - Options to continue the reservation request along the path despite failures at some early nodes - Option to receive notification of failures at each failed node The group discussed several possible ways to achieve these functionalities and decided to wait till after Lee's presentation to wrap up this issue. o RSVP local repair after route change sender ----- router-1 ---....---- router-N --(failed link)--- Assuming that the routing protocol can promptly notify rsvpd on router-N for the outage, what actions should RSVP take to speed up recovery? There are three options: 1. Router-N sends out a PATH refresh immediately 2. Router-N sends a notification to all senders immediately, so they can send a PATH refresh immediately end-to-end 3. Do nothing, just wait till next refresh cycle The desire is to do better than the third option in terms of recovery delays; both of the first two options, however, suffer from the same problem: we do not know how long it may take the routing protocol to settle down after a topological change, therefore they both may result in sending out refreshes too early. A new suggestion was to have a new damping timer, a promising idea but requires nailing down further details (e.g., How long to wait? After damping, how can router-N detect whether it is on or off the new path? And if router-N is no longer on the path, who should send the refresh?) We ran out of time at this point so Fred Baker's presentation on RSVP Integrity was postponed to the second session. Agenda -- Wednesday's Session Based on the first session, the co-chairs revised the agenda accordingly: o Report on Integrated Services Test BOF (Fred Baker) o Issues for Proposed Standards - Dealing with admission control failures (Lee Breslau) - Unpacking PATH messages? (Lixia Zhang) - Applicability statement - Router alert (Yakov Rekhter) - RSVP and tunneling - Flowspec format - Flow policing at split o Future work - Draft Standard - Version 2 - RSVP integrity (Fred Baker) - Authentication/policy data - API? - MIB? Bob started the meeting by a consensus poll: are we ready to move to Proposed Standard? About a quarter of the group voted yes, no one voted no. Someone from the floor asked what is the relation between the planned two versions of the protocol and the standardization process? The group plans to move to Proposed Standard with Version 1; after a couple of years of running experience and further protocol development, the Draft Standard would likely be Version 2 of the protocol. Integrated Services Test BOF Fred Baker gave a five minute summary of INTSERVT BOF (see the BOF minutes for details). Dealing with Admission Control Errors Due to time limitation, Lee Breslau gave a highlight of the prepared presentation ``Options for dealing with admission control failures''. Lee summarized four options: 1. Return an error message and drop the request 2. Return an error message and forward the request 3. Reservation script 4. Advertise installed service With (1), one can only get services that are available end-to-end; (2) may lead to persistent error messages; (3) allows the receiver to specify router actions on admission failures, which leads to increased functionalities and flexibilities but also potential complexities and difficulties in reservation merging. (4) informs the user the minimal level of installed service along the path. Although each of the four has its own drawbacks, (3) seems to have the potential for the desired functionality; to avoid its complication, one may define a constrained set of simple options. Lee's briefing was followed by a long discussion, focusing particularly on whether RSVP should allow the option of a request triggering error messages at all nodes along the paths. Mark Handley suggested to define separate diagnostic messages for information collection which have the advantages of: o Being able to optionally query information about paths to specific sources, and o Not affecting router state. To find what is going on along the path, diagnostic messages seem more useful than error messages. The group finally reached a (very?) rough consensus of going with a 1-bit flag plus support for diagnostic messages. The flag allows the receiver to specify whether the request should trigger an error report upon admission control failure or be forwarded. Lixia and Lee agreed to work out a first proposal on error handling and diagnostic message design, and we expect to have more discussion on this issue on the working group mailing list. Unpacking PATH Messages Lixia summarized the pros and cons of packing PATH messages. Pros: o Packing reduces the number of PATH messages over each link to one message per refresh period. o Packing over each hop avoids the problem of forcing intermediate routers to send out packets with arbitrary (the original sender) source addresses because packet PATH messages use the sending hop IP address as the source. Cons: When crossing non-RSVP clouds, if the underneath multicast routing protocols use source-based trees, losing the original source address in each PATH message may result in messages being delivered along extra paths (the paths not traversed by data packets). Therefore, o RSVP routers after the clouds may receive duplicate PATH messages from different paths and may not be able to tell which are correct ones to reach the senders; o Extra reservations may be made along the extra paths; o Due to the inability to tell the right path, reservation failure along any of the paths will cause confusions to applications. The group reached the consensus of not packing PATH messages in Version 1. Applicability Statement The working group decided not to do this for now. We need to wait for further experiments to determine the usefulness and necessity of individual parts in the protocol. Router Alert Yakov Rekhter presented a proposal for a new IP option: Router Alert. Basically, a router often needs to examine the payload of a packet that is not destined to the router. For example, check for a specific protocol number to filter out RSVP PATH messages, or check for a specific UDP port for some other purpose. Given that the router already must check for IP options and bump any packets with options out of the fast path, Router Alert option seems a more efficient implementation to cover all cases that require hop-by-hop packet processing. There was a lively discussion on the pro's and con's of Router Alert option on the working group mailing list. It is viewed by some people as crucially important to have Router Alert option implemented before shipping RSVP product, while others see it as a bad design to have RSVP dependent on a particular IP option. This is not work of the RSVP Working Group, but the group plans to have RSVP implementation include the Router Alert option for PATH messages forwarding. RSVP and Tunneling Yakov Rekhter presented another proposal for IP tunneling. The tunnel endpoints create a new ``tunnel'' for each flow, by adding a UDP header right after IP tunnel header and using a unique UDP port number for each flow between the two tunnel endpoints. Along the tunnel, instead of making reservations with the SESSION/FILTER_SPEC parameters, the tunnel parameters are used in the RSVP messages (IP tunnel endpoint addresses, and the UDP port number). The same flowspec is used, bumped up to account for the tunnel encapsulation. In other words, it looks like a separate unicast end-to-end reservation between the tunnel endpoints. When the flow emerges from the tunnel, the original SESSION/FILTER_SPEC parameters are used again. It is unclear whether the issue of how to handle tunneling should be on our plate. One view is that someone, or a separate group, needs to work out a common scheme to handle all potential issues caused by IP tunneling. Traffic Policing at Split Point The working group agreed that it is necessary to police traffic at reservation split points for WF type reservations. Flowspec Format This is not on our agenda; the group will be relying on the INTSERV Working Group to supply us with the flowspec format. Future Work o Go on to Draft Standard: the working group may need another job description but should be doable. o RSVP integrity: although this should be a must, the work does not seem ready for prime time, therefore it will not go in Version 1. Both integrity check and MIB work should be done within this group. o Authentication: study it for Version 2. o API? API contains lots of other things other than RSVP. It should be put off until we have more implementation and experience, and wait until it becomes clearer who should do it Wrapping Up The working group agreed to clean up the current draft specification and then do a last call within the working group, before submitting it to the IESG for consideration as a Proposed Standard.