HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:28:54 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 01 Jul 1996 22:21:00 GMT ETag: "2f51db-7733-31d84f4c" Accept-Ranges: bytes Content-Length: 30515 Connection: close Content-Type: text/plain Internet Draft Lixia Zhang Expiration: December 1996 UCLA File: draft-ietf-rsvp-diagnostic-msgs-01.txt June, 1996 RSVP Diagnostic Messages Status of Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This draft describes the RSVP diagnosis facility. As the deployment of RSVP is spreading out, it has become clear that a method for collecting information about the RSVP state along the path is needed. This specification describes the required functionality, packet format, and processing rules. 1. Introduction In the original design of RSVP, error messages are the only means for the end hosts to receive feedback information regarding a specific request that has failed, a failure in setting up either a PATH state or reservation state. In the absence of failures, one receives no feedback regarding the details of a reservation that has been put in place, such as whether, or where, or how, one's own reservation request is merged with that of others. In case of a failure, the error message carries back only the information from the failed point, without any information about the state at other hops before or after the failure. Such missing information, however, can be highly desirable for debugging purpose, or may even be interesting to end applications. In this memo we specify an RSVP diagnostic facility to collect information of RSVP state along the path from a receiver to a specific sender. Diagnostic messages are independent from any other RSVP control messages and produce no side-effects. That is, they do not change any RSVP state at either routers or hosts. A diagnostic reply is not an error report, but a collection of requested RSVP state information. We have the following design goals in mind: - To be able to collect RSVP state information at every hop along the path once the PATH state has been set up, either for an existing reservation or before a reservation request is made; here the "hop" means RSVP-capable routers. More specifically, we want to be able to collect information about flowspec, refresh timer values, and reservation merging at each hop along the path. - To be able to collect the routing hop count for each non-RSVP cloud the path crosses. - To avoid diagnostic packet implosion or explosion. The following are specifically identified as non-goals: - Checking the resource availability along a path. Such functionality may be useful for future reservation requests, but would require modifications to existing admission control module which is beyond the scope of RSVP. 2. Overview We define two types of diagnostic packets, diagnostic request (DREQ) and reply (DREP). To avoid packet implosion or explosion, we restrict all diagnostic packets to be unicast only (but see Section 5.2 on crossing firewalls). If the requesting host is at the receiving end of the delivery path that is to be queried, it sends a DREQ packet to the last-hop router of the path. If the requester is not a receiving host, it simply sends the DREQ packet to some router on the path. The DREQ packet specifies the RSVP session and a sending host to that session. The router receiving the request adds to the DREQ packet a response data object containing its RSVP state for the specified RSVP session, and then forwards the request via unicast to the router that it believes is the proper previous hop for the given source. Each subsequent hop attaches its own response data object to the end of the DREQ packet, then unicast-forwards to the previous hop. When the DREQ packet reaches the sender, the sender changes the packet type to Diagnostic Reply (DREP) and sends the completed response to the original requester. The response may also be returned before reaching the sender if any error condition along the path, such as "no path state", prevents further forwarding of the request packet. DREP packets can be unicast back to the requester either directly, or in a hop-by-hop manner by reversing the exact path that the DREQ packet has taken. The former is faster and more efficient, but the latter may be the only choice if the packets have to cross firewalls. To facilitate the latter case, a DREQ packet may optionally carry a ROUTE object, which is a list of router addresses that the DREQ packet has passed through on the way to the sender; this ROUTE object is built incrementally as the DREQ packet passes through the intermediate routers. The DREP packet can then be returned to the requester by reversing the path. When the path consists of many hops, it is possible that the total length of a DREP packet will exceed the path MTU size before reaching the sender, thus the packet has to be fragmented. Relying on IP fragmentation and reassembly, however, can be troublesome, especially when DREP packets are returned to the requester hop-by-hop, in which case fragmentation/reassembly would have to be performed at each hop. To avoid such excessive overhead, we let the requester define a default path MTU size which is carried in every DREQ packet. If an intermediate router believes that the default MTU size is too big, it returns the DREQ packet with corresponding error bit set. If an intermediate router detects that a DREQ packet size reaches the MTU size, it trims off the partial result and returns it to the requester, then forwards the trimmed DREQ packet to the next hop towards the sender. Through out this memo we use the word "DREQ packet", rather the word "message" to call a diagnostic request since it always consists of a single packet. On the other hand, one DREQ packet can generate multiple DREP packets, each containing a fragment of the total reply. Notice that one can forward DREQ packets only after the RSVP PATH state has been set up. If no PATH state exists, one may resort to the traceroute facility to examine whether the unicast/multicast routing is working correctly. 3. Diagnostic Packet Format A diagnostic packet consists of the following parts: +-----------------------------------+ | RSVP common header | +-----------------------------------+ | Diagnostic packet header object | +-----------------------------------+ | session object | +-----------------------------------+ | (optional) route object | +-----------------------------------+ | one or more Response Object | +-----------------------------------+ 3.1 RSVP Message Common Header In the RSVP message common header, 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | Flags| Type | RSVP Checksum | +-------------+-------------+-------------+-------------+ | Send_TTL | reserved | RSVP Length | +-------------+-------------+-------------+-------------+ | Message ID | +-------------+-------------+-------------+-------------+ The Flags field is unused for now and must be set to zero. Type = 8: DREQ Type = 9: DREP RSVP Checksum covers the entire packet body including this header. Send_TTL: the IP TTL value that a router puts in the IP header when forwarding the DREQ packet to the previous hop. RSVP length: the total length of this diagnostic packet in bytes, including the common header. If this is a DREP packet and the MF flag in diagnostic packet header (see below) is set, this length field indicate the length of this single DREP fragment, rather than the total length of the the complete DREP reply (which may not be known in advance). Message ID identifies an individual DREQ packet and corresponding reply (or all the fragments of the reply). 3.2 RSVP Diagnostic Packet Header Object Both DREQ and DREP headers are a concatenation of Diagnostic Packet Header Object and an RSVP Session object, as defined below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | class | c-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-RSVP-hops | RSVP-hop-count| multicast TTL | Reserved |H|MF| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | path MTU | Fragment offset | +---------------+---------------+---------------+---------------+ | Sender Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAST-HOP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response Address | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | + RSVP Session Object | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length is the length of this diagnostic header object. Class = 30. C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 (Ctype = 2). Max-RSVP-hops specifies the maximum number of RSVP hops that the requester wants to collect information from. In case an error condition in the middle of the path prevents the DREQ packet from reaching the specified sender, one may use this field to perform an expanding-length search to reach the point just before the problem. RSVP-hop-count field records the number of RSVP hops that have been traversed so far. Multicast TTL is used to limit the multicast scope when the response address is a multicast address; see Section 5.2 for more details. Otherwise this field must be set to zero. The H flag indicates how the reply should be returned. When H = 0 and the response address is a unicast address, DREP packets should be sent to the response address directly via unicast; otherwise DREP packets are sent to the LAST-HOP address. If H = 0 and the response address is a multicast address, DREP packets should be sent to the LAST-HOP address via unicast. If H = 1, DREP packets must be returned to the LAST-HOP address in a hop-by-hop way. The node specified by the LAST-HOP address then forwards DREP packets to the response address. The MF flag means "more fragment". It must be set to zero in all DREQ packets. All DREP packets that are returned by intermediate routers rather than the sender must set the MF flag to 1; when the sender converts a DREQ packet to a DREP, the MF flag remains zero. The path MTU is a 16-bit field that specifies a default MTU size for diagnostic packets. Sender address is the IP address of the sender for the RSVP path being traced. The DREQ packet proceeds hop-by-hop towards this address. LAST-HOP address is the IP address of the last hop at the receiving end for the path being traced. The DREQ packet starts collecting information at this node and proceeds toward the sender. Response Address is the address to which the DREP packet(s) should be sent. This Response Address does not necessarily specify the node that initiates the DREQ packet, although most often it would. The session object identifies the RSVP session for which the state information is being collected. Optionally, the diagnostic packet header may also contain a ROUTE object, as defined below, immediately after the Session object. The ROUTE object is to be used to return DREP packets hop-by-hop. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | class | c-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | R-pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + List of RSVP routers | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length field represents the total length of the object in number of bytes, from which the number of addresses in the RSVP router list can be easily computed. Class = 31. C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 (Ctype = 2) ROUTE object. R-pointer is used in DREP packets only (see Section 4.2 for details), and must be set to zero in all DREQ packets. In a DREQ packet, List of RSVP routers lists all the RSVP hops between the LAST-HOP address, as specified in the Diagnostic packet header object, and the last RSVP router the DREQ packet has visited. In a DREP packet, List of RSVP routers lists all the RSVP hops between the LAST-HOP and the router that returns this DREP packet. 3.3 Response Data Object When receiving a DREQ packet, each RSVP router attaches a "response data" object to it before forwarding on. The response data object is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | class | C-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DREQ Arrival Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous-RSVP-Hop Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reservation style | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D-TTL |M|R-error| K | timer value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tspec object | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | filter spec object | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | flowspec object | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class = 32. Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data, respectively. DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival time of the DREQ packet at this router. The 32-bit form of an NTP timestamp consists of the middle 32 bits of the full 64-bit form; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. Incoming Interface Address specifies the IP address of the interface on which packets from the sender, as defined in the Diagnostic Packet Header, are expected to arrive, or 0 if unknown. Outgoing Interface Address specifies the IP address of the interface from which the DREQ packet comes, and to which packets from the given sender and for the specified session address flow, or 0 if unknown. Previous-RSVP-Hop Router Address specifies the router from which this router receives RSVP PATH messages from this source, or 0 if unknown. Notice that the response object format as shown above assumes IPv4 addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2), these three addresses will be 16 bytes each. Reservation style is the 4-byte value of RSVP Style Object as defined in RSVP specification. D-TTL contains the routing hop count this DREQ packet traveled from the down-stream RSVP router to the current router. M is a single-bit flag which indicates whether the reservation, as described by the objects below, is merged with reservations from other downstream interfaces when being forwarded upstream. R-error is a 7-bit field that indicates error conditions at a router. Currently defined values are 0x00: no error 0x01: no PATH state 0x02: MTU too big 0x04: ROUTE object too big K is the refresh timer parameter defined in RSVP, and timer value is the local refresh timer value in second. The remaining parts, Tspec, filter spec, and flowspec objects follow the definitions given in RSVP specification. The latter two may be absent (see Section 4.1 on DREQ forwarding). 4. Diagnostic Packet Forwarding Rules 4.1 DREQ Packet Forwarding DREQ packets are forwarded via hop-by-hop unicast from the LAST-HOP address to the Source address as specified in the diagnostic packet header. Each hop performs the following processing before forwarding the packet to the next hop towards the sender: 1 Compute the routing hop count from the previous RSVP hop. This is done by subtracting the value of the TTL value in the IP header from Send_TTL in RSVP common header. The result is then saved in the D-TTL field of the response data object. 2 If no PATH state exists for the specified session, set R-error = 0x01 in the Response Data object. 3 If the path MTU value is too large, set "MTU too large" error bit, and change the MTU value to the MTU value of the current router. 4 Attach the response data object to the end of the DREQ packet. Tspec, filter spec, and flowspec objects in the response object describe the reservation in place at the Outgoing Interface for the specified session. If no reservation state exists for the specified RSVP session, the response object will contain no filter-spec or flowspec object; it should still include the Tspec object for the specified sender that has been carried to the router in the sender's PATH messages. If neither PATH nor reservation state exists for the specified RSVP session, then the response object contains none of the Tspec, filter or flow spec object. 5 Increase the packet length field in the RSVP common header accordingly. 6 If any error bit is set, change the type field in RSVP common header from DREQ to DREP, and send the packet back to either the LAST-HOP address (if H = 1, or response address is a multicast address), or to the response address directly via unicast (if H = 0). 7 Increment the RSVP-hop-count field in the diagnostic packet header by one. If the resulting value is equal to that of Max-RSVP-hops, or if the current hop is the sender as identified by the "Source Address" in the RSVP diagnostic header, go to Send_DREP(), and then return. 8 If the resulting DREQ packet size exceeds the MTU limit, minus some margin to hold the address list object as described below, go to Send_DREP(). 9 if no error bit set, forward the DREQ packet to the next hop towards the source. Send_DREP(): 1. If the H flag in the Diagnostic Header header is off, set target=response address given in the DREQ header, goto Step-5. 2. Otherwise create a ROUTE Object (as defined in Section 3.2.2), Rnew. R-pointer value is set to the number of response objects in the DREQ packet. The list of RSVP routers is filled by taking the "Incoming Interface Address" from each of the response objects. The resulting list of routers is in the order in which the DREQ packet has visited them. The DREP packet will traverse through the routers in the reverse order. 3. If the DREQ packet already contains a Router Object, Rold, merge Rnew with Rold by adding the R-pointer in Rnew to that in Rold, and attach the Router list of Rnew to the end of that in Rold. 4. Insert the resulting Route object from Steps 2 & 3 between Session object and the first response data block. set target = the last address in ROUTE 5. Make a copy of the resulting DREQ packet, change the type field in RSVP common header from DREQ to DREP, and send the packet to target via unicast. If the ROUTE object is so large such that (size of ROUTE + 2 * size of response data object) > path MTU, set the "route too big" error bit, send the packet, and go to 7. 6. Trim off all the response data objects from the original DREQ packet, and adjust the "Fragment offset" value in the RSVP common header accordingly. 7. Return. 4.2 DREP Forwarding When the H flag is off, DREP packets are sent directly to the original requester. When H flag is on, however, they are forwarded hop-by-hop to the requester, by reversing the route as listed in the Route object. When a router receives a DREP packet, it simply decreases R-pointer by one (address length), and forward the packet to the address pointed by R-pointer in the route list. When the LAST-HOP router receives a DREP packet, it sends the packet to the Response address. 4.3 MTU Selection and Adjustment Because the DREQ packet carries the allowed MTU size of previous hops that the DREP packets will later traverse, this unique feature allows the easy semantic fragmentation as described above. Whenever the DREQ packet grows to approach the size of MTU, it can be trimmed before being forwarded again. When a requester sends a DREQ packet, the path MTU field in the RSVP Diagnostic Packet header can be set to a configured default value. Whenever a DREQ packet size approaches the specified MTU value, an intermediate RSVP router makes a copy of the packet, converts it to a DREP packet to send back, and then trims off the partial results from DREQ packet and forwards it. It is possible that the original MTU value is chosen larger than the actual MTU value along some portion of the path being traced. Therefore each intermediate RSVP router must check the MTU value when processing a DREQ packet. If the specified MTU value is larger than the MTU of the incoming interface (that the DREQ packet will be forwarded to), the router (1) sets the R-error value, (2) changes the MTU value in the header to the smaller value, and (3) converts the DREQ packet to a DREP and sends it back to the requester. In rare case that some intermediate routers do not check, or enforce upon, the MTU value carried in the diagnostic packets, it is possible that on the way back to the requester, a DREP packet may encounter a link of smaller MTU. When this happens, the router follows steps (1) and (2) as outlined above, and trims off the extra part of the DREP packet to fit in the smaller MTU of the link. The trimming must be done at response object boundaries. Such trimming of packets results in information loss. However because the requester learns what is the available MTU size, it can either ignore the loss, or otherwise try again with the smaller MTU value. 4.4 Errors If an error condition prevents a DREP packet from being forwarded further, the packet is simply dropped. If an error condition, such as lack of PATH state, prevents a DREQ packet from being forwarded further, the router must change the current packet to DREP type and return it to the response address. 5. Problem Diagnosis by Using RSVP Diagnostic Facility 5.1 Broken Intermediate Router A broken (or legacy) intermediate RSVP router may simply not understand diagnostic packets, and drop them. The querier would then get no response at all from its requests. It may then choose to first do a multicast traceroute (in case of multicast) to get information about the route length, and then perform an RSVP diagnosis search by gradually increasing the value of M_TTL field until it no longer receives a response. 5.2 Across Firewalls Firewalls can cause problems in diagnostic packet forwarding. Let us look at two different cases. First, let us assume that the querier is a receiving host of the session to be examined. In this case, firewalls should not prevent the forwarding of the diagnostic packets in a hop-by-hop manner, assuming that proper holes have been punched on the firewall to allow hop-by-hop forwarding of other RSVP packets. The querier may start by setting the H flag off, which can give a faster response delivery and reduced overhead at intermediate routers. However if no response is received, the querier may resend the DREQ packet with H flag turned on. If the requester is a third party host and is separated from the LAST-HOP address by a firewall (either the requester is behind a firewall, or the LAST-HOP is a router behind a firewall, or both), at this time I do not know any other solution but attempting to use multicast. To send a DREQ packet across a firewall (or firewalls), the request should be multicast to the group being examined (since the last hop router listens to that group). All routers except the correct last hop router, as identified by the LAST-HOP address in the DREQ header, should ignore any DREQ request received via multicast. To receive a DREP packet across a firewall (or firewalls), the querier should set the response address to a well-known multicast address allocated specifically for DREP packets. In this case, all the reply packets will be first unicast to the LAST-HOP address specified in the diagnostic header, which in turn multicasts them out with a scope as specified by the multicast TTL value in the Diagnostic Packet Header Object. This multicast TTL scope should be set to a value sufficient for the response from the LAST-HOP router to reach the querier. However we must also carefully limit this value to a small number, because there is only one well-known multicast address for this purpose, therefore all the queriers from all other sessions will receive the multicast DREP packets as well. If the querier still cannot receive the DREP packet when the TTL reaches the limit, then one must consider using a node closer to the LAST-HOP address instead. 5.3 Examination of RSVP Timers One can easily collect information about the current timer value at each RSVP hop along the way. This will be very helpful in situations when the reservation state goes up and down frequently, to find out whether the state changes are due to improper setting of timer values, or K values (when across lossy links), or frequent routing changes. 5.3 Discovering Non-RSVP Clouds The D-TTL field in each response data block shows the number of routing hops between adjacent RSVP routers. Therefore any value greater than one indicates a non-RSVP clouds in between. Together with the arrival timestamps (assuming NTP works), this value can also give some vague, though not necessarily accurate, indication of how big that cloud might be. One might also find out all the intermediate non-RSVP routers by running either unicast or multicast trace route. 5.4 Discovering Reservation Merges The flowspec value in a response data block specifies the amount of resources (whatever that means by the yet to be defined flowspec) being reserved for the data stream defined by the filter spec in the same data block. When this value of adjacent response data blocks differs, that is, a downstream router Rd has a smaller value than its immediate upstream router Ru, it indicates a merge of reservation with RSVP request(s) from other down stream interface(s) at Rd. Further, in case of SE style reservation, one can examine how the different SE scopes get merged at each hop. In particular, if a receiver sends a DREQ packet before sending its own reservation, it can discover (1)how many RSVP hops there are along the path between the specified source and itself, (2)how many of the hops already have some reservation by other receivers, and (3)possibly foresee how its reservation request might get merged with other existing ones. 5.5 Error Diagnosis In addition to examining the state of a working reservation, RSVP diagnostic packets are more likely to be invoked when things are not working correctly. For example, a receiver has reserved an adequate pipe for a specified incoming data stream, yet the observed delay or loss ratio is much higher than expected. In this case the receiver can use the diagnostic facility to examine the reservation state at each RSVP hop along the way to find out whether the RSVP state is set up correctly, whether there is any blackhole along the way, or whether there are non-RSVP clouds, and where, that may have caused the performance problem. 6. Further Work A missing piece from the current design is the handling of diagnostic packets across routers that are RSVP-capable but do not support RSVP diagnostic messages. 7. Acknowledgment The idea of developing a diagnostic facility for RSVP was first proposed by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox PARC and John Krawczyk of Baynetworks for their valuable comments on the first draft of this memo. Lee and Bob Braden contributed further comments after the LA IETF, and John Krawczyk caught a number of errors just prior to this post. Authors' Addresses Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90024 Phone: 310-825-2695 EMail: lixia@cs.ucla.edu