NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
Lixia Zhang <lixia@cs.ucla.edu>
Bob Braden <braden@isi.edu>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:rsvp@isi.edu
To Subscribe: rsvp-request@isi.edu
Archive: ftp://ftp.isi.edu/rsvp/rsvp.mail
Description of Working Group:
RSVP is a resource reservation setup protocol for the Internet. Its major features include: (1) the use of ``soft state'' in the routers, (2) receiver-controlled reservation requests, (3) flexible control over sharing of reservations and forwarding of subflows, and (4) the use of IP multicast for data distribution.
The primary purpose of this working group is to evolve the RSVP specification and to introduce it into the Internet standards track. The working group will also serve as a meeting place and forum for those developing and experimenting with RSVP implementations.
The task of the RSVP Working Group, creating a robust specification for real-world implementations of RSVP, will require liaison with two other efforts: (1) continuing research and development work on RSVP in the DARTnet research community, and (2) the parallel IETF working group that is considering the service model for integrated service. Although RSVP is largely independent of the service model, its design does depend upon the overall integrated service architecture and the requirements of real-time applications. As an additional task, RSVP will maintain coordination with the IPng-related working groups.
Goals and Milestones:
Done |
|
Hold BOF on RSVP at Houston IETF meeting. |
Done |
|
Prepare new draft of RSVP Protocol in time for Seattle IETF meeting, following e-mail review and possible MBONE meetings. |
Nov 94 |
|
Submit the RSVP specification to the IESG for consideration as a Prototype RFC. Begin revision based on experience. |
Mar 95 |
|
Release revised specification. |
Jul 95 |
|
Submit RSVP specification to IESG for Proposed Standard status. |
Internet-Drafts:
· RSVP Cryptographic Authentication
· RSRR: A Routing Interface For RSVP
· RSVP Operation Over IP Tunnels
· RSVP Management Information Base
Request For Comments:
RFC |
Status |
Title |
RFC2205 |
PS |
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification |
RFC2206 |
PS |
RSVP Management Information Base using SMIv2 |
RFC2207 |
PS |
RSVP Extensions for IPSEC Data Flows |
RFC2208 |
Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment | |
RFC2209 |
PS |
Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules |
RSVP Minutes
43rd IETF in Orlando, FL
Steven Berson
Thursday December 10 1300-1500
RSVP Working Group Minutes
A. WORKING GROUP STATUS
Three documents still need to go to Working Group Last Call: the Diagnostics draft, the tunnels draft, and the Integrity draft. The Diagnostics and Integrity drafts should be ready to go to last call after this meeting. A problem that has come up with the tunnels spec will be discussed.
The Opengroup has published the RAPI interface. An HTML version is available on the web as
http://www.opengroup.org/publications/catalog/c809.htm
Postscript and printed versions are available for a nominal charge.
B. DIAGNOSTICS DRAFT
Lixia Zhang talked about draft-ietf-rsvp-diagnostics-05.txt on RSVP Diagnostic messages. There were some minor text changes and lots of polishing since the last IETF. The only technical change is an added description of the limitation of the current approach. To get around the ``black holes'' caused by RSVP routers that do not support Diagnostic functions, RSVP diagnostic design uses traceroute to find the next RSVP+diagnostic node after the blackhole; this approach works well with multicast reservations but breaks in case of asymmetric unicast routes. These limitations are described in the draft.
There is an implementation available at UCLA at:
http://irl.cs.ucla.edu/
The meeting agreed to advance this specification to Working Group Last Call.
C. INTEGRITY DRAFT
Bob Lindell talked about draft-ietf-rsvp-md5-07.txt on RSVP cryptographic authentication. RSVP provides integrity and authentication (but not confidentiality), with protection against replays. Lindell summarized key management issues: (1) keys have lifetimes, (2) the key identifier names both the key and the algorithm, (3) keys are distributed Out-Of-Band (OOB), and (4) keys need to be distributed to all next hops. The last issue affects large LANs.
Changes in the draft include:
(1) Key ID now need only be unique per sender, not globally unique,
(2) a handshake-OK flag has been added,
(3) the spec now defines a key-management abstract interface, and
(4) challenge and response messages are now distinct.
The new handshake-OK flag is set by a sender that is prepared to respond to a challenge from the receiver; this handshake is needed to securely establish an initial sequence number for integrity objects. If the handshake-OK bit is not set, the receiver can avoid waiting a full timeout period for a response that will never come.
There are several competing design goals, particularly auto-configuration, that make in-band key distribution desirable. The issue that held back the draft was the key replay problem, which is now addressed. Some people also want the document to include some key management provisions, which the current draft leaves for other documents (and probably for other WGs). The meeting consensus was that a combined draft would be better, but that the WG should go ahead with a last call on the current draft if it takes too long to write the combined draft. The decision was to give Fred Baker and Tim Moore two months to update the draft; otherwise, the current draft will go to last call, and key management will be in a separate draft.
D. TUNNELS
John Wroclawski (representing the int-serv working group, as well as being a co-author) has noted one problem in draft-ietf-rsvp-tunnel-01.txt. The problem concerns the dynamic binding of end-to-end RSVP sessions to pre-configured RSVP sessions over an IP-in-IP tunnel. The current draft assumes that the end-to-end PATH messages carry enough information to choose among multiple tunnel sessions. John pointed out, however, that RSVP semantics requires that the receving end be able to make this binding decision dynamically. That is to say, the binding should be determined only when the reservation message from the receiver arrives.
Discussion centered around whether the current draft can go to last call with only a description of the issue, or whether a solution for the issue is required at this stage. Lixia pointed out that the design goal is *simple* support for RSVP reservations over IP tunnels; because the RSVP sessions over the tunnel are set up through a management interface, the policies regarding which end-to-end session can use which tunnel session are presumably made at the same time. Hence the current design does not go as far as providing the receiver the ability to dynamically change the binding. The consensus was that it was OK to go to last call with a clear description of the issues, but it would be desirable to solve the problem if a simple solution exists. The decision was that Lixia Zhang and Andreas Terzis at UCLA would have up to two months to revise the draft to solve these problems; otherwise, the draft will go to last call with only an added description of the issues.
E. RSVP AND DIFF-SERV
John Wroclawski talked about the relationship of RSVP and Int-Serv to Diff-Serv. This issue was initially raised in the diffserv WG (and in the aggregation work presented in this working group in Chicago), but parts of the work are being transferred to the RSVP and the ISSLL WGs. The current work is in the following drafts:
- draft-ietf-diffserv-rsvp-01.txt
- draft-bernet-diffedge-01.txt
- draft-berson-rsvp-aggregation-00.txt
- draft-guerin-aggreg-rsvp-00.txt
In one model, a diff-serv cloud can simply be treated as a single logical link. It was agreed that ISSLL WG will undertake the design of this approach and the definition of mappings of Int-Serv services onto Diff-Serv services that it requires. This approach also has two short-term issues that are specific to the RSVP WG: how to pass RSVP messages without processing through parts of a diffserv cloud, and how to use the DCLASS object to pass diffserv class information.
However, this model has important restrictions with respect to support for multicast and heterogeneous reservations, issues that have been central to Int-Serv and RSVP. Resolving these issues appears to involve protocol design in which limited amounts of RSVP-like flow state will be required at points inside the cloud. This design ought to take place within the RSVP WG. Another RSVP WG issue is how (and if) to do admission control within the cloud as suggested in the aggregation drafts. There was general consensus that the RSVP working group should be looking at aggregated flows, using diff-serv as one mechanism. However, the WG charter will need to be updated.
There was some confusion about what the DCLASS object is. It is supposed to be like the TCLASS object used in the SBM draft (draft-ietf-issll-is802-sbm-07.txt), but Yoram Bernet took an action item to write up the DCLASS/TCLASS objects and mail it to the WG.
F. MPLS
Lou Berger talked about draft-ietf-mpls-rsvp-lsp-tunnel-00.txt, which discusses extending RSVP for use with MPLS. Basically, there will be a large number of RSVP messages in a large MPLS cloud, and message processing might take up too much router time. This draft proposes a series of changes to RSVP to reduce message load. These changes include having message IDs, ACKing all messages by message ID, and using HELLO messages to verify that neighboring routers are alive. It uses these facilities to provide local hard state for RSVP signaling.
There was no general consensus on this proposal. Some felt that these proposed changes add a lot of complexity without a clear need. Others felt that it is the right direction to move.
G. PARAMETER-BASED ADMISSION CONTROL (PBAC)
Marc Greis talked about draft-greis-aggregation-with-pbac-00.txt which uses measurements as well as aggregate reservation data to do admission control for an aggregated RSVP. He showed simulation data that showed a more conservative admission control at a cost of a small number of extra messages.
H. SCRAPI
Bob Lindell talked about draft-lindell-rsvp-scrapi-01.txt which describes a simplified API for RSVP, based on RAPI. SCRAPI does not require an application to specify detailed flow specs or callbacks. SCRAPI uses two main calls, scrapi_sender() and scrapi_receiver(), which take simpler parameters than RAPI and use defaults for other parameters. SCRAPI provides no detailed error messages; instead, it returns a 3-valued reservation status, green (success), yellow (pending), or red (error). Several applications using SCRAPI are distributed as part of ISI's RSVP applications release (see http://www.isi.edu/rsvp/release.html). There are still some issues: CONFIRM messages are not reliable, and the error model for multicast can still be complex.
Update of RSVP Diagnostics
RSVP Cryptographic Authentication
Problem Space
MPLS Traffic Engineering
IntServ State Aggregation using Parameter- based Admission Control
SCRAPI Applications Programming Interface for RSVP