CURRENT MEETING REPORT

Reported by Daniel Zappala, USC Information Sciences Institute, Bruce Davie, Cisco Systems, and Bob Braden, USC Information Sciences Institute

Minutes of the Resource Reservation Setup Protocol Working Group (RSVP)

Summary

The last technical issues were resolved to move the Version 1 RSVP spec to Proposed Standard. In addition, three auxilary documents were approved for final edit and working group last call: INTEGRITY, IPSEC Support, and Router Alert. The Diagnostic message spec and the RSVP MIB were deferred pending implementation experience.

Agenda -- Monday 4 March Session:

• IPSEC Support: Lou Berger, FORE Systems
• MD5 INTEGRITY object: Fred Baker, Cisco Systems
• Diagnostic message: Lixia Zhang, UCLA
• RSVP Fragmentation

IPSEC Support

Lou Berger made a presentation on an RSVP extension for data traffic that uses IP Security (IPSEC), documented in [draft-ietf-rsvp-ext-02.txt].

The problem: IPSEC headers don't contain TCP/UDP-like ports, and if the packet is encrypted then the ports cannot even be seen, so RSVP can't classify flows. Proposed solution: use the IPSEC SPI in place of ports. It's unstructured, so we can't identify a session by source/dest port. Sessions are identified using a Virtual Destination Port which is not carried in data packets, and the SPI is used as a generalized source port.

One problem with the approach is that all flows with the same protocol and destination address will match a WF reservation. This seems acceptable, given the fact that persons concerned with security would be less likely to use wildcard sender reservations.

The approach requires new filter spec and sender template object types for AH (authentication header) and ESP (encapsulating security payload). Message processing is unchanged.

Some issues raised during discussion included:

• Is it OK to use one CType for both AH and ESP cases, which have the SPI at different offsets? We had previously said that the CType would unambiguously define the format.

• SPIs may change during a session. How is this handled?

• Since the port information is actually visible in the case of AH, should we just use it instead of SPI?

• Should an intermediate header be introduced between the IP header and IPSEC headers, instead? This approach was rejected because it would require changes to IPSEC, which is going to Proposed Standard.

• Is it OK to have different approaches for IPv6 and IPv4?

The rough consensus of the group was to move the proposal ahead to working group last call.

MD5 INTEGRITY Object

Fred Baker of Cisco summarized his draft [draft-ietf-rsvp-md5-02.txt] on the format and useage of the RSVP INTEGRITY object, which allows reservations to be signed across each hop.

The consensus was to move ahead to working group last call.

Diagnostic Message

Lixia Zhang presented the diagnostic message proposal described in [draft-ietf-rsvp-diagnostic-msgs-00.txt].

The goal is to provide a means to determine the path and reservation state along the path from a particular node to a given sender. The message collects collect RSVP state at each hop, using path state for routing. If no path state exists, a user would use traceroute, and then check RSVP state within individual nodes. Information to be collected includes: the state of a reservation, reservation merging, and hop count info for non-RSVP clouds. It is not possible to collect resource availability information, since this is not under RSVP's control.

There are two message types: DREQ (request) and DREP (report). A DREQ can be sent by a 3rd party, and goes from an initial node towards a single sender, picking up the requested information. At any point where it can't go further (e.g., because message has grown too large), the DREQ is converted to a DREP and sent to the requester.

The consensus after discussion was that the proposal looks good in general, but there are a number of detailed issues to be worked out, and we need some implementation experience.

RSVP Fragmentation

There was a discussion of the last open issue to be settled before the Version 1 protocol spec can be submitted for Proposed Standard: how to handle fragmentation of large RSVP messages.

The primary options are:

a) Semantic fragmentation

Each fragment is logically complete. This works the best under packet loss, but it is complex to figure out the details, and some large objects may not be fragmentable.

b) IP fragmentation

There is a 64KB limit on the largest object that can be sent. Loss of any fragment means the entire message must be resent. Concern was expressed about the quality and limitations of existing implementations of IP fragmentation.

c) RSVP fragmentation

Like IP fragmentation, but uses fragmentation fields at the RSVP level - the only advantage over (b) is the removal of the 64k limit.

However, a mixture of these may be used. One mixed case that was considered was using IP fragmentation below 64KB and RSVP fragmentation above 64KB. Another option discussed was to include RSVP fragmentation in the spec but write an AS that says current implementations need not use it.

Fred Baker observed that the 64KB limit is the least of our worries; it's loss and packet queue limits that will kill us, and RSVP fragmentation doesn't fix these.

The consensus was to drop RSVP fragmentation fields from spec, since it doesn't fix the serious problems, and the 64KB limit is unlikely to be a problem in the near future. At the same time, work on the details of semantic fragmentation as the ideal long-term fix.

One issue with semantic fragmentation is that it requires fine-granularity state timeout. Bob Braden pointed out that the current spec specifies a separate timer for each flowspec, but it is ambiguous with regard to timeouts for SE style reservations. There could be a timer for each filter spec, or a timer for the entire list treated atomically.

Agenda -- Wednesday 6 March Session:

