RSVP Minutes 44th IETF in Minneapolis, MN Jeff Kann Thursday March 18, 1300-1500 RSVP Working Group Minutes A. Last-Call Status Report -- Chairs --------------------------------- o RAP Documents Related to RSVP Shai Herzog believes that the issues raised about the RAP RSVP extensions document have all been resolved. Some of them concerned structuring the document and had no impact on the content of this draft. He posted a new version with some style changes. The meeting consensus was to allow one additional week after IETF to ensure that all comments have been addressed, before closing this WG last call on the RSVP-related RAP documents. o RSVP Integrity Following the agreement at the previous meeting, the RSVP integrity spec was augmented with an appendix supplied by Peter Ford, concerning key management issues for edge networks. The meeting consensus was to let this document begin WG last call after IETF. o RSVP Diagnostics Although the WG had agreed to proceed with WG last call on the Diagnostics spec after the previous (Orlando) meeting, an implementation of the spec later revealed some problems. The spec was fixed, and the consensus of the meeting was to let this document begin WG last call after IETF. o RSVP Tunnels Lixia Zhang said that the latest draft resolves the issues raised at the last meeting by John Wroclawski, and it also contains additional clarification. Braden noted that the mechanism for RSVP tunneling is similar to that of Fred Baker's aggregation draft and to the MPLS tunnel draft (both discussed later in the meeting). However, although it might eventually be possible to re-modularize these documents to build on a common mechanism, we are not yet ready to do that. In the meantime, the tunnel spec, which seems to solve a problem for some (e.g., mobile QoS), should go forward. The meeting consensus was to let this document begin WG last call right after IETF. B. RSVP for Qualitative Applications -- Yoram Bernet ------------------------------------------------- The goal is to provide QoS for applications that cannot quantify their exact needs. Flowspecs do not carry user-generated parameters. DCLASS Object -- Yoram Bernet ----------------------------- A new DCLASS object is sent in RESV messages inside diffserv regions. Boundary routers will perform admissional control and assigns the DCLASS object to the message. Two upper bits of the object class type is chosen to make it a unknown object type for backwards compatibility (forwarded if unrecognized). The question was raised on whether the DCLASS should be in the Intserv/Diffserv architecture draft. Bernet described a DCLASS enhancement table, which maps a router's interfaces to a given DSCP and rate. Although this is a simple approach, it provides some mechanism to do admission control for intserv/ diffserv boundaries. DCLASS is analogous to TCLASS object in the SBM. There were questions about how well we can do admissional control at the boundaries. Lixia said that DCLASS object format standardization is a valid topic in the the RSVP working group, but issues of traffic control are outside our charter. What about multicast? This needs further thought. C. RSVP Aggregation -- Fred Baker ------------------------------ This draft describes a specific mechanism to achieve RSVP aggregation, based upon earlier work by Roch Guerin. The present draft is solving a somewhat different problem than the tunnels spec, since the latter has pre-configured egress points while the present spec allows discovery of the egress points. It creates a new session and filter spec for the aggregated reservation, but classification within the aggregating region is performed using the DSCP. When PATH message arrives the Egress router, it sends a PATH_ERR message to ingress router with DSCP; ingress router then sends aggregate PATH, and egress then sends aggregate RESV message towards ingress router. Bob Braden asked why the decision was made at the egress instead of ingress router and he also wondered where the DLCASS object is used in the scheme. Fred answered that the DCLASS object is being used to specify the MF (DSCP) classification, and as a consistency check. Michael Speer asked about the more difficult multicast aggregation, which was discussed in a draft by Steve Berson. The answer was that multicast introduces heterogenity, which requires some micro-flow (MF) classification at certain branch points within the cloud. There was discussion by Baker, Yoram Bernet, John Wroclawski, and Bob Braden about the relationship of this draft to the tunnel spec. They are closely related, especially if you think of the tunnel draft as a collection of tools rather than a single mechanism. The chairs believe that this draft is being taken up by the ISSLL working group. D. RSVP Extensions for LSP (MPLS) Tunnels -- George Swallow, Lou Berger -------------------------------------------------------------------- Swallow explained the scope of this spec as: o Target application is traffic engineering o Restricted to LSP (Label Switching Protocol) tunnels o Does not describe general operation of RSVP with MPLS o Treats only unicast destinations The advantages of using RSVP for this application are: o Can use SE style for "make-before-break" switching of paths. o Existing protocol framework, avoid inventing another; existing implementation base The MPLS additions to RSVP are: o Tunnel identification o Label distribution o Explicit route specification o Tunnel identification - Class = SESSION, C-Type = LSP_TUNNEL_IPv4 - Class = SENDER_TEMPLATE, C-Type = LSP_TUNNEL_IPv4 Berger summarized changes in the current draft. o New RRO flags o CoS Flowspec o Message_ID simplification - Eliminated extra refresh needed prior to setting last_refresh - Last_refresh can only be set where HELLO being exchanged with RSVP next_hop. o HELLO simplification - Eliminated tracking of per LIH state - Still tracks neighboring RSVP node state - When out-of-sync state detected, all neighbor state expired and must be refreshed It has been agreed that the next version of the LSP Tunnels spec will separate the refresh reduction extension, which is independent of MPLS, from the rest, which is MPLS-dependent. There is some urgency among vendors to reach a quick agreement on the refresh reduction. Meanwhile, Lixia Zhang and her students are investigating an alternative approach to refresh reduction, which will support partial refresh. The plan is to hold an interim RSVP WG meeting, probably at Cisco during April, to try to reach agreement on this spec, hopefully combining the Berger and the Zhang approaches. E. RSVP Tunnel draft update -- Andreas Terzis ------------------------------------- Andrea Terzis gave a very brief summary of the final update to the RSVP tunnel draft. - Mapping between e2e and tunnel sessions is now initiated by e2e RESV messages, to be consistent with the int-serv model. - The tunnel spec briefly distinguishes two different forms of "multicasting" with tunnels. In a "multicast" tunnel, a packet is actually multicast to all egress routers. In a "point-to-multipoint" tunnel, a data packet is replicated at the ingress router, which unicasts a copy (through a tunnel) to each egress router. A complication of the latter form is that the destination address cannot be used within the tunnel for classification. F. Working Group Charter Revision -- Chairs ----------------------------------------- The chairs, in consultation with the Area Director, have decided that it is time for the RSVP working group to terminate. It has accomplished its major goals, and the primary specifications are or soon will be Proposed Standards. Industry is now busy implementing and testing the results. Meanwhile, there is a lack of energy in the current RSVP group for substantive new protocol design work. There is also considerable confusion over the basic design goals of diffserv and intserv, and how the pieces of Internet QoS will fit together. It is time to take stock, perhaps have some new BOFs, and generate new working groups with new foci. There is also a problem of availability of chairs. Michael Speer asked about whether RSVP should go to Draft Standard soon. Fred Baker replied that it seems to be premature talking about draft standard since we are still expecting the first router vendor and also the windows NT to ship. Braden noted that the RSVP mailing list will continue indefinitely. The RSVP WG previously went dormant for awhile, and it appears to be time to kill it now. Lixia Zhang does not think the WG has spent enough effort on the aggregation issue, but this is mostly individual efforts at present. John Wroclawski noted that the ISSLL working group is expected to carry on the aggregation work. However, the RSVP protocol itself appears unlikely to change in the near future. The Area Director Scott Bradner stated that he believes it is rational for the RSVP WG to terminate in the near future. We can schedule a meeting it Oslo, and cancel it if none is needed. G. Short Reports ------------- o Processing Rules -- Bob Lindell The Informational RFC on the RSVP processing rules contains errors. He has drafted a major revision of this spec. His goals were to: o Use more abstract descriptions o Use set operations o Supply minimal state block descriptions o Clarify the RSVP specifications His work has also revealed some minor protocol issues, in particular: o CONFIRM processing requires orderable flowspec o Varying ADSPEC could trigger excess PATH messages (John Wroclawski noted that the int-serv Adspec is not expected to change frequently, but some hold-down and/or granularity control would be advisable). o Fwd_Flowspec may trigger a change in reservation o SCRAPI (Simplified API) Version 2 -- Bob Lindell Lindell described a new version of the simplified API for RSVP, called SCRAPI. It refined the error model and removed the TTL parameter. Open issues include how to compute a reasonable approximation to a token bucket depth with parameters that a typical application is likely to know. Yoram Bernet mentioned the alternative Winsock API, and Michael Speer proposed a simplified interface using the Winsock API as a starting point. o Java API -- Pete St. Piere Sun has developed a Java library for RSVP API. St Piere asked whether working group memebers are willing to act as the "experts group" for draft review.