idnits 2.17.1 draft-ietf-rsvp-diagnostic-msgs-02.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-26) 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 682 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 20 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. -------------------------------------------------------------------------------- 2 Internet Draft Lixia Zhang 3 Expiration: April 1997 Andreas Terzis 4 File: draft-ietf-rsvp-diagnostic-msgs-02.txt UCLA 5 November, 1996 7 RSVP Diagnostic Messages 9 Status of Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Abstract 29 This draft describes the RSVP diagnosis facility. As the 30 deployment of RSVP is spreading out, it has become clear that 31 a method for collecting information about the RSVP state along 32 the path is needed. This specification describes the required 33 functionality, packet format, and processing rules. 35 1. Introduction 37 In the original design of RSVP, error messages are the only means for 38 the end hosts to receive feedback information regarding a specific 39 request that has failed, a failure in setting up either a PATH state 40 or reservation state. In the absence of failures, one receives no 41 feedback regarding the details of a reservation that has been put in 42 place, such as whether, or where, or how, one's own reservation 43 request is merged with that of others. In case of a failure, the 44 error message carries back only the information from the failed point, 45 without any information about the state at other hops before or after 46 the failure. Such missing information, however, can be highly desirable 47 for debugging purpose, or may even be interesting to end applications. 49 In this memo we specify an RSVP diagnostic facility to collect information 50 of RSVP state along the path from a receiver to a specific sender. 51 Diagnostic messages are independent from any other RSVP control messages 52 and produce no side-effects. That is, they do not change any RSVP state at 53 either routers or hosts. A diagnostic reply is not an error report, but a 54 collection of requested RSVP state information. 56 We have the following design goals in mind: 58 - To be able to collect RSVP state information at every hop along the 59 path once the PATH state has been set up, either for an existing 60 reservation or before a reservation request is made; here the "hop" 61 means RSVP-capable routers. 63 More specifically, we want to be able to collect information about 64 flowspec, refresh timer values, and reservation merging at each hop along 65 the path. 67 - To be able to collect the routing hop count for each non-RSVP cloud 68 the path crosses. 70 - To avoid diagnostic packet implosion or explosion. 72 The following are specifically identified as non-goals: 74 - Checking the resource availability along a path. Such functionality 75 may be useful for future reservation requests, but would require 76 modifications to existing admission control module which is beyond 77 the scope of RSVP. 79 2. Overview 81 We define two types of diagnostic packets, diagnostic request (DREQ) 82 and reply (DREP). To avoid packet implosion or explosion, 83 we restrict all diagnostic packets to be unicast only (but see Section 84 5.2 on crossing firewalls). If the requesting host is at the receiving 85 end of the delivery path that is to be queried, it sends a DREQ packet 86 to the last-hop router of the path. If the requester is not a 87 receiving host, it simply sends the DREQ packet to some router on the 88 path. The DREQ packet specifies the RSVP session and a sending host 89 to that session. The router receiving the request adds to the DREQ 90 packet a response data object containing its RSVP state for the 91 specified RSVP session, and then forwards the request via unicast to 92 the router that it believes is the proper previous hop for the given 93 source. Each subsequent hop attaches its own response data object to 94 the end of the DREQ packet, then unicast-forwards to the previous 95 hop. When the DREQ packet reaches the sender, the sender changes 96 the packet type to Diagnostic Reply (DREP) and sends the completed 97 response to the original requester. The response may also be returned 98 before reaching the sender if any error condition along the path, such 99 as "no path state", prevents further forwarding of the request packet. 101 DREP packets can be unicast back to the requester either directly, or 102 in a hop-by-hop manner by reversing the exact path that the DREQ 103 packet has taken. The former is faster and more efficient, but the 104 latter may be the only choice if the packets have to cross firewalls. To 105 facilitate the latter case, a DREQ packet may optionally carry a ROUTE 106 object, which is a list of router addresses that the DREQ packet has 107 passed through on the way to the sender; this ROUTE object is built 108 incrementally as the DREQ packet passes through the intermediate routers. 109 The DREP packet can then be returned to the requester by reversing the path. 111 When the path consists of many hops, it is possible that the total length 112 of a DREP packet will exceed the path MTU size before reaching the sender, 113 thus the packet has to be fragmented. Relying on IP fragmentation and 114 reassembly, however, can be troublesome, especially when DREP packets are 115 returned to the requester hop-by-hop, in which case fragmentation/reassembly 116 would have to be performed at each hop. To avoid such excessive overhead, 117 we let the requester define a default path MTU size which is carried in 118 every DREQ packet. If an intermediate router believes that the default MTU 119 size is too big, it returns the DREQ packet with corresponding error bit 120 set. If an intermediate router detects that a DREQ packet size reaches the 121 MTU size, it trims off the partial result and returns it to the requester, 122 then forwards the trimmed DREQ packet to the next hop towards the sender. 123 Through out this memo we use the word "DREQ packet", rather the word 124 "message" to call a diagnostic request since it always consists of a single 125 packet. On the other hand, one DREQ packet can generate multiple DREP 126 packets, each containing a fragment of the total reply. 128 Notice that one can forward DREQ packets only after the RSVP PATH state has 129 been set up. If no PATH state exists, one may resort to the traceroute 130 facility to examine whether the unicast/multicast routing is working 131 correctly. 133 3. Diagnostic Packet Format 135 A diagnostic packet consists of the following parts: 137 +-----------------------------------+ 138 | RSVP common header | 139 +-----------------------------------+ 140 | Diagnostic packet header object | 141 +-----------------------------------+ 142 | session object | 143 +-----------------------------------+ 144 | (optional) route object | 145 +-----------------------------------+ 146 | one or more Response Object | 147 +-----------------------------------+ 149 3.1 RSVP Message Common Header 151 In the RSVP message common header, 153 0 1 2 3 154 +-------------+-------------+-------------+-------------+ 155 | Vers | Flags| Type | RSVP Checksum | 156 +-------------+-------------+-------------+-------------+ 157 | Send_TTL | reserved | RSVP Length | 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. 166 The Checksum algorithm is the same as the one used in IP checksum, that 167 is it is: 168 The 16 bit one's complement of the one's complement sum of all the 16 169 bit words in the header. For purposes of computing the checksum, the value 170 of the checksum is zero. 172 Send_TTL: the IP TTL value that a router puts in the IP header when 173 forwarding the DREQ packet to the previous hop. 175 RSVP length: the total length of this diagnostic packet in bytes, including 176 the common header. If this is a DREP packet and the MF flag in diagnostic 177 packet header (see below) is set, this length field indicate the length of 178 this single DREP fragment, rather than the total length of the 179 the complete DREP reply (which may not be known in advance). 181 3.2 RSVP Diagnostic Packet Header Object 183 Both DREQ and DREP headers are a concatenation of Diagnostic Packet 184 Header Object and an RSVP Session object, as defined below: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | length | class | c-type | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Max-RSVP-hops | RSVP-hop-count| multicast TTL | Reserved |H|MF| 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Message ID | 194 +---------------+---------------+---------------+---------------+ 195 | path MTU | Fragment offset | 196 +---------------+---------------+---------------+---------------+ 197 | Sender Filter Spec | 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | LAST-HOP Address | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Response Address | 203 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 204 | | 205 + Followed by RSVP Session Object | 206 | | 208 Length is the length of this diagnostic header object. 210 Class = 30. 212 C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 213 (Ctype = 2). In the the IPv6 case adddreses will be 16 bytes each. 215 Max-RSVP-hops specifies the maximum number of RSVP hops that the 216 requester wants to collect information from. In case an error 217 condition in the middle of the path prevents the DREQ packet from 218 reaching the specified sender, one may use this field to perform an 219 expanding-length search to reach the point just before the problem. 221 The fragment offset field indicates where in the total reply this fragment 222 belongs. The fragment offset is measured in octets. The first fragment has 223 offset zero. 225 RSVP-hop-count field records the number of RSVP hops that have been 226 traversed so far. 228 Multicast TTL is used to limit the multicast scope when the response 229 address is a multicast address; see Section 5.2 for more details. 230 Otherwise this field must be set to zero. 232 The H flag indicates how the reply should be returned. When H = 0 and 233 the response address is a unicast address, DREP packets should be sent 234 to the response address directly via unicast If H = 0 and the response 235 address is a multicast address, DREP packets should be sent to the LAST-HOP 236 address via unicast. If H = 1, DREP packets must be returned to the 237 LAST-HOP address in a hop-by-hop way. The node specified by the 238 LAST-HOP address then forwards DREP packets to the response address. 240 The MF flag means "more fragment". It must be set to zero in all DREQ 241 packets. All DREP packets that are returned by intermediate routers rather 242 than the sender must set the MF flag to 1; when the sender converts a DREQ 243 packet to a DREP, the MF flag remains zero. 245 Message ID identifies an individual DREQ packet and corresponding 246 reply (or all the fragments of the reply). 248 The path MTU is a 16-bit field that specifies a default MTU size for 249 diagnostic packets. 251 Sender Filter-Spec is the IP address plus the port of the sender being 252 traced. The DREQ packet proceeds hop-by-hop towards this address. 254 LAST-HOP address is the IP address of the last hop at the receiving 255 end for the path being traced. The DREQ packet starts collecting 256 information at this node and proceeds toward the sender. 258 Response Address is the address to which the DREP packet(s) should be 259 sent. This Response Address does not necessarily specify the node that 260 initiates the DREQ packet, although most often it would. 262 The session object identifies the RSVP session for which the state 263 information is being collected. 265 Optionally, the diagnostic packet header may also contain a ROUTE object, as 266 defined below, immediately after the Session object. The ROUTE object is 267 to be used to return DREP packets hop-by-hop. 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | length | class | c-type | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | reserved | R-pointer | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 + List of RSVP routers | 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Length field represents the total length of the object in number of 280 bytes, from which the number of addresses in the RSVP router list can be 281 easily computed. 283 Class = 31. 284 C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 285 (Ctype = 2) ROUTE object. 287 R-pointer is used in DREP packets only (see Section 4.2 for details), 288 but is incremented as each hop adds its incoming interface address in 289 the ROUTE object. 291 In a DREQ packet, List of RSVP routers lists all the RSVP hops between the 292 LAST-HOP address, as specified in the Diagnostic packet header object, and 293 the last RSVP router the DREQ packet has visited. 294 In a DREP packet, List of RSVP routers lists all the RSVP hops between the 295 LAST-HOP and the router that returns this DREP packet. 297 3.3 Response Data Object 299 When receiving a DREQ packet, each RSVP router attaches a "response data" 300 object to it before forwarding on. The response data object is defined as 301 follows: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | length | class | C-type | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | DREQ Arrival Time | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Incoming Interface Address | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Outgoing Interface Address | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Previous-RSVP-Hop Router Address | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | reservation style | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | D-TTL |M|R-err| K | timer value | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 | Tspec object | 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | 325 | filter spec object | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 | flowspec object | 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Class = 32. 334 Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data, 335 respectively. 337 DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival 338 time of the DREQ packet at this router. The 32-bit form of an NTP 339 timestamp consists of the middle 32 bits of the full 64-bit form; that 340 is, the low 16 bits of the integer part and the high 16 bits of the 341 fractional part. 343 Incoming Interface Address specifies the IP address of the interface on 344 which packets from the sender, as defined in the Diagnostic Packet Header, 345 are expected to arrive, or 0 if unknown. 347 Outgoing Interface Address specifies the IP address of the interface from 348 which the DREQ packet comes, and to which packets from the given sender 349 and for the specified session address flow, or 0 if unknown. 351 Previous-RSVP-Hop Router Address specifies the router from which this 352 router receives RSVP PATH messages from this source, or 0 if unknown. 354 Notice that the response object format as shown above assumes IPv4 355 addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2), these 356 three addresses will be 16 bytes each. 358 Reservation style is the 4-byte value of RSVP Style Object as defined in 359 RSVP specification. 361 D-TTL contains the routing hop count this DREQ packet traveled from the 362 down-stream RSVP router to the current router. 364 M is a single-bit flag which indicates whether the reservation, as 365 described by the objects below, is merged with reservations from other 366 downstream interfaces when being forwarded upstream. 368 R-error is a 3-bit field that indicates error conditions at a router. 369 Currently defined values are 370 0x00: no error 371 0x01: no PATH state 372 0x02: MTU too big 373 0x04: ROUTE object too big 375 K is the refresh timer parameter defined in RSVP, and timer value is the 376 local refresh timer value in seconds. 378 The remaining parts, Tspec, filter spec, and flowspec objects follow the 379 definitions given in RSVP specification. The latter two may be absent 380 (see Section 4.1 on DREQ forwarding). Also note that the length of these 381 object is varying so the lengths used on the diagram above are not 382 representative. 384 4. Diagnostic Packet Forwarding Rules 386 4.1 DREQ Packet Forwarding 388 DREQ packets are forwarded via hop-by-hop unicast from the LAST-HOP 389 address to the Source address as specified in the diagnostic packet 390 header. Each hop performs the following processing before forwarding 391 the packet to the next hop towards the sender: 393 1 Compute the routing hop count from the previous RSVP hop. 394 This is done by subtracting the value of the TTL value in the IP header 395 from Send_TTL in RSVP common header. The result is then saved in the 396 D-TTL field of the response data object. 398 2 If no PATH state exists for the specified session, set R-error = 0x01 in 399 the Response Data object. 401 3 If the path MTU value is too large, set "MTU too large" error bit, and 402 change the MTU value to the MTU value of the incoming interface for PATH 403 messages for the current router. 405 4 Attach the response data object to the end of the DREQ packet. 406 Tspec, filter spec, and flowspec objects in the response object describe 407 the reservation in place at the Outgoing Interface for the specified 408 session. 410 If no reservation state exists for the specified RSVP session, the 411 response object will contain no filter-spec or flowspec object; it should 412 still include the Tspec object for the specified sender that has been 413 carried to the router in the sender's PATH messages. 415 If neither PATH nor reservation state exists for the specified RSVP 416 session, then the response object contains none of the Tspec, filter 417 or flow spec object. 419 5 Increase the packet length field in the RSVP common header accordingly. 421 6 If any error bit is set, change the type field in RSVP common header 422 from DREQ to DREP, and send the packet back to either the LAST-HOP 423 address (if H = 1, or response address is a multicast address), or 424 to the response address directly via unicast (if H = 0). 426 7 Increment the RSVP-hop-count field in the diagnostic packet header by one. 428 If the resulting value is equal to that of Max-RSVP-hops, or if the 429 current hop is the sender as identified by the "Source Address" in the 430 RSVP diagnostic header, go to Send_DREP(), and then return. 432 8 If the resulting DREQ packet size exceeds the MTU limit, minus some 433 margin to hold the address list object as described below, go to 434 Send_DREP(). 436 9 If no error bit set ,then if the H-bit is set append the "Incoming 437 Interface Address" to the end of the ROUTE object, increment 438 R-Pointer by one and update the packet length field in the RSVP 439 common header accordingly. 440 Finally forward the DREQ packet to the next hop towards the 441 source. 443 Send_DREP(): 444 1. If the H flag in the Diagnostic Header header is off, 445 set target=response address given in the DREQ header, else 446 set target = the last address in ROUTE. 448 2. Make a copy of the DREQ packet and change the type field in RSVP 449 common header from DREQ to DREP. If this host is not the source set 450 the MF flag on. 452 If the ROUTE object is so large such that 453 (size of ROUTE + size of response data object) > path MTU, 454 then set the "route too big" error bit, send the response packet, 455 and go to 7, else send the response packet. 457 3. If this host is not the source, then trim off all the response data 458 objects from the original DREQ packet, adjust the "Fragment offset" 459 value in the RSVP common header accordingly and forward the 460 modified DREQ packet towards the source. 462 4. Return. 464 4.2 DREP Forwarding 466 When the H flag is off, DREP packets are sent directly to the original 467 requester. When H flag is on, however, they are forwarded hop-by-hop 468 to the requester, by reversing the route as listed in the Route object. 470 When a router receives a DREP packet, it simply decreases R-pointer by 471 one (address length), and forward the packet to the address pointed by 472 R-pointer in the route list. 474 When the LAST-HOP router receives a DREP packet, it sends the 475 packet to the Response address. 477 4.3 MTU Selection and Adjustment 479 Because the DREQ packet carries the allowed MTU size of previous hops 480 that the DREP packets will later traverse, this unique feature allows 481 the easy semantic fragmentation as described above. Whenever the DREQ 482 packet grows to approach the size of MTU, it can be trimmed before 483 being forwarded again. 485 When a requester sends a DREQ packet, the path MTU field in the RSVP 486 Diagnostic Packet header can be set to a configured default value. 487 Whenever a DREQ packet size approaches the specified MTU value, an 488 intermediate RSVP router makes a copy of the packet, converts it to a DREP 489 packet to send back, and then trims off the partial results from DREQ 490 packet and forwards it. 492 It is possible that the original MTU value is chosen larger than the actual 493 MTU value along some portion of the path being traced. Therefore each 494 intermediate RSVP router must check the MTU value when processing a DREQ 495 packet. If the specified MTU value is larger than the MTU of the incoming 496 interface (that the DREQ packet will be forwarded to), the router 497 (1) sets the R-error value, 498 (2) changes the MTU value in the header to the smaller value, and 499 (3) converts the DREQ packet to a DREP and sends it back to the requester. 501 In rare case that some intermediate routers do not check, or enforce upon, 502 the MTU value carried in the diagnostic packets, it is possible that on the 503 way back to the requester, a DREP packet may encounter a link of smaller MTU. 504 When this happens, the router follows steps (1) and (2) as outlined above, 505 and trims off the extra part of the DREP packet to fit in the smaller MTU of 506 the link. The trimming must be done at response object boundaries. Such 507 trimming of packets results in information loss. However because the 508 requester learns what is the available MTU size, it can either ignore the 509 loss, or otherwise try again with the smaller MTU value. 511 4.4 Errors 513 If an error condition prevents a DREP packet from being forwarded 514 further, the packet is simply dropped. 516 If an error condition, such as lack of PATH state, prevents a DREQ 517 packet from being forwarded further, the router must change the 518 current packet to DREP type and return it to the response address. 520 5. Problem Diagnosis by Using RSVP Diagnostic Facility 522 5.1 Broken Intermediate Router 524 A broken (or legacy) intermediate RSVP router may simply not 525 understand diagnostic packets, and drop them. The querier would then 526 get no response at all from its requests. It may then choose to first 527 do a multicast traceroute (in case of multicast) to get information 528 about the route length, and then perform an RSVP diagnosis search 529 by gradually increasing the value of M_TTL field until it no longer 530 receives a response. 532 5.2 Across Firewalls 534 Firewalls can cause problems in diagnostic packet forwarding. Let us 535 look at two different cases. 537 First, let us assume that the querier is a receiving host of the 538 session to be examined. In this case, firewalls should not prevent 539 the forwarding of the diagnostic packets in a hop-by-hop manner, 540 assuming that proper holes have been punched on the firewall to allow 541 hop-by-hop forwarding of other RSVP packets. The querier may start by 542 setting the H flag off, which can give a faster response delivery and 543 reduced overhead at intermediate routers. However if no response is 544 received, the querier may resend the DREQ packet with H flag turned 545 on. 547 If the requester is a third party host and is separated from the LAST-HOP 548 address by a firewall (either the requester is behind a firewall, or the 549 LAST-HOP is a router behind a firewall, or both), at this time I do not 550 know any other solution but attempting to use multicast. 552 To send a DREQ packet across a firewall (or firewalls), the request 553 should be multicast to the group being examined (since the last hop 554 router listens to that group). All routers except the correct last 555 hop router, as identified by the LAST-HOP address in the DREQ 556 header, should ignore any DREQ request received via multicast. 558 To receive a DREP packet across a firewall (or firewalls), the querier 559 should set the response address to a well-known multicast address 560 allocated specifically for DREP packets. In this case, all the reply 561 packets will be first unicast to the LAST-HOP address specified in the 562 diagnostic header, which in turn multicasts them out with a scope as 563 specified by the multicast TTL value in the Diagnostic Packet Header 564 Object. This multicast TTL scope should be set to a value sufficient 565 for the response from the LAST-HOP router to reach the querier. 566 However we must also carefully limit this value to a small number, 567 because there is only one well-known multicast address for this 568 purpose, therefore all the queriers from all other 569 sessions will receive the multicast DREP packets as well. If the 570 querier still cannot receive the DREP packet when the TTL reaches the 571 limit, then one must consider using a node closer to the LAST-HOP 572 address instead. 574 5.3 Examination of RSVP Timers 576 One can easily collect information about the current timer value at each 577 RSVP hop along the way. This will be very helpful in situations when 578 the reservation state goes up and down frequently, to find out whether 579 the state changes are due to improper setting of timer values, or K 580 values (when across lossy links), or frequent routing changes. 582 5.3 Discovering Non-RSVP Clouds 584 The D-TTL field in each response data block shows the number of 585 routing hops between adjacent RSVP routers. Therefore any value 586 greater than one indicates a non-RSVP clouds in between. Together 587 with the arrival timestamps (assuming NTP works), this value can also 588 give some vague, though not necessarily accurate, indication of how 589 big that cloud might be. One might also find out all the intermediate 590 non-RSVP routers by running either unicast or multicast trace route. 592 5.4 Discovering Reservation Merges 594 The flowspec value in a response data block specifies the amount of 595 resources (whatever that means by the yet to be defined flowspec) 596 being reserved for the data stream defined by the filter spec in the 597 same data block. When this value of adjacent response data blocks 598 differs, that is, a downstream router Rd has a smaller value than its 599 immediate upstream router Ru, it indicates a merge of reservation with 600 RSVP request(s) from other down stream interface(s) at Rd. 601 Further, in case of SE style reservation, one can examine how the 602 different SE scopes get merged at each hop. 604 In particular, if a receiver sends a DREQ packet before sending its 605 own reservation, it can discover (1)how many RSVP hops there are along 606 the path between the specified source and itself, (2)how many of 607 the hops already have some reservation by other receivers, and 608 (3)possibly foresee how its reservation request might get merged with 609 other existing ones. 611 5.5 Error Diagnosis 613 In addition to examining the state of a working reservation, RSVP 614 diagnostic packets are more likely to be invoked when things are not 615 working correctly. For example, a receiver has reserved an 616 adequate pipe for a specified incoming data stream, yet the observed 617 delay or loss ratio is much higher than expected. In this case the 618 receiver can use the diagnostic facility to examine the reservation 619 state at each RSVP hop along the way to find out whether the RSVP state is 620 set up correctly, whether there is any blackhole along the way, or 621 whether there are non-RSVP clouds, and where, that may have caused the 622 performance problem. 624 6. Further Work 626 A missing piece from the current design is the handling of diagnostic 627 packets across routers that are RSVP-capable but do not support 628 RSVP diagnostic messages. 630 7. Acknowledgment 632 The idea of developing a diagnostic facility for RSVP was first 633 proposed by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox 634 PARC and John Krawczyk of Baynetworks for their valuable comments on 635 the first draft of this memo. Lee and Bob Braden contributed further 636 comments after the LA IETF, and John Krawczyk caught a number of 637 errors just prior to this post. We would also like to thank Vincent 638 Subramanian for his comments on this second draft of the memo. 640 Authors' Addresses 642 Lixia Zhang 643 UCLA 644 4531G Boelter Hall 645 Los Angeles, CA 90024 647 Phone: 310-825-2695 648 EMail: lixia@cs.ucla.edu 650 Andreas Terzis 651 UCLA 652 4677 Boelter Hall 653 Los Angeles, CA 90024 655 Phone: 310-267-2190 656 Email: terzis@cs.ucla.edu