idnits 2.17.1 draft-ietf-rsvp-diagnostic-msgs-01.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-03-28) 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 666 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 58 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 16 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2 Expiration: December 1996 UCLA 3 File: draft-ietf-rsvp-diagnostic-msgs-01.txt June, 1996 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 the 28 deployment of RSVP is spreading out, it has become clear that 29 a method for collecting information about the RSVP state along 30 the path is needed. This specification describes the required 31 functionality, packet format, and processing rules. 33 1. Introduction 35 In the original design of RSVP, error messages are the only means for 36 the end hosts to receive feedback information regarding a specific 37 request that has failed, a failure in setting up either a PATH state 38 or reservation state. In the absence of failures, one receives no 39 feedback regarding the details of a reservation that has been put in 40 place, such as whether, or where, or how, one's own reservation 41 request is merged with that of others. In case of a failure, the 42 error message carries back only the information from the failed point, 43 without any information about the state at other hops before or after 44 the failure. Such missing information, however, can be highly desirable 45 for debugging purpose, or may even be interesting to end applications. 47 In this memo we specify an RSVP diagnostic facility to collect information 48 of RSVP state along the path from a receiver to a specific sender. 49 Diagnostic messages are independent from any other RSVP control messages 50 and produce no side-effects. That is, they do not change any RSVP state at 51 either routers or hosts. A diagnostic reply is not an error report, but a 52 collection of requested RSVP state information. 54 We have the following design goals in mind: 56 - To be able to collect RSVP state information at every hop along the 57 path once the PATH state has been set up, either for an existing 58 reservation or before a reservation request is made; here the "hop" 59 means RSVP-capable routers. 61 More specifically, we want to be able to collect information about 62 flowspec, refresh timer values, and reservation merging at each hop along 63 the path. 65 - To be able to collect the routing hop count for each non-RSVP cloud 66 the path crosses. 68 - To avoid diagnostic packet implosion or explosion. 70 The following are specifically identified as non-goals: 72 - Checking the resource availability along a path. Such functionality 73 may be useful for future reservation requests, but would require 74 modifications to existing admission control module which is beyond 75 the scope of RSVP. 77 2. Overview 79 We define two types of diagnostic packets, diagnostic request (DREQ) 80 and reply (DREP). To avoid packet implosion or explosion, 81 we restrict all diagnostic packets to be unicast only (but see Section 82 5.2 on crossing firewalls). If the requesting host is at the receiving 83 end of the delivery path that is to be queried, it sends a DREQ packet 84 to the last-hop router of the path. If the requester is not a 85 receiving host, it simply sends the DREQ packet to some router on the 86 path. The DREQ packet specifies the RSVP session and a sending host 87 to that session. The router receiving the request adds to the DREQ 88 packet a response data object containing its RSVP state for the 89 specified RSVP session, and then forwards the request via unicast to 90 the router that it believes is the proper previous hop for the given 91 source. Each subsequent hop attaches its own response data object to 92 the end of the DREQ packet, then unicast-forwards to the previous 93 hop. When the DREQ packet reaches the sender, the sender changes 94 the packet type to Diagnostic Reply (DREP) and sends the completed 95 response to the original requester. The response may also be returned 96 before reaching the sender if any error condition along the path, such 97 as "no path state", prevents further forwarding of the request packet. 99 DREP packets can be unicast back to the requester either directly, or 100 in a hop-by-hop manner by reversing the exact path that the DREQ 101 packet has taken. The former is faster and more efficient, but the 102 latter may be the only choice if the packets have to cross firewalls. To 103 facilitate the latter case, a DREQ packet may optionally carry a ROUTE 104 object, which is a list of router addresses that the DREQ packet has 105 passed through on the way to the sender; this ROUTE object is built 106 incrementally as the DREQ packet passes through the intermediate routers. 107 The DREP packet can then be returned to the requester by reversing the path. 109 When the path consists of many hops, it is possible that the total length 110 of a DREP packet will exceed the path MTU size before reaching the sender, 111 thus the packet has to be fragmented. Relying on IP fragmentation and 112 reassembly, however, can be troublesome, especially when DREP packets are 113 returned to the requester hop-by-hop, in which case fragmentation/reassembly 114 would have to be performed at each hop. To avoid such excessive overhead, 115 we let the requester define a default path MTU size which is carried in 116 every DREQ packet. If an intermediate router believes that the default MTU 117 size is too big, it returns the DREQ packet with corresponding error bit 118 set. If an intermediate router detects that a DREQ packet size reaches the 119 MTU size, it trims off the partial result and returns it to the requester, 120 then forwards the trimmed DREQ packet to the next hop towards the sender. 121 Through out this memo we use the word "DREQ packet", rather the word 122 "message" to call a diagnostic request since it always consists of a single 123 packet. On the other hand, one DREQ packet can generate multiple DREP 124 packets, each containing a fragment of the total reply. 126 Notice that one can forward DREQ packets only after the RSVP PATH state has 127 been set up. If no PATH state exists, one may resort to the traceroute 128 facility to examine whether the unicast/multicast routing is working 129 correctly. 131 3. Diagnostic Packet Format 133 A diagnostic packet consists of the following parts: 135 +-----------------------------------+ 136 | RSVP common header | 137 +-----------------------------------+ 138 | Diagnostic packet header object | 139 +-----------------------------------+ 140 | session object | 141 +-----------------------------------+ 142 | (optional) route object | 143 +-----------------------------------+ 144 | one or more Response Object | 145 +-----------------------------------+ 147 3.1 RSVP Message Common Header 149 In the RSVP message common header, 151 0 1 2 3 152 +-------------+-------------+-------------+-------------+ 153 | Vers | Flags| Type | RSVP Checksum | 154 +-------------+-------------+-------------+-------------+ 155 | Send_TTL | reserved | RSVP Length | 156 +-------------+-------------+-------------+-------------+ 157 | Message ID | 158 +-------------+-------------+-------------+-------------+ 160 The Flags field is unused for now and must be set to zero. 162 Type = 8: DREQ 163 Type = 9: DREP 165 RSVP Checksum covers the entire packet body including this header. 167 Send_TTL: the IP TTL value that a router puts in the IP header when 168 forwarding the DREQ packet to the previous hop. 170 RSVP length: the total length of this diagnostic packet in bytes, including 171 the common header. If this is a DREP packet and the MF flag in diagnostic 172 packet header (see below) is set, this length field indicate the length of 173 this single DREP fragment, rather than the total length of the 174 the complete DREP reply (which may not be known in advance). 176 Message ID identifies an individual DREQ packet and corresponding 177 reply (or all the fragments of the reply). 179 3.2 RSVP Diagnostic Packet Header Object 181 Both DREQ and DREP headers are a concatenation of Diagnostic Packet 182 Header Object and an RSVP Session object, as defined below: 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | length | class | c-type | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Max-RSVP-hops | RSVP-hop-count| multicast TTL | Reserved |H|MF| 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | path MTU | Fragment offset | 192 +---------------+---------------+---------------+---------------+ 193 | Sender Address | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | LAST-HOP Address | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Response Address | 198 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 199 | | 200 + RSVP Session Object | 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Length is the length of this diagnostic header object. 206 Class = 30. 208 C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 209 (Ctype = 2). 211 Max-RSVP-hops specifies the maximum number of RSVP hops that the 212 requester wants to collect information from. In case an error 213 condition in the middle of the path prevents the DREQ packet from 214 reaching the specified sender, one may use this field to perform an 215 expanding-length search to reach the point just before the problem. 217 RSVP-hop-count field records the number of RSVP hops that have been 218 traversed so far. 220 Multicast TTL is used to limit the multicast scope when the response 221 address is a multicast address; see Section 5.2 for more details. 222 Otherwise this field must be set to zero. 224 The H flag indicates how the reply should be returned. When H = 0 and 225 the response address is a unicast address, DREP packets should be sent 226 to the response address directly via unicast; otherwise DREP packets 227 are sent to the LAST-HOP address. If H = 0 and the response address 228 is a multicast address, DREP packets should be sent to the LAST-HOP 229 address via unicast. If H = 1, DREP packets must be returned to the 230 LAST-HOP address in a hop-by-hop way. The node specified by the 231 LAST-HOP address then forwards DREP packets to the response address. 233 The MF flag means "more fragment". It must be set to zero in all DREQ 234 packets. All DREP packets that are returned by intermediate routers rather 235 than the sender must set the MF flag to 1; when the sender converts a DREQ 236 packet to a DREP, the MF flag remains zero. 238 The path MTU is a 16-bit field that specifies a default MTU size for 239 diagnostic packets. 241 Sender address is the IP address of the sender for the RSVP path being 242 traced. The DREQ packet proceeds hop-by-hop towards this address. 244 LAST-HOP address is the IP address of the last hop at the receiving 245 end for the path being traced. The DREQ packet starts collecting 246 information at this node and proceeds toward the sender. 248 Response Address is the address to which the DREP packet(s) should be 249 sent. This Response Address does not necessarily specify the node that 250 initiates the DREQ packet, although most often it would. 252 The session object identifies the RSVP session for which the state 253 information is being collected. 255 Optionally, the diagnostic packet header may also contain a ROUTE object, as 256 defined below, immediately after the Session object. The ROUTE object is 257 to be used to return DREP packets hop-by-hop. 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | length | class | c-type | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | reserved | R-pointer | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 + List of RSVP routers | 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Length field represents the total length of the object in number of 270 bytes, from which the number of addresses in the RSVP router list can be 271 easily computed. 273 Class = 31. 274 C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 275 (Ctype = 2) ROUTE object. 277 R-pointer is used in DREP packets only (see Section 4.2 for details), and 278 must be set to zero in all DREQ packets. 280 In a DREQ packet, List of RSVP routers lists all the RSVP hops between the 281 LAST-HOP address, as specified in the Diagnostic packet header object, and 282 the last RSVP router the DREQ packet has visited. 283 In a DREP packet, List of RSVP routers lists all the RSVP hops between the 284 LAST-HOP and the router that returns this DREP packet. 286 3.3 Response Data Object 288 When receiving a DREQ packet, each RSVP router attaches a "response data" 289 object to it before forwarding on. The response data object is defined as 290 follows: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | length | class | C-type | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | DREQ Arrival Time | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Incoming Interface Address | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Outgoing Interface Address | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Previous-RSVP-Hop Router Address | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | reservation style | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | D-TTL |M|R-error| K | timer value | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 | Tspec object | 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 | filter spec object | 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 | flowspec object | 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Class = 32. 323 Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data, 324 respectively. 326 DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival 327 time of the DREQ packet at this router. The 32-bit form of an NTP 328 timestamp consists of the middle 32 bits of the full 64-bit form; that 329 is, the low 16 bits of the integer part and the high 16 bits of the 330 fractional part. 332 Incoming Interface Address specifies the IP address of the interface on 333 which packets from the sender, as defined in the Diagnostic Packet Header, 334 are expected to arrive, or 0 if unknown. 336 Outgoing Interface Address specifies the IP address of the interface from 337 which the DREQ packet comes, and to which packets from the given sender 338 and for the specified session address flow, or 0 if unknown. 340 Previous-RSVP-Hop Router Address specifies the router from which this 341 router receives RSVP PATH messages from this source, or 0 if unknown. 343 Notice that the response object format as shown above assumes IPv4 344 addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2), these 345 three addresses will be 16 bytes each. 347 Reservation style is the 4-byte value of RSVP Style Object as defined in 348 RSVP specification. 350 D-TTL contains the routing hop count this DREQ packet traveled from the 351 down-stream RSVP router to the current router. 353 M is a single-bit flag which indicates whether the reservation, as 354 described by the objects below, is merged with reservations from other 355 downstream interfaces when being forwarded upstream. 357 R-error is a 7-bit field that indicates error conditions at a router. 358 Currently defined values are 359 0x00: no error 360 0x01: no PATH state 361 0x02: MTU too big 362 0x04: ROUTE object too big 364 K is the refresh timer parameter defined in RSVP, and timer value is the 365 local refresh timer value in second. 367 The remaining parts, Tspec, filter spec, and flowspec objects follow the 368 definitions given in RSVP specification. The latter two may be absent 369 (see Section 4.1 on DREQ forwarding). 371 4. Diagnostic Packet Forwarding Rules 373 4.1 DREQ Packet Forwarding 375 DREQ packets are forwarded via hop-by-hop unicast from the LAST-HOP 376 address to the Source address as specified in the diagnostic packet 377 header. Each hop performs the following processing before forwarding 378 the packet to the next hop towards the sender: 380 1 Compute the routing hop count from the previous RSVP hop. 381 This is done by subtracting the value of the TTL value in the IP header 382 from Send_TTL in RSVP common header. The result is then saved in the 383 D-TTL field of the response data object. 385 2 If no PATH state exists for the specified session, set R-error = 0x01 in 386 the Response Data object. 388 3 If the path MTU value is too large, set "MTU too large" error bit, and 389 change the MTU value to the MTU value of the current router. 391 4 Attach the response data object to the end of the DREQ packet. 392 Tspec, filter spec, and flowspec objects in the response object describe 393 the reservation in place at the Outgoing Interface for the specified 394 session. 396 If no reservation state exists for the specified RSVP session, the 397 response object will contain no filter-spec or flowspec object; it should 398 still include the Tspec object for the specified sender that has been 399 carried to the router in the sender's PATH messages. 401 If neither PATH nor reservation state exists for the specified RSVP 402 session, then the response object contains none of the Tspec, filter 403 or flow spec object. 405 5 Increase the packet length field in the RSVP common header accordingly. 407 6 If any error bit is set, change the type field in RSVP common header 408 from DREQ to DREP, and send the packet back to either the LAST-HOP 409 address (if H = 1, or response address is a multicast address), or 410 to the response address directly via unicast (if H = 0). 412 7 Increment the RSVP-hop-count field in the diagnostic packet header by one. 414 If the resulting value is equal to that of Max-RSVP-hops, or if the 415 current hop is the sender as identified by the "Source Address" in the 416 RSVP diagnostic header, go to Send_DREP(), and then return. 418 8 If the resulting DREQ packet size exceeds the MTU limit, minus some 419 margin to hold the address list object as described below, go to 420 Send_DREP(). 422 9 if no error bit set, forward the DREQ packet to the next hop towards the 423 source. 425 Send_DREP(): 426 1. If the H flag in the Diagnostic Header header is off, 427 set target=response address given in the DREQ header, goto Step-5. 429 2. Otherwise create a ROUTE Object (as defined in Section 3.2.2), Rnew. 430 R-pointer value is set to the number of response objects in the DREQ 431 packet. The list of RSVP routers is filled by taking the "Incoming 432 Interface Address" from each of the response objects. 434 The resulting list of routers is in the order in which the DREQ packet 435 has visited them. The DREP packet will traverse through the routers in 436 the reverse order. 438 3. If the DREQ packet already contains a Router Object, Rold, merge 439 Rnew with Rold by adding the R-pointer in Rnew to that in Rold, and 440 attach the Router list of Rnew to the end of that in Rold. 442 4. Insert the resulting Route object from Steps 2 & 3 between 443 Session object and the first response data block. 444 set target = the last address in ROUTE 446 5. Make a copy of the resulting DREQ packet, change the type field in RSVP 447 common header from DREQ to DREP, and send the packet to target via 448 unicast. 450 If the ROUTE object is so large such that 451 (size of ROUTE + 2 * size of response data object) > path MTU, 452 set the "route too big" error bit, send the packet, and go to 7. 454 6. Trim off all the response data objects from the original DREQ 455 packet, and adjust the "Fragment offset" value in the RSVP common header 456 accordingly. 458 7. Return. 460 4.2 DREP Forwarding 462 When the H flag is off, DREP packets are sent directly to the original 463 requester. When H flag is on, however, they are forwarded hop-by-hop 464 to the requester, by reversing the route as listed in the Route object. 466 When a router receives a DREP packet, it simply decreases R-pointer by 467 one (address length), and forward the packet to the address pointed by 468 R-pointer in the route list. 470 When the LAST-HOP router receives a DREP packet, it sends the 471 packet to the Response address. 473 4.3 MTU Selection and Adjustment 475 Because the DREQ packet carries the allowed MTU size of previous hops 476 that the DREP packets will later traverse, this unique feature allows 477 the easy semantic fragmentation as described above. Whenever the DREQ 478 packet grows to approach the size of MTU, it can be trimmed before 479 being forwarded again. 481 When a requester sends a DREQ packet, the path MTU field in the RSVP 482 Diagnostic Packet header can be set to a configured default value. 483 Whenever a DREQ packet size approaches the specified MTU value, an 484 intermediate RSVP router makes a copy of the packet, converts it to a DREP 485 packet to send back, and then trims off the partial results from DREQ 486 packet and forwards it. 488 It is possible that the original MTU value is chosen larger than the actual 489 MTU value along some portion of the path being traced. Therefore each 490 intermediate RSVP router must check the MTU value when processing a DREQ 491 packet. If the specified MTU value is larger than the MTU of the incoming 492 interface (that the DREQ packet will be forwarded to), the router 493 (1) sets the R-error value, 494 (2) changes the MTU value in the header to the smaller value, and 495 (3) converts the DREQ packet to a DREP and sends it back to the requester. 497 In rare case that some intermediate routers do not check, or enforce upon, 498 the MTU value carried in the diagnostic packets, it is possible that on the 499 way back to the requester, a DREP packet may encounter a link of smaller MTU. 500 When this happens, the router follows steps (1) and (2) as outlined above, 501 and trims off the extra part of the DREP packet to fit in the smaller MTU of 502 the link. The trimming must be done at response object boundaries. Such 503 trimming of packets results in information loss. However because the 504 requester learns what is the available MTU size, it can either ignore the 505 loss, or otherwise try again with the smaller MTU value. 507 4.4 Errors 509 If an error condition prevents a DREP packet from being forwarded 510 further, the packet is simply dropped. 512 If an error condition, such as lack of PATH state, prevents a DREQ 513 packet from being forwarded further, the router must change the 514 current packet to DREP type and return it to the response address. 516 5. Problem Diagnosis by Using RSVP Diagnostic Facility 518 5.1 Broken Intermediate Router 520 A broken (or legacy) intermediate RSVP router may simply not 521 understand diagnostic packets, and drop them. The querier would then 522 get no response at all from its requests. It may then choose to first 523 do a multicast traceroute (in case of multicast) to get information 524 about the route length, and then perform an RSVP diagnosis search 525 by gradually increasing the value of M_TTL field until it no longer 526 receives a response. 528 5.2 Across Firewalls 530 Firewalls can cause problems in diagnostic packet forwarding. Let us 531 look at two different cases. 533 First, let us assume that the querier is a receiving host of the 534 session to be examined. In this case, firewalls should not prevent 535 the forwarding of the diagnostic packets in a hop-by-hop manner, 536 assuming that proper holes have been punched on the firewall to allow 537 hop-by-hop forwarding of other RSVP packets. The querier may start by 538 setting the H flag off, which can give a faster response delivery and 539 reduced overhead at intermediate routers. However if no response is 540 received, the querier may resend the DREQ packet with H flag turned 541 on. 543 If the requester is a third party host and is separated from the LAST-HOP 544 address by a firewall (either the requester is behind a firewall, or the 545 LAST-HOP is a router behind a firewall, or both), at this time I do not 546 know any other solution but attempting to use multicast. 548 To send a DREQ packet across a firewall (or firewalls), the request 549 should be multicast to the group being examined (since the last hop 550 router listens to that group). All routers except the correct last 551 hop router, as identified by the LAST-HOP address in the DREQ 552 header, should ignore any DREQ request received via multicast. 554 To receive a DREP packet across a firewall (or firewalls), the querier 555 should set the response address to a well-known multicast address 556 allocated specifically for DREP packets. In this case, all the reply 557 packets will be first unicast to the LAST-HOP address specified in the 558 diagnostic header, which in turn multicasts them out with a scope as 559 specified by the multicast TTL value in the Diagnostic Packet Header 560 Object. This multicast TTL scope should be set to a value sufficient 561 for the response from the LAST-HOP router to reach the querier. 562 However we must also carefully limit this value to a small number, 563 because there is only one well-known multicast address for this 564 purpose, therefore all the queriers from all other 565 sessions will receive the multicast DREP packets as well. If the 566 querier still cannot receive the DREP packet when the TTL reaches the 567 limit, then one must consider using a node closer to the LAST-HOP 568 address instead. 570 5.3 Examination of RSVP Timers 572 One can easily collect information about the current timer value at each 573 RSVP hop along the way. This will be very helpful in situations when 574 the reservation state goes up and down frequently, to find out whether 575 the state changes are due to improper setting of timer values, or K 576 values (when across lossy links), or frequent routing changes. 578 5.3 Discovering Non-RSVP Clouds 580 The D-TTL field in each response data block shows the number of 581 routing hops between adjacent RSVP routers. Therefore any value 582 greater than one indicates a non-RSVP clouds in between. Together 583 with the arrival timestamps (assuming NTP works), this value can also 584 give some vague, though not necessarily accurate, indication of how 585 big that cloud might be. One might also find out all the intermediate 586 non-RSVP routers by running either unicast or multicast trace route. 588 5.4 Discovering Reservation Merges 590 The flowspec value in a response data block specifies the amount of 591 resources (whatever that means by the yet to be defined flowspec) 592 being reserved for the data stream defined by the filter spec in the 593 same data block. When this value of adjacent response data blocks 594 differs, that is, a downstream router Rd has a smaller value than its 595 immediate upstream router Ru, it indicates a merge of reservation with 596 RSVP request(s) from other down stream interface(s) at Rd. 597 Further, in case of SE style reservation, one can examine how the 598 different SE scopes get merged at each hop. 600 In particular, if a receiver sends a DREQ packet before sending its 601 own reservation, it can discover (1)how many RSVP hops there are along 602 the path between the specified source and itself, (2)how many of 603 the hops already have some reservation by other receivers, and 604 (3)possibly foresee how its reservation request might get merged with 605 other existing ones. 607 5.5 Error Diagnosis 609 In addition to examining the state of a working reservation, RSVP 610 diagnostic packets are more likely to be invoked when things are not 611 working correctly. For example, a receiver has reserved an 612 adequate pipe for a specified incoming data stream, yet the observed 613 delay or loss ratio is much higher than expected. In this case the 614 receiver can use the diagnostic facility to examine the reservation 615 state at each RSVP hop along the way to find out whether the RSVP state is 616 set up correctly, whether there is any blackhole along the way, or 617 whether there are non-RSVP clouds, and where, that may have caused the 618 performance problem. 620 6. Further Work 622 A missing piece from the current design is the handling of diagnostic 623 packets across routers that are RSVP-capable but do not support 624 RSVP diagnostic messages. 626 7. Acknowledgment 628 The idea of developing a diagnostic facility for RSVP was first 629 proposed by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox 630 PARC and John Krawczyk of Baynetworks for their valuable comments on 631 the first draft of this memo. Lee and Bob Braden contributed further 632 comments after the LA IETF, and John Krawczyk caught a number of 633 errors just prior to this post. 635 Authors' Addresses 637 Lixia Zhang 638 UCLA 639 4531G Boelter Hall 640 Los Angeles, CA 90024 642 Phone: 310-825-2695 643 EMail: lixia@cs.ucla.edu