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.