Subject: Minutes of RSVP WG meeting

From: Bob Braden <[email-masked]>
Date: Wed, 8 Dec 1999 22:43:25 GMT

RSVP Working Group Meeting Minutes
Tuesday, November 11, 1999

1. Working group status
   --------------------

Bob Braden reported on the status of the working group.  The plan is
(still) to finish the work on RSVP refresh overhead reduction
extensions before terminating the working group.  Discussions may
continue on the mailing list ([email-masked]) afterwards, and a new
working group may be constituted as the need rises.

Braden stated his belief that the refresh reduction extensions
represent a fundamental change to the way that RSVP works, and
therefore they need to be designed with some care.

The primary issue at the meeting was to move the refresh overhead
reduction mechanisms towards Proposed Standard.  Secondarily, the
meeting also considered the issue of RSVP proxies.

2. RSVP Receiver Proxies
   ---------------------

Silvano Gai reported on draft-sgai-rsvp-proxy-00.txt "RSVP Receiver
Proxy".  Application developers need a mechanism to signal the network
with user identity, application identification, traffic classification
information, etc., and get back policy information, perhaps including a
diffserv code point (DSCP).  One way to meet this need would be to
install a "RSVP proxy" in the first-hop router.  This proxy could
automatically generate RESV messages for certain sessions (selection
based on policy) in response to PATH messages.  A few missing pieces
needed to make RSVP proxy work are being standardized by other working
groups: the Null Service by the ISSLL WG, and flexible policy
mechanisms by the RAP WG.  A related draft ``COPS Extensions for RSVP
Receiver Proxy Support'' draft-nitsan-cops-rsvp-proxy-00.txt was
presented to the RAP WG.

Discussion centered on whether RSVP proxy requires any standardization
effort from the RSVP WG.  RSVP Proxies do not modify the RSVP protocol;
they only change the way the protocol is used.  After some discussion
the working group reached consensus to move
draft-sgai-rsvp-proxy-00.txt to an RSVP Working Group Informational
RFC.  Further discussion of this proposal should take place both on the
RSVP mailing list and in the RAP working group.  A Last Call for it
will be issued in both working groups.

3. Presentations and discussions on RSVP refresh overhead reduction
   ----------------------------------------------------------------

The "RSVP refresh overhead reduction" extensions have two functions:
(1) reliable delivery of RSVP messages and (2) reducing the overhead
due to RSVP refresh messages.  Reliable delivery will prevent delays in
establishing, changing, or tearing down RSVP state caused by loss of an
RSVP control message.  Refresh overhead reduction will reduce both
network bandwidth and message processing.   The two functions are
included in one extension package because the refresh reduction
mechanisms require reliable delivery.

At Oslo IETF the WG reached a consensus to move these extensions
forward.  Since then, a number of details of the proposed mechanisms
were changed and a few new proposals were made.  The goal of this
meeting was to reach closure on which mechanisms should be move to
Proposed Standard status.

3.1 Berger Draft

Lou Berger reported the changes in
draft-ietf-rsvp-refresh-reduct-01.txt "RSVP Refresh Reduction
Extensions".  This draft:

   (1) broke Message_ID class to 3 classes for message ID, message ID ACK,
       and message ID list;

   (2) added discussion of bundling time delays, including the limits
       suggested by Tommasi;

   (3) added IPv6 CTypes; and

   (4) clarified the transmission mechanism of Srefresh messages
       for multicast RSVP sessions.

Berger presented two options for (4):

	(a) Send a separate Srefresh message to the session address
		for each multicast session.

	(b) Multicast Srefresh messages for multicast path state to
		an all-RSVP-nodes multicast address.  

Option (b) will always result in lower bandwidth for RSVP messages,
since it allows all multicast destinations to be included in the same
Srefresh message.  However, processing overhead is a more complex
tradeoff between options (a) and (b).  Option (b) will require
additional processing to do an RPF check for each received message ID,
but option (b) also requires that fewer SRefresh messages be
processed.

The consensus was to include only (the simpler) one of these options in
the spec.  There was a weak consensus (silence) for (a).

3.2 Tommasi Draft: Compressed List Descriptors (CLD)
    ------- ------ --------- ---- ----------- -----

