INTERIM MEETING REPORT Reported by Bob Braden, Information Sciences Institute Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) The Working Group held a one-day interim meeting at Cisco in San Jose on November 10, 1995. There were 21 participants, and the meeting was broadcast over the MBONE. Minutes were also published. Bob Braden presented an extended summary of the discussion and conclusions of this meeting. o Protocol Changes Ratified The interim meeting had ratified a number of changes, to which the Dallas meeting had no objection: o No Filter_Spec object in WF style reservation o StyleId field dropped from STYLE objects o SE style simplified to contain only one flowspec o The TIME_VALUES object required o Policing added at branch points o Defer time specified for local repair o New Agreements Reached The interim meeting had agreed to a number of points, which again the Dallas meeting accepted: o PathErr messages sent hop-by-hop o Tspecs required in Path messages o No merging of SE with WF reservations o Merging of SE with SE as described in document o Removed Rmax (end-to-end bound on state refresh rate R) o Unknown C-Type in objects of known classes is always an error The interim meeting had included extended discussion on a few issues. o UDP Encapsulation The interim meeting had concluded that UDP encapsulation is necessary to handle hosts that do not support any form of raw socket, and that a local well-known multicast address should be used. The unicast session case was discussed in Dallas. For unicast UCP- encapsulated sessions, it may be necessary to configure the hosts with the IP address of the first-RSVP-hop router. However, in the common case that the first-hop RSVP router is also the first-hop IP router, RSVP on the host should be able to auto-configure using the existing routing table machinery. o Role of Protocol Id and Zero Ports The following rules were accepted by the Dallas meeting: o The SESSION object contains a required Protocol Id. o Zero port field means "no port", not "any port". o Ports are always interpreted as UDP/TCP format. o End system should enforce zero-port rules. o Soft ACKs At the interim meeting, several vendors with customer requirements had urged the inclusion of a soft-ACK mechanism originating at the first reservation merge point, even though it is not an end-to-end confirmation and thus does not necessarily guarantee that a reservation has been in place all the way to the source(s). This soft ACK mechanism using a CONFIRM object and message was been added to the latest specification (ID08). o Error Handling The discussion in the interim meeting had not led to a conclusion, and the issue was discussed further (see below). o Tunnels Several issues about the interaction of RSVP with encapsulating tunnels had not been resolved in the interim meeting. Should we require 'interior' routers of encapsulatin tunnels to look inside the encapsulation to classify data packets? This would be necessary to support reservations for individual flows within many of the current tunnel schemes. The alternative would be to not support per-flow reservations within tunnel schemes currently defined, but to develop a new standard for encapsulation that includes a suitable demuxing field within the encapsulation itself. Should RSVP provide for in-tunnel reservations for individual flows? This requires recursively applying RSVP to the reservations within the tunnel, as several have independently observed. o IP-level Security and RSVP filter When IP-level encryption is used, the UDP ports are obscured so that RSVP cannot classify packets. In IP6, the flow id can be used instead, but not for the WF (shared) style. o Diagnostic Messages: Lixia Zhang Lixia has taken on the suggestion made by Mark Handley at the last IETF in Stockholm to develop diagnostic messages for RSVP. The most attractive features of diagnositc messages are that they are independent from any other RSVP messages and do not change any existing state. They can be used to either examine the state of an existing reservation at each hop, or collect information for a future request. To eliminate packet implosion, a diagnostic request message will originate from one receiver and destinate to one source host in the same session. It will be forwarded hop-by-hop, and each hop attaches a reponse block to the message. When the request message reaches the destinated source host, the source host will then chane the message type to "reply" and send it back to the originator. The message may also be sent back by an intermediate router if an error has occurred that prevents further forwarding, or if a specified hop limit has been reached. A minimal set of information to be put in the "response block" include: o time of the message arrival If routers have a roughly synchronized clock through NTP, this collection of time stamps at each router will help estimate the delay between the two ends. o addresses of the current node and the previous ÒroutingÓ hop. This information helps identify non-RSVP clouds along the path. o All the current multicast routing protocols know the previous hop address. o Unicast routing protocols do not provide this information, but it was suggested that one can get the exact list of routing hops (bar any hidden hops by tunnels) along the path by invoking unicast traceroute from the source. o addresses of incoming interface, I, and outgoing interface, O (in data flow direcdtion) o reservation state, or absence of it o Tspec and Rspec that are in place at the output interface O o timer values o a "Merge" flag to indicate whether the request from O has been merged with other requests when being forwarded through I. There was a lively discussion around a number of design issues that are yet to be firmed up. 1. The scope of the information to be collected: should we confine the diagnostic messages to collect only information available from RSVP state, or allow a broader range of possibilities such as bandwidth availability that might be provided by resource management module in the future? The consensus was to only collect information from RSVP state or whatever source we have control over. 2. Should the reply message be unicast directly to the originator, or forwarded hop-by-hop? To get around the firewall, RSVP has been taking the hop-by-hop approach for other message types such as PATH ERR and RESV ACK messages. In contrast, multicast traceroute proposes to multicast the response instead. 3. Should a third party be allowed to initiate a diagnostic message from a chosen receiver? The working group felt we should provide this flexibility. 4. What would be the relation with multicast traceroute, given that there seems certain overlap in functionality? The consensus seems to be that most of the information RSVP collects is not available from mtrace; the two are more complementary to each other than conflicting with each other. Discussion of Open RSVP Issues The group agreed to keep both WF and SE styles in the version 1 RSVP spec. John Wroclawski (re)confirmed that (1) the work by Int-Serv Working Group expects a flag indicating whether there is any non-RSVP clouds along the path, and (2) it is RSVP's responsibility to produce this flag. RSVP Spec-08 supports this flag by using hop-counts; the newly proposed diagnostic messages can also provide this information. The group discussed again how to let an end system control the error behavior: whether a reservation should be forwarded despite an error, and when an error message should be returned (and to whom). However, the discussion went off in another direction when Fred Baker brought up the "second killer reservation" problem, in which a peristant unsuccessful attempt to make a large reservation can block smaller reservation requests for the same flow. It was believed that this problem is serious enough to require a solution in the version 1 protocol spec, even if it adds some complexity to the protocol. Further discussion was deferred to the second session.