idnits 2.17.1 draft-ietf-rsvp-diagnostic-msgs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 548 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1996) is 10115 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lixia Zhang, UCLA 2 Expiration: August 1996 3 File: draft-ietf-rsvp-diagnostic-msgs-00.txt 5 RSVP Diagnostic Messages 7 Status of Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as "work in progress." 19 To learn the current status of any Internet-Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 Abstract 27 This draft describes the RSVP diagnosis facility. As 28 the deployment of RSVP has spread, it has become clear that 29 a method for collecting information about the RSVP state along 30 the way from a receiver to a particular source is needed. 31 This specification describes the required functionality, packet 32 format, and processing rules. 34 1. Introduction 36 In the original design of RSVP, error messages are the only means for 37 the end hosts to receive feedback information regarding a specific 38 request that has failed, a failure in setting up either a PATH state 39 or reservation state. In absence of a failure, one receives no 40 feedback regarding the details of a reservation that has been put in 41 place, such as whether, or where, or how, one's own reservation 42 request is merged with that of others. In case of a failure, the 43 error message carries back only the information from the failed point, 44 without any information about the state at other hops before the 45 failure. Such missing information, however, can be highly desirable 46 for debugging purpose, or even be interesting to end applications. 48 In this memo we specify an RSVP diagnostic facility to collect 49 information of RSVP state along the path from a receiver to a specific 50 sender. Diagnostic messages are independent from any other RSVP 51 control messages and are side-effect free. That is, they do not change 52 any RSVP state at either routers or hosts. A diagnostic reply is not 53 an error report, but a collection of RSVP state information as 54 requested. 56 We have the following design goals in mind: 57 - To be able to collect RSVP state information at every hop along the 58 path once the PATH state has been set up, either for an existing 59 reservation or before one has made any reservation request. 60 - More specifically, to be able to collect information about flowspec, 61 timer values, and reservation merging at each hop along the path. 62 - To be able to collect hop count for each non-RSVP cloud the path 63 crosses. 64 - To avoid packet implosion or explosion. 65 Here the "hop" is defined as RSVP-capable routers. 67 The following are specifically identified as non-goals for the time 68 being: 69 - Checking the resource availability along a path. Such functionality 70 may be useful for future reservation requests, but would require 71 modifications to existing admission control module which is beyond 72 our control. 74 2. Overview 76 We define two types of diagnostic packets, diagnostic request (DREQ) 77 and reply (DREP). To avoid packet implosion or explosion, we restrict 78 diagnostic packets to unicast only (but see Section 5.2 on firewall 79 issues). The requesting host is not necessarily have the 80 receiving end of the delivery path that is to be queried. The 81 requester simply sends an RSVP Diagnostic request packet (DREQ) to 82 the last-hop router of the path. The DREQ packet specifies the RSVP 83 session and a sender host to that session. The last-hop router adds 84 to the DREQ packet a response data block containing its RSVP state 85 for the specified RSVP session, and then forwards the request via 86 unicast to the router that it believes is the proper previous hop for 87 the given source. Each subsequent hop adds its own response data to 88 the end of the request packet, then unicast forwards to the previous 89 hop. When the DREQ packet reaches the sender, the sender then changes 90 the packet type to Diagnostic Reply (DREP) and sends the completed 91 response to the original requester. The response may also be returned 92 before reaching the sender if any error condition along the path, such 93 as "no path state", prevents further forwarding of the request packet. 95 DREP packets can be unicast back to the requester either directly, or 96 in a hop-by-hop manner by reversing the exact path that the DREQ 97 packet has taken. The former is faster and more efficient, but the 98 latter may be needed when the packets have to go across firewalls. To 99 facilitate the latter case, DREQ packet may carry an optional ROUTING 100 object, which is a list of router addresses that the packet has passed 101 through on the way to the sender. The DREP packet can then be 102 returned to the requester by revering the path. 104 When the path consists many hops, it is possible that the total length 105 of a DREP packet will exceed the path MTU size and the packet has to 106 be fragmented. Relying on IP fragmentation and reassembly, however, 107 is troublesome, especially when DREP packets are returned to the 108 requester hop-by-hop, in which case fragmentation/reassembly would 109 have to be performed at each hop. To avoid such excessive overhead, 110 We propose to define a default MTU value, and once an intermediate 111 router detects that a DREQ packet size reaches the pre-defined MTU 112 size, it returns the partial result to the requester, and then 113 forwards the trimmed DREQ packet to the next hop towards the sender. 114 Therefore through out this memo we use the word "DREQ packet", rather 115 the word "message" to call a diagnostic request which always consists 116 of a single packet. On the other hand, one diagnostic request can 117 generate multiple DREP packets, each containing a fragment of the 118 total reply. 120 Notice that one can forward DREQ packets only after the path state has 121 been set up. Otherwise one may resort back to the traceroute 122 facility to examine whether the unicast/multicast routing is working 123 correctly. 125 3. DREQ / DREP Packet Format 127 A diagnostic packet consists of three parts: the RSVP common header, 128 diagnostic packet header, and response data object. 130 3.1 RSVP Message Common Header 132 In the RSVP message common header, 134 0 1 2 3 135 +-------------+-------------+-------------+-------------+ 136 | Vers | Flags| Type | RSVP Checksum | 137 +-------------+-------------+-------------+-------------+ 138 | RSVP Length | reserved | Send_TTL | 139 +-------------+-------------+-------------+-------------+ 140 | Message ID | 141 +--------+-+--+-------------+-------------+-------------+ 142 |Resved |MF| Fragment offset | 143 +--------+-+--+-------------+-------------+-------------+ 145 Flags field is unused for now. 147 Type = 8: DREQ 148 Type = 9: DREP 150 RSVP Checksum covers the entire packet body including this header. 152 Send_TTL holds IP TTL value that a router puts in the IP header when a 153 DREQ packet is forwarded to the previous hop. 155 Message ID identifies an individual DREQ packet and corresponding 156 reply (or all the fragments of the reply). 158 MF flag is on for all but the last packet (fragment) in a Diagnostic Reply. 160 Fragment Offset field gives the byte offset of the current fragment 161 in the complete Diagnostic Reply. 163 3.2 RSVP Diagnostic Packet Header Object 165 Both the DREQ/DREP header is a concatenation of Diagnostic Packet 166 Header Object and an RSVP Session object, as defined below: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | length = 20 | class | c-type | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | M-TTL | hop-count | Error code | XXXX | |H| 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Source Address | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Destination Address | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Response Address | 180 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 181 | | 182 + RSVP Session Object | 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Class field is unused for the moment and must be set to zero. 188 C-type is used to distinguish IPv4 and IPv6. 190 M-TTL specifies the maximum number of hops that the requester 191 wants to collect information for. In case that some error condition in 192 the middle of the path keeps the DREQ packet from reaching the 193 specified sender, this field can be used to perform an 194 expanding-length search to reach the point just before the problem. 196 Hop-count field records the number of RSVP hops that have been 197 traversed so far. 199 Error code expresses the errors encountered that prevented DREQ from 200 reaching the source. Currently defined values are 201 0x00: no error 202 0x01: lack of PATH state 204 A possible use of the 4 bit value XXXX is discussed in Section 5.2 205 when the "Response Address" is a multicast address. Otherwise the 206 value is 0. 208 H flag indicates how the reply should be returned to the requester. 209 When H = 0, DREP packets should be sent to the requester directly via 210 unicast; when H = 1, DREP packets should be returned to the request 211 in a hop-by-hop way. 213 Source address specifies the IP address of the source for the 214 path being traced. The DREQ packet proceeds hop-by-hop towards this 215 source. 217 Destination address field specifies the IP address of the receiving 218 end for the path being traced. The DREQ packet starts at this node 219 and proceeds toward the source. 221 Response Address field specifies the address to which the DREP 222 packet(s) gets sent. 224 The session object identifies the session for which the RSVP state 225 information is being collected. 227 Optionally, the packet header may also contain a ROUTE Object, as 228 defined below, right after the Session object (to be used to return 229 DREP packets hop-by-hop) 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | length | class | R-pointer | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 + List of RSVP routers | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Length field represents the total length of the object in number of 240 bytes, from which the number of addresses in the router list can be 241 easily computed. 243 R-pointer is used in DREP packets only (see Section 4.2), and must be 244 zero in all DREQ packets. (notice that this is a violation of the 245 common object format defined in RSVP spec) 247 List of RSVP routers lists all the RSVP hops between the Destination 248 and the router that returns this DREP packet in a DREP packet, or the 249 last router that has updated this list in a DREQ packet. 251 3.3 Response Data 253 Each RSVP router adds a "response data" segment to the DREQ packet 254 before it forwards it on. The response data looks like this: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | length | class | C-type | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | DREQ Arrival Time | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Incoming Interface Address | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Outgoing Interface Address | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Previous-RSVP-Hop Router Address | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | reservation style | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | D-TTL |M|R-error| K | timer value | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | Tspec object | 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 | filter spec object | 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 | flowspec object | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival 287 time of the DREQ packet at this router. The 32-bit form of an NTP 288 timestamp consists of the middle 32 bits of the full 64-bit form; that 289 is, the low 16 bits of the integer part and the high 16 bits of the 290 fractional part. 292 Incoming Interface Address specifies the address of the interface on 293 which packets from this source are expected to arrive, or 0 if 294 unknown. 296 Outgoing Interface Address specifies the address of the interface on 297 which packets from this source flow to the specified destination, or 0 298 if unknown. 300 Previous-RSVP-Hop Router Address specifies the router from which this 301 router receives PATH packets from this source, or 0 if unknown. 303 Reservation style is the 4 byte value of RSVP Style Object as defined in 304 RSVP specification. 306 D-TTL specifies the hop count this DREQ packet traveled from the 307 down-stream RSVP router to the current router. 309 M-flag indicates whether the reservation, as described by the objects 310 below, is merged with reservations from other downstream interfaces 311 when being forwarded upstream. 313 R-error indicates error conditions at a router. Currently defined 314 values are 315 0x00: no error 316 0x01: no reservation 318 K is the parameter defined in RSVP, and timer value is the local 319 refresh timer value in second. 321 The rest parts, Tspec, filter spec, and flowspec objects follow the 322 definitions given in RSVP specification. The latter two may be absent 323 (see Section 4.1 on DERQ forwarding). 325 4. Diagnostic Packet Forwarding Rules 327 4.1 DREQ Forwarding 329 DREQ packets are forwarded hop-by-hop via unicast from the destination 330 address to the source address as specified in the diagnostic packet 331 header. 333 Each hop carries out the following processing before forwarding the 334 packet to the next hop towards the source: 335 - Compute the routing hop count from the previous RSVP hop. 336 This is done by comparing the value of Send_TTL with the TTL value 337 in the IP header. The result is then put into the D-TTL field of 338 the response data. 339 - Attach its response data block to the end of the DREQ packet. 340 Tspec, filter spec, and flowspec objects in the data block describe 341 the reservation in place at the Outgoing Interface for the specified 342 session. 343 If there is no reservation state, then the response data block will 344 contain no filter-spec or flowspec; it should still have the Tspec 345 value for the specified sender that has been carried to the router 346 by PATH messages. 347 - increment hop-count by one. 348 - If the hop-count value is equal to that of M-TTL, or if the current 349 hop is the sender as identified by the "Source Address" in the RSVP 350 diagnostic header, go to Send_DREP(), and then return. 351 - If the resulting DREQ packet size exceeds a pre-defined MTU limit 352 (minus some margin to hold the address list, see blow), go to 353 Send_DREP(). 354 - Count the number or response data blocks, N, increase the "Fragment 355 offset" value in RSVP common header by (24N + N X M)). 356 (Section 3.3 defines the first 24 bytes in the response block, M is 357 the length of Tspec + Filterspec + Flowspec) 358 - Trim off all the response data blocks from the original DREQ 359 packet, then forward to the next hop towards the source. 361 Send_DREP(): 362 1. If the H flag in the Diagnostic Header header is off, 363 o Make a copy of the packet, change the packet type from DREQ to 364 DREP, and send it to the response address given in the DREQ 365 header.*** 366 o Return. 368 2. Create a ROUTE Object (as defined in Section 3.2.2), Rnew. 369 R-pointer value is filled by counting the number of response 370 data blocks in the DREQ packet. The list of RSVP routers is 371 filled by taking the "Incoming Interface Address" from each of the 372 response data block. 374 3. If the DREQ packet already contains a Router Object, Rold, merge 375 Rnew with Rold by adding the R-point in Rnew to that in Rold, and 376 attach the Router list of Rnew to the end of that in Rold. 378 4. Insert the resulting Route object from Steps 2 & 3 between 379 Session object and the first response data block. 381 5. Make a copy of the resulting DREQ packet, change the packet type 382 from DREQ to DREP, and send the packet to the last address in ROUTE 383 object. 385 6. Return. 387 4.2 DREP Forwarding 389 When the H flag is off, DREP packets are sent directly to the original 390 requester. When H flag is on, however, they are forwarded hop-by-hop 391 to the requester, by reversing the route as listed in the Route object. 393 When a router receives a DREP packet, it simply decreases R-pointer by 394 one (address length), and forward the packet to the address pointed by 395 R-pointer in the route list. 397 When the destination router receives a DREP packet, it sends the 398 packet to the Response address. 400 4.3 Errors 402 If an error condition prevents a DREP packet from being forwarded 403 further, the packet is simply dropped. 405 If an error condition, such as lack of PATH state, prevents a DREQ 406 packet from being forwarded further, the router must change the 407 current packet to DREP type and return it to the response address. 409 5. Problem Diagnosis by Using RSVP Diagnostic Facility 411 5.1 Broken Intermediate Router 413 A broken (or legacy) intermediate RSVP router may simply not 414 understand diagnostic packets, and drop them. The querier would then 415 get no response at all from its requests. It may then choose to first 416 do a multicast traceroute (in case of multicast) to get information 417 about the route length, and then perform an RSVP diagnosis search 418 by gradually increasing the value of M_TTL field until it no longer 419 receives a response. 421 5.2 Across Firewalls 423 Firewalls can cause problems in diagnostic packet forwarding. Let us 424 look at two different cases. 426 First, let us assume that the querier is a receiving host of the 427 session to be examined. In this case, firewalls should not prevent 428 the forwarding of the diagnostic packets in a hop-by-hop manner, 429 assuming that proper holes have been punched on the firewall to allow 430 hop-by-hop forwarding of other RSVP packets. The querier may start by 431 setting the H flag off, which can give a faster response delivery and 432 reduced overhead at intermediate routers. However if no response is 433 received, the querier may resend the DREQ packet with H flag turned 434 on. 436 If the requester is a third party host and is separated from the 437 destination address by a firewall (either the requester is behind a 438 firewall, or the destination is a router behind a firewall, or even 439 both), at this time I do not know any other solution but attempting to 440 use multicast. 442 To send a DREQ packet across a firewall (or firewalls), the request 443 should be multicast to the group being examined (since the last hop 444 router listens to that group). All routers except the correct last 445 hop router, as identified by the destination address in the DREQ 446 header, should ignore any DREQ request received via multicast. 448 To receive a DREP packet across a firewall (or firewalls), the querier 449 should set the response address to a wellknown multicast address 450 allocated specifically for DREP packets. In this case, all the reply 451 packets will be first unicast to the destination address, which in 452 turn multicasts them out, with the TTL value specified in the XXXX 453 field in the diagnostic header. This response TTL should be set to a 454 value sufficient for the response from the destination router to reach 455 the querier. However we choose to physically limit this value to be 456 no more than 15, because there is only one wellknown multicast 457 address for this purpose, therefore all the queriers from all other 458 sessions will receive the multicast DREP packets as well. If the 459 querier still cannot receive the DREP packet when the TTL reaches the 460 limit, then one must consider using a node closer to the destination 461 instead. 463 5.3 Examination of RSVP Timers 465 One easily collects information about the current timer value at each 466 RSVP hop along the way. This will be very helpful in situations when 467 the reservation state goes up and down frequently, to find out whether 468 the state changes are due to improper setting of timer values, or K 469 values (when across lossy links), or frequent routing changes. 471 5.3 Discovering Non-RSVP Clouds 473 The D-TTL field in each response data block shows the number of 474 routing hops between adjacent RSVP routers. Therefore any value 475 greater than one indicates a non-RSVP clouds in between. Together 476 with the arrival timestamps (assuming NTP works), this value can also 477 give some vague, though not necessarily accurate, indication of how 478 big that cloud might be. One might also find out all the intermediate 479 non-RSVP routers by running either unicast or multicast trace route. 481 5.4 Discovering Reservation Merges 483 The flowspec value in a response data block specifies the amount of 484 resources (whatever that means by the yet to be defined flowspec) 485 being reserved for the data stream defined by the filter spec in the 486 same data block. When this value of adjacent response data blocks 487 differs, that is, a downstream router Rd has a smaller value than its 488 immediate upstream router Ru, it indicates a merge of reservation with 489 RSVP request(s) from other down stream interface(s) at Rd. 490 Further, in case of SE style reservation, one can examine how the 491 different SE scopes get merged at each hop. 493 In particular, if a receiver sends a DREQ packet before sending its 494 own reservation, it can discover (1)how many RSVP hops there are along 495 the path between the specified source and itself, (2)how many of 496 the hops already have some reservation by other receivers, and 497 (3)possibly foresee how its reservation request might get merged with 498 other existing ones. 500 5.5 Error Diagnosis 502 In addition to examining the state of a working reservation, RSVP 503 diagnostic packets are more likely to be invoked when things are not 504 working or working correctly. For example, a receiver has reserved an 505 adequate pipe for a specified incoming data stream, yet the observed 506 delay or loss ratio is much higher than expected. In this case the 507 receiver can use the diagnostic facility to examine the reservation 508 state at each RSVP hop along the way to find out whether the RSVP state is 509 set up correctly, whether there is any blackhole along the way, or 510 whether there are non-RSVP clouds, and where, that may have caused the 511 performance problem. 513 6. Acknowledgment 515 The idea of developing a diagnostic facility for RSVP was first 516 proposed by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox 517 PARC and John Krawczyk of Baynetworks for their valuable comments on 518 the first draft of this memo. 520 Authors' Addresses 522 Lixia Zhang 523 UCLA 524 4531G Boelter Hall 525 Los Angeles, CA 90024 527 Phone: 310-825-2695 528 EMail: lixia@cs.ucla.edu