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.