CURRENT_MEETING_REPORT_ Reported by Lixia Zhang/Xerox PARC and Robert Braden/USC-ISI Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) The RSVP Working Group met on Wednesday and Thursday. The primary objective of the meeting was to review and discuss the major revision to the protocol specification that resulted from the San Jose meeting, with the intent of moving towards standardization. Review of Revised Functional Specification Bob Braden gave a presentation on the revised Functional Specification, emphasizing the changes from the November 1994 draft (04). The new draft is: draft-ietf-rsvp-spec-05.ps, .txt. Modifications/additions: o RSVP session: `generalized port' is (UDP/TCP) port. o Flowspec: Rspec and Tspec. o Filterspec: `generalized port' is (UDP/TCP) port. o If link layer is active (e.g., ATM), the traffic scheduler does whatever is necessary to obtain desired QoS from link (e.g., use signaling protocol). o Added OPWA. o Dynamic filter style moved to appendix: high priority study. o Format of RSVP messages completely changed to small fixed header followed by sequence of variable-length typed objects. Issue from Berson: Whether to forward a Resv message when an error is found, is still open. Note that reservation error may still occur even with OPWA. Issue: Recovery from routing changes: should we do local recovery, or end-to-end? The argument for local recovery is protocol simplicity; no additions are necessary. Arguments for end-to-end recovery are: (1) RSVP cannot recover faster than the underlying routing protocol's reaction time, and (2) local recovery has the danger of making reservation along wrong paths. Comment from Farinacci: We have experienced that in PIM implementation -- whenever topology changes, hosts often rejoin the multicast group through wrong interface, and have to readjust later. Fixed header includes length, since we did not include a pseudo-header. Question: Is pseudo header a good thing anyway? (The audience seemed to reached consensus of not using pseudo-header). It was noted that the explicit message length field is redundant, since it can be easily derived by parsing the objects in the message. Issue: Why not just define one filter type instead of two? Braden: allows different address families: currently IPv4 and IP6, in the future perhaps IPX, etc. Issue from Ajit: RSVP interface has to be redesigned to match the latest multicast routing release. Braden: Yes, RSVP has a routing-dependent adaptation module to interface to routing. Farinacci: Better not to design a protocol based only on the implementation one knows today. Have one credential per sender in Path messages, but only one credential per reservation -- this is due to resv merging, in order to scale. In WF style, an optional filter specification is allowed, to support partial wildcarding: e.g., (host,*) or (*,port), as well as a full wildcard sender (*,*). Not clear this is useful, but it is an easy generalization. Issue: How to compute merge sender_Tspecs in order to compute reservation = MIN(Tspec, sender_Tspec). It seems that they must be summed. Question: why should different receiver and sender Tspec be allowed? Braden: to prevent over-reservation on access links. Question: Who is working on the RSVP/routing interface issue now? Braden: Daniel Zappala, with Deborah Estrin. Will make sure document is presented to the working group. Presentations on Two Major Open Issues Issue One: Wildcard Filter Looping Steve Berson presented a review and proposed solution to the two problems posed by the wildcard filter style (more generally, by any style with wildcard scope) with looped topologies: unwanted reservations, and self-refreshing loops. This was joint work with Daniel Zappala. Their proposed solution: Record the upstream senders for each outgoing link and carry that sender list in each Resv message going upstream. If the underlying multicast routing protocol uses shared trees, then this information not necessary. The main issue with the proposed solution is scalability: it causes a linear increase in the size/number of Resv messages with the number of senders. However, Zappala and Berson pointed out that its scaling is the same as the scaling of Path messages and of (source-tree-based) multicast routing. Braden introduced a related proposal: Add a new reservation style, ``shared explicit.'' This style would allow a receiver to explicitly list the senders to use a shared reservation. It would also be possible for the application to call for a wildcard SE reservation, with the RSVP daemon filling in the complete sender list from the path state. The result would be exactly analogous to a WF reservation using the Zappala/Berson scheme. There was a lengthy discussion of the issues. Wroclawski strongly objected to the proposed WF modification, due to scaling. He suggested that it could seriously impact possible future applications. Others in the room attempted to construct alternative solutions (and there were later claims of success, although no alternative has yet been documented). Issue: our application requires reservation ACK. Braden: Can be added into OPWA messages. There seemed to be general agreement that the SE style (without the wildcard) was a useful feature that should be in the specification. There was not a clear consensus on what to do about wildcard filters. Zhang argued for taking some time to look for a better solution. Issue Two: IP6 Flow Label in RSVP Lixia Zhang presented a proposal on how to support IP6 flow labels in RSVP, to speed packet classification. IP6 flow labels have the constraint: all packets carrying the same flow label must have the same source and destination address. This limits the use of flow labels to demultiplexing packet streams within each source host. She proposed that a flow label could simply replace the port number and protocol ID fields in an RSVP filter specification. There was general agreement with this approach. Implementation Status and Vendor Plans o Prototype RSVP daemon: Steve Berson, ISI Release 2.1 of the RSVP code was released on 17 March. The rsvpd in 2.1 is functionally the same as release 2.01, but 2.1 has many updates and fixes. Release 2.1 also includes the modified applications from MIT and a modified mrouted. o Applications using RSVP: Bobby Minnear, MIT MIT has updated their Tk/Tcl-based RSVP interface program tkrsvp to use the new API. This supports RSVP reservations for vat, for example. They have also modified nv to support RSVP. This code is part of the latest ISI release. o Traffic control kernel using RSVP: John Wroclawski, MIT MIT has done a FreeBSD implementation of a traffic control kernel, including CSZ scheduling with link-sharing. o Solaris implementation: Don Hoffman, Sun The Solaris RSVP+CBQ version of the release 2.01 RSVP code is available now on the net. Releast 2.1 will be available very soon. o Bay Networks: John Krawczyk Bay Networks is implementing multiple sources of reservation information: RSVP, ST2, and static configuration for reserved flows. Their architecture will have these sources as parallel inputs to the scheduler. Their timetable: - Ship ST2 implementation by summer (September) - Ship RSVP implementation by fall (October) o Cisco: Dino Farinacci Multicast routing has been widely deployed inside Cisco (PIM), they plan to ship WFQ by July, and RSVP by the end of the year. Discussion of More Open Issues o Flowspec format Braden suggested that the format of flowspecs should be defined by the INTSERV Working Group, with an appropriate indirection in the RSVP specification. Issue: since one cannot leave a hole in real code, whose responsibility it is to define a minimal flowspec that vendors can implement now? o More on WF style looping Zhang: Some progress has been made towards resolving WF loop problems. The basic idea is that: (1) PATH messages do not loop themselves; (2) if RESV messages are made to reverse the paths of PATH messages precisely (this is not done in the current specification), they will be loop-free and travel no further than PATH messages. o UDP encapsulation revisited Presentation by Braden: UDP encapsulation turned out to be more complex than expected. Two different well-known multicast addresses need to be used for encapsulation. UDP encapsulation allowed RSVP to work through PARC firewall (their security people did not link a new IP type, but they understood how to handle UDP packets with given address and port numbers). But there was a multicast tunnel, which required a special provision: unicasting Path messages from host to first-hop router. Question by Wroclawski: Getting worried about hack after hack, hence losing architectural oversight. Please summarize all the hacks that have been proposed so far in one place for assessment. Question by Baker: Why not just UDP encapsulations everywhere and forget protocol ID 46? Farinacci: Would make it much harder/less efficient to grab RSVP packets in routers. o Functionality and reliability issues - Require RPF check on received messages? - Do we need to send more than one copy of teardown messages? - How to use IP6 flowIDs? [Resolved earlier.] o Security issues - Security data - Do we need credential for teardown? [The answer seemed to be no.] - What if a credential changes? Question: What is needed for Version 1 specification in terms of security considerations? - RSVP needs the same integrity check used by routing protocols today. - There was some discussion of credentials. USC/ISI and MIT are working on the administrative model for credentials. There is a note that will be distributed to the working group. Question: Should the credential issue be left for future study or defined now? (Lots of discussion). Advanced Reservations o Using RSVP for advanced reservations: Mikael Degermark, University of Lulea, Sweden Question: Receivers may not be all turned on yet when you make reservations one month in advance, and the topology may also change in between. Therefore RSVP does not seem to be the right vehicle for advanced reservations in the way as the authors have proposed. Response: RSVP messages can be sent very slowly in advance of the event. o The `RBONE' proposal for using RSVP in the MBONE: Steve Casner, ISI Comments: A proper analogy between advanced reservation and RSVP is airline reservations: airlines make advanced reservations by selling tickets, air traffic controller controls the real traffic. Issue: Would the proposed advanced reservations motivate people to all make advanced reservations? What would be the impact?