• Router Alert
• RSVP Spec updates: Bob Braden, ISI
• RSVP MIB: Fred Baker, Cisco Systems
• Reservations in tunnels: John Krawczyk, BayNetworks o Policy/Access Control Models: Shai Herzog, ISI o RSVP/Routing Interface: Daniel Zappala, ISI

Router Alert

RSVP requires the Router Alert option [draft-katz-router-alert-01.txt] for efficient processing in routers.

The group agreed that the chairs should review this spec and then send it to WG last call.

RSVP Spec Updates

Bob Braden summarized the minor updates required in the RSVP specification before it is sent to last call.

- IP6 intro paragraph

- Fix some typos

- A service preemption can trigger a RESVTEAR message - RSVP may get back an updated flowspec from traffic control - Change common header length field to 24 bits - Clarify updating of SE state; Bob prefers to recommend

that each flowspec has its own timer

- Remove fragmentation fields

The chairs promised to update the spec and send it out for working group last call by Friday March 15. Assuming no major problems are found, it will then be submitted to the IESG for general last call, two weeks later.

RSVP MIB

Fred baker summarized the draft RSVP MIB developed by himself and John Krawczyk [draft-ietf-rsvp-mib-02.txt], which apparently has not been widely read by the group. There was considerable discussion, suggesting that the document needs to be read more widely and commented on.

Some of the issues raised included:

- The draft MIB tracks all PATH and RESV messages received and sent, rather than just reflecting current state. Baker indicated that this info may be needed for some applications, for example an outboard policy server that could preempt reservations.

- Should the RSVP MIB have its own flow/classification table, or should there be an integrated table for all reservation protocols

- Can we make reservations by SNMP (yes), and can we do them at a specified future time (no. This was ruled out of scope by the chair, but it is also addressed in part by the policy work of Shai Herzog - see below).

- Should the RSVP MIB contain service-model dependent objects such as the QoS class, or should that be in the int-serv MIB?

- The MIB should perhaps include counters of `bad' events.

- RSVP tries hard to be easily extensible. Can this be reflected into the MIB, or is every small extension of RSVP going to require revision of the MIB.

The eventual consensus was that publishing this MIB as an Experimental RFC would be acceptable. This will allow further experience with it.

Reservations in Tunnels

John (JJ) Krawczyk presented a detailed proposal for handling RSVP reservations within IP-encapsulating tunnels, developed with Lixia Zhang and John Wroclawski.

The goals of the proposal are to limit the changes to endpoints only, to allow multiple flows per tunnel, and to coexist with current tunneling schemes and RSVP Version 1 routers.

There are two related problems:

• Using the any of the several IP-in-IP encapsulation mechanisms

that already exist, reserved data flows are invisible to intermediate routers inside the tunnel, as the current encapsulation mechanisms do not contain enough information to identify flows.

The proposed solution uses UDP encapsulation of data to provide port information that is accessible to the intermediate routers. Best-effort flows would use the old (IP-only) encapsulation, while reserved flows would use the new UDP encapsulation.

• RSVP control messages are also invisible within the tunnel.

The solution here is to apply RVSP "recursively" between the tunnel endpoints. Thus, new PATH messages need to be sent to intermediate routers, while the original PATH messages go "through" the tunnel.

JJ proposes using an `ignore and forward if unknown' object type to associate the tunneled path message with the hop-by-hop message. A similar approach would be used for reservation messages. There are some complications that arise since we may multiplex multiple flows onto a single tunnel reservation.

Some issues were:

- Security: it's easy to spoof the encapsulation header, and this can't be detected until the exit of the tunnel. Therefore the attacker can consume tunnel resources.

- Fragmentation and MTU discovery

Although we just solve the single case of DVMRP tunnels by peeking at the information inside the encapsulating header, there was a desire for a more general solution.

Zhang, Krawczyk, Baker, and Wroclawski agreed to produce the document.

Policy/Access Control Models

Shai Herzog presented his work on policy [ftp://ftp.isi.edu/rsvp/docs/lpm-doc.ps.Z, .txt]. This work aims to address the need to control usage and provide user feedback when special QoS is granted to a flow.

Policies are complex, local and dynamic. They should not be part of RSVP spec (or even necessarily located in the forwarding path). His work is based on three principles aiming to provide scalability:

- Bilateral agreements

- No global information or agreements

- Policies are controlled & configured locally

The implementation abstraction is the local policy module (LPM), a common layer above RSVP that receives and generates policy data objects. The LPM talks to several handlers for different policies. e.g. one handler may determine `how much does this cost?', another may determine `who gets charged?'. He has defined formats for POLICY objects, which may or may not include embedded INTEGRITY objects.

In his approach, the RSVP spec itself needs the following extensions:

- A new RESV Report message

- Changes to API

- LPM interface

- Default handling for POLICY_DATA objects

Herzog will submit two Internet Drafts, for further discussion on the mailing list.

RSVP/Routing Interface

Daniel Zappala presented a review of the current interface between RSVP and routing. He then described an extension to it to provide support for shared trees (e.g, PIM, CBT). An Internet Draft is in progress.