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.