Franco Tommasi presented the difference between approaches described in
his draft, draft-tommasi-rsvp-enhan-scalab-01.txt "Some extensions to
enhance the scalability of the RSVP protocol", and the Berger draft.
The differences center on the way that summary refresh IDs are
represented.  The Tommasi draft represents Summary refresh IDs using
Compressed List Descriptors (CLDs), which allow IDs that are clustered
to be represented in a very compact encoding.  This encoding can reduce
the number of bytes in a summary refresh message.

Another difference is in the reliability mechanisms for summary refresh
messages.  The Tommasi draft allows both the normal "weak" refresh and
also a "strong refresh"; the latter uses sequence numbers to ensure
that all parts of a summary refresh are received.

Finally, the Tommasi draft allows messages to be sent with an "urgent"
bit, which is analogous to TCP's Push bit; it will terminate the
bundling wait and force immediate forwarding of a Bundle message
containing the urgent data.

The discussion following Tommasi's presentation concluded that the CLDs
may be a good idea.  In order benefit from CLDs, the refresh IDs need
to be assigned in sequential order (or any method producing good
clustering of message IDs).  There was a concern with refresh ID
wraparound if sequential numbering were used.  The urgent bit scheme,
however, raised a big concern.  If all the messages are considered
urgent, policing for urgent bits would be needed, leading to further
complication.  One suggestion, which was generally accepted, would
consider the urgent bit as a hint which could be ignored by a node.

The WG consensus is to consider the CLD and (optional) urgent bit
schemes when finalizing the Berger draft for standardization.

3.3 Hierarchical Summary Refresh
    ------------ ------- -------

George Swallow presented draft-swallow-rsvp-hierarchical-refresh-00.txt
"RSVP Hierarchical Summary Refresh", which further extends the proposed
summary refresh mechanism to allow a hierarchy of summary refresh
messages.  That is, an entire summary refresh (Srefresh) message can
itself be refreshed using a single unique message ID in another
Srefresh message, providing a further reduction in the number of
refresh messages.  If a node receives an unknown message ID, that node
will return a NACK to trigger the retransmission of all the state (be
it an Srefresh message or raw RSVP state) represented by the unknown
message ID.

It was suggested that the potential savings from this second-level
summary might seldom be reached due to the rate of change of
reservations.  Swallow postulated an MPLS environment where RSVP state
seldom changes, and typically all RSVP state changes if any does.  In
such an environment, message processing costs could be substantially
reduced with his proposal.  However RSVP as a general signaling protocol
must consider usage in general cases.  The WG consensus was that the
potential overhead reduction provided by this scheme does not warrant
the addition of its complexity to the RSVP spec at this time.

3.4 Using Session State Checksum as the State ID
    --------------------------------------------
A major concern with the scheme described in the current Berger draft
is that, once the RSVP state between two routers gets out of sync, the
error will never be noticed or corrected.  To overcome this problem
Lixia Zhang described a scheme suggested by Will Leland: instead of
using a sequential number to represent the state of each RSVP session,
a router can use a computed checksum based on the current session state
variables.  This checksum computation can be carried out by a
background process at each router that periodically goes through all
the RSVP sessions to update the checksum.  When a router receives a
session ID that disagrees with the locally computed session ID, it
should send a NACK to trigger the raw RSVP state being retransmitted.

This scheme provides strong checking on RSVP state consistency between
routers.  One major objection to this approach is that different
vendors have different RSVP implementations.  Being able to compare the
checksum between two routers means standardizing the internal
representations of RSVP session state, a step which was considered too
costly.  A compromise was suggested to ease this concern: let each
router keep a checksum of its state as a local variable that is
recomputed periodically, and whenever the checksum changes, the router
triggers a retransmission of the full RSVP state.

4. Discussion of "Refresh Reduction" Extensions
   ---------- -- -------- ---------- ----------

There was consensus to move the refresh reduction draft towards Proposed
Standard as soon as possible.  Specific changes recommended were:

  1. More word-smithing
  2. Adopt the scheme of each router keeping a locally computed 
     state checksum that is updated periodically as a way to detect
     unnoticed state changes.

There was also general agreement that the UCLA proposal "RSVP Refresh
Overhead Reduction by State Compression"
(draft-wang-rsvp-state-compression-02.txt) should be published as
an Experimental RFC.