NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Lixia Zhang <email@example.com>
Bob Braden <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Vern Paxson <firstname.lastname@example.org>
Transport Area Advisor:
Scott Bradner <email@example.com>
To Subscribe: firstname.lastname@example.org
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:
Hold BOF on RSVP at Houston IETF meeting.
Prepare new draft of RSVP Protocol in time for Seattle IETF meeting, following e-mail review and possible MBONE meetings.
Submit the RSVP specification to the IESG for consideration as a Prototype RFC. Begin revision based on experience.
Release revised specification.
Submit RSVP specification to IESG for Proposed Standard status.
Request For Comments:
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
RSVP Management Information Base using SMIv2
RSVP Extensions for IPSEC Data Flows
Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment
Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules
RSVP Working Group Minutes
42nd IETF in Chicago
Reported by: Steven Berson
Tuesday August 25 0900-1000
RSVP Working Group session I meeting minutes
A. WORKING GROUP STATUS
Co-chair Bob Braden (USC/ISI) opened the meeting with a summary on progress in the
RSVP Working Group. Three basic RSVP documents have been published as Proposed
Standards: RFC 2205 (RSVP Version 1 Functional Specification), RFC 2206 (RSVP MIB),
and RFC 2207 (RSVP extensions for IPSEC). The WG has also published two Informational
RFCs: RFC 2209 (RSVP message processing rules) and RFC 2208 (Version 1 Applicability
Statement). Several WG documents have yet not been submitted for Proposed Standard:
MD5 Integrity, RSVP Diagnostic Messages, and RSVP tunnels. Braden noted that the WG
had been dormant since the Munich meeting, and that several new issues that have come up
since then merit discussion.
B. RAPI STANDARDIZATION
Chris Harding (Open Group) spoke on the work in the effort by the XNET Working group
of Open Group to standardize the RAPI application programming interface. The original
RAPI interface was designed and documented by ISI and Sun Microsystems, and it is included
in ISI's rsvpd distribution. As a target for Open group standardization, the original RAPI
specification was too ISI-specific, too Unix-specific, and too socket-specific, and its error
handling was weak. The January 1998 draft removed the Unix-specific and socket-specific
parts, and the June 1998 draft improved error handling and added a specification of the RAPI
and Integrated Services data structures that an application needs to know. In July 1998, the
draft spec was sent out for company review.
Final editing of the spec is scheduled for the end of September, and the spec will then be
published on the Web in html.
C. RSVP INTEGRITY OBJECT
Bob Lindell (USC/ISI) described the updated draft on RSVP Cryptographic Authentication
(draft-ietf-rsvp-md5-06.txt). RSVP provides integrity and authentication (but not
confidentiality) on a hop-by-hop basis, as opposed to the end-to-end approach of IPSEC.
The earlier draft did not reach Proposed Standard because it did not adequately address
replay attacks, in the view of the IESG.
This version of the draft provides an approach based on a key-id, a one-time sequence number,
and an MD5 digest, carried in an RSVP INTEGRITY object. The key-id defines a key and an
algorithm. Implementation of the MD5 algorithm is required, but other optional algorithms may
be implemented. Each key is simplex and is distributed out-of-band. Each key has a defined
lifetime, after which a new key must be negotiated.
Sequence numbers are defined to be monotonically increasing, which requires some form of
stable storage. For example, an implementation might choose to construct monotonically
increasing sequence numbers using a stable hardware clock, a counter in stable storage, or
NTP time synchronization. The sequence number only exists for the life of the key, at which
time a new initial sequence number is chosen. To provide complete protection against replays,
RSVP requires an initial INTEGRITY handshake when the system initializes. This handshake
requires a new RSVP message. The receiver sends a challenge to the sender, which responds
to the challenge by returning its current sequence number.
Out-of-order sequence numbers are handled by keeping a list of the K most recent sequence
numbers that have arrived.
Braden commented that replayed messages within a small time window just refresh existing
state, so they are not a great security threat. The magnitude of the threat need to be balanced
against the complexity of mechanisms to protect against the threat.
D. USER IDENTITY
Tim Moore (Microsoft) spoke about draft-ietf-rap-user-identity-00.txt that has been introduced
into the RAP WG. Its primary function is to define a User Identify (sub-)object for use
within a POLICY object. However, it also draft proposes an extension to the Cryptographic
Authentication draft just discussed, to solve what is seen as a scaling problem for the
Cryptographic Authentication (INTEGRITY) mechanism across a large campus LAN. Their
idea is to use a key associated with the User Identify object, instead of a per-host key, for the
integrity hash in the edge of the network. The intent appeared to be that node-specific keys
would still be used for hop-by-hop integrity in the interior of the network.
Discussion after the meeting clarified the relationship between the User Identity and the
INTEGRITY specifications. It should suffice to made a small addition to the INTEGRITY
spec, noting that the receiver may have only a cache of keys and may have to consult some
external [policy] server to locate the necessary key when an unknown key-id arrives. This
addition will be made shortly.
There remains the issue of key management, to which User Identity draft adds an important
scaling problem. It is not entirely clear which WG needs to address RSVP key management.
There are also a number of unresolved issues in the User Identity work, relating to merging
User Identity objects.
E. RSVP DIAGNOSTIC MESSAGES
Andreas Terzis (UCLA) talked about draft-ietf-rsvp-diagnostics-04.txt, on RSVP diagnostic
messages. The current update has no major changes, although some minor improvements
have been made. There are some changes in the order of processing of DREQ messages,
and an additional paragraph on security considerations.
The draft now deals with the issue of ``black holes', where a node understands RSVP but
does not understand diagnostic messages. Their approach is to use a traceroute or mtrace
approach using multiple messages with increasing ttls to reach the next RSVP node that
handles diagnostic messages.
UCLA has produced a graphical diagnostic client, with a Java applet front end and a back
end written in C.
The question was asked if there is a problem with asymmetric paths, Terzis said yes.
Discussions after the meeting led to the following conclusions:
- There should be no problem with multicast RSVP sessions.
- Asymmetric paths can cause problems in unicast sessions if one runs traceroute starting
from receiver direction. A obvious solution is to run traceroute from sender direction.
The spec is being revised accordingly.
Braden commented that the diagnostics draft is mature and doing a last call soon is reasonable.
Braden mentioned that vendors had wanted this earlier and questioned whether they still do.
No opinions were offered on this.
F. RSVP TUNNELS
Andreas Terzis also talked about draft-ietf-rsvp-tunnel-01.txt. There was a cleanup and
reorganization of the draft for this version. There are three types of tunnels defined: (1) at
least one tunnel endpoint does not support RSVP tunnels, (2) configured tunnels, and (3)
dynamic tunnels created by end-to-end sessions. There is also some support for multicast
tunnels, but such tunnels are for signaling only and not for data traffic.
UCLA's implementation of tunnels needs to be upgraded to the ISI 4.2a4 release, and the SESSION_ASSOC object needs to be handled on an end-to-end basis rather than between the tunnel end-points.
Braden mentioned that the tunnels work, which is less mature than Diagnostic messages, seems to be part of a larger picture, which seems to include diff-serv tunnels, MPLS, and mobile IP. Lixia and George
Swallow stated that MPLS is a separate issue, but Scott Bradner said that the problem set in MPLS is similar to the problem set with RSVP tunnels, so the solutions should be similar. In response to a question from Yoram Bernet, Lixia answered that the current draft does not include diff-serv tunnels. Braden noted that Yoram would be talking about that issue on Wednesday.
Bob asked about the relationship to other new tools, such as MPLS, that are being developed to support VPNs. Lixia clarified the issue by emphasizing that: (1) RSVP tunnel support is needed as long as IP
tunnels exist, and (2) RSVP tunnel support can be used to implement VPNs, but having alternative ways to implement VPNs does not make RSVP tunnel support less useful.
There was no clear way forward from this discussion, but we hope that further discussion on the mailing list will help.
G. ROUTER ALERT
Bob Braden spoke (standing in for Craig Partridge and Alden Jackson (BBN)) about the Router Alert (RA) IP option. The draft RA for IPv6 differs from the Proposed Standard RA for IPv4: IPv4 RA has no
parameter (and vendors look at the IP protocol id), while the IPv6 RA has a parameter whose value registered with IANA. Possible actions include adding the same parameter to IPv4 RA, or removing the parameter from IPv6 and using the IP protocol Id.
There was insufficient time or motivation to discuss this issue in the meeting, and it was deferred. Lixia asked if this is an RSVP issue. Braden said that he would be happy to turn it over to the proper party. Scott Bradner said that the RSVP WG is as good a place as any for it.
Wednesday August 26 1530-1730
RSVP Working Group session II meeting minutes
A. DOCUMENTS ISSUES
Bob Braden led a discussion on the future of the RSVP documents.
- The processing rules document (RFC 2209) is out of date.
Michael Speer said that the document should either be updated or dropped. There was sentiment that the document is highly useful to implementers, implying that it should be updated.
- Should we merge documents such as RFC 2207 (IPSEC) into the RSVP Spec (RFC 2205)?
- Should the WG make the new IPv6 flow labels document a WG item? There is a strong parallel between the IPSEC extension and the handling of IPv6 flow labels; perhaps these should be somehow treated together.
The question was raised whether we should mandate the use of flow labels with RSVP-IPv6. It was not clear whether this issue falls into the RSVP WG domain, and it was tabled.
Lixia urged that the "fat" be cut from the spec. Braden reminded people that document form was the current issue, while Lixia was raising an issue about content. Michael Speer suggested that all changes should be postponed until RSVP is advanced to Draft Standard.
Braden raised the question of the need for UDP encapsulation, and there was broad support for dropping it from the spec. The attendees indicated by their silence that all important operating systems now
support raw mode. Braden will issue a Working Group Last Call for this change.
The Working Group will attempt to advance the Cryptographic Authentication, Diagnostic messages, and Tunnels documents to Proposed Standard. It was undecided when to advance the RSVP Version 1 Spec to Draft Standard.
The Working Group next turned to presentations on important proposals for RSVP extensions, in particular for MPLS, aggregation, and differentiated services.
George Swallow (Cisco) and Tony Li (Juniper) discussed work in the MPLS WG on using RSVP for MPLS traffic engineering (draft-swallow-mpls-rsvp-trafeng-00.txt). This draft suggests adding three new objects to RSVP to exchange label and for explicit routing. It also includes new tunnel CTypes, a new Session Attribute object, and a new RSVP message type for aggregation of label-switched state.
Li talked about the issues with Juniper's experience with RSVP. These include relatively high cpu overhead to process RSVP protocol packets, with a design limit of roughly 10,000 sessions. The current solution for this problem, lowering the refresh rate, can interfere with convergence after route changes. Other suggested approaches include concatenating small RSVP messages into larger datagrams, using digests for messages (as in IS-IS), using TCP for RSVP, or using the reliable-update scheme of Pan, Schulzrinne, and Guerin (draft-pan-rsvp-timer-00.txt). Li noted that using state digests implies that sessions are long lived.
Li asked for input from the RSVP WG on this work, which is originating in the MPLS Working Group. Scott Bradner urged the RSVP WG to look at Li's talk very seriously. The MPLS work is looking not at hijacking RSVP, but making it more useful.
John Wroclawski (MIT) presented an overview of two different contributions on aggregation of RSVP state in the interior of the network: draft-berson-rsvp-aggregation-00.txt and draft-guerin-aggreg-rsvp-00.txt. The main issues in both drafts were the amount of scheduling state and the amount of RSVP control state. The requirements of both drafts were to (1) limit state, (2) deliver the reserved service, (3) maintain flow isolation, and (4) disaggregate. The Guerin draft is more comprehensive in some ways,
including support for both Controlled Load and Guaranteed service; however, it deals only with unicast. The Berson draft is oriented towards Controlled Load and provides multicast support. There was an of whether the measurement-based admission control in the Berson draft could correctly account for new flows.
Liang Li asked how the ingress and egress nodes know that they are the ingress and egress; the ingress is known by configuration, but the egress may be dependent on the destination IP address of the packet.
This work is closely related to the diff-serv work (see later discussion), although no one has brought them together.
D. FRAMEWORK FOR FUTURE RESOURCE MANAGEMENT
Lixia Zhang (UCLA) presented a two-tier framework for resource management. Today's Internet is an interconnection of multiple administrative domains, and all protocol designs must take this basic fact into consideration. Analogous to the inter-domain/intra-domain routing distinction, we must move resource managements towards a two-level control hierarchy. Lixia suggested that each domain will have a Bandwidth Broker (BB) to manage SLAs (service level agreements) with neighbor domains, and they can have the flexibility of selecting among different approaches for intra-domain signaling.
Other ongoing work seems to all fit into this two-tier model. RSVP makes a good intra-domain signaling protocol (as Yoram described in more detail later), and MPLS can also be viewed as another intra-domain
candidate for transit domains (ISP networks).
John Wroclawski noted that the ability to make end-to-end allocation for individual remains useful in many ways. Lixia pointed out that the two-tier framework maintains the ability of adjusting resource
allocation to meet the needs of individual flows, but performs such function in a scalable way through bilateral agreement between Bandwidth Brokers. Steve Berson asked what is the means to achieve
end-to-end resource allocation; it would be achieved through the concatenation of SLAs.
E. RSVP AND DIFF-SERV
Yoram Bernet (Microsoft) and Raj Yavatkar (Intel) discussed drafts draft-ietf-diffserv-rsvp-00.txt and draft-bernet-diffedge-00.txt. Their approach is to use Integrated Service over int-serv clouds and
Differentiated Service (with admission control) over diff-serv clouds, with RSVP doing end-to-end signaling. To do this, mappings from int-serv services to diff-serv services would be needed. There would typically be a default mapping, but the host (or network) may be able to request alternate mappings.
The diff-serv cloud should not set the RSVP service "Break bit" unless it is unable to provide the requested service. Another issue is how to carry RSVP protocol messages transparently across diff-serv networks. There was a discussion of using the Router Alert (RA) option, turning it "off" in the interior of a diff-serv cloud.
There was a discussion of hosts tagging packets for diff-serv. This allows the host itself to implement drop preference, and it makes it easier to use IPSEC (since the transport fields necessary to tag the packet at the first hop router would then be hidden).
John Wroclawski noted that the proposed tagging scheme lets the sender, not the receiver, decide on the service. Bernet answered that the sender knows the characteristics of the traffic, but agreed that it was
an open issue. Tony Li claimed that in two years, 90 percent of Internet traffic will be either tunneled or label-switched. Andrew Smith asked whether new PHB's are needed, but this is an ISSLL WG
No conclusions were reached in this discussion.
RSVP Cryptographic Authentication
User Identity Policy Element
Update on RSVP Diagnostics
MPLS Additions to RSVP
A Two-Tier Model for Internet Resource Management
Review of RSVP/Diffserv
go to list