idnits 2.17.1 draft-ietf-rsvp-diagnostic-msgs-05.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 156 has weird spacing: '...utgoing link,...' == Line 363 has weird spacing: '...must be zero....' == Line 525 has weird spacing: '...rwarded hop-b...' -- 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 (November 1998) is 9293 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) == Missing Reference: 'RSVP' is mentioned on line 202, but not defined == Missing Reference: 'Class' is mentioned on line 362, but not defined == Missing Reference: 'C-type' is mentioned on line 344, but not defined == Missing Reference: 'C-Type' is mentioned on line 362, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-rsvp-tunnel-03 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Lixia Zhang 3 Expires: May 1999 Andreas Terzis 4 UCLA 5 Subramaniam Vincent 6 Cisco 7 Bob Braden 8 ISI 9 November 1998 10 RSVP Diagnostic Messages 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Distribution of this memo is unlimited. 34 Abstract 36 This document specifies the RSVP diagnostic facility, which allows a 37 user to collect information about the RSVP state along the path. 38 This specification describes the functionality, diagnostic message 39 formats, and processing rules. 41 1. Introduction 43 In the basic RSVP protocol [RSVP], error messages are the only means 44 for an end host to receive feedback regarding a failure in setting up 45 either path state or reservation state. An error message carries 46 back only the information from the failed point, without any 47 information about the state at other hops before or after the 48 failure. In the absence of failures, a host receives no feedback 49 regarding the details of a reservation that has been put in place, 50 such as whether, or where, or how, its own reservation request is 51 being merged with that of others. Such missing information can be 52 highly desirable for debugging purpose, or for network resource 53 management in general. 55 This document specifies the RSVP diagnostic facility, which is 56 designed to fill this information gap. The diagnostic facility can 57 be used to collect and report RSVP state information along the path 58 from a receiver to a specific sender. It uses Diagnostic messages 59 that are independent of other RSVP control messages and produce no 60 side-effects; that is, they do not change any RSVP state at either 61 nodes or hosts. Similarly, they provide not an error report but 62 rather a collection of requested RSVP state information. 64 The RSVP diagnostic facility was designed with the following goals: 65 - To collect RSVP state information from every RSVP-capable hop 66 along a path defined by path state, either for an existing 67 reservation or before a reservation request is made. More 68 specifically, we want to be able to collect information about 69 flowspecs, refresh timer values, and reservation merging at each 70 hop along the path. 72 - To collect the IP hop count across each non-RSVP cloud. 74 - To avoid diagnostic packet implosion or explosion. 76 The following is specifically identified as a non-goal: 78 - Checking the resource availability along a path. Such 79 functionality may be useful for future reservation requests, but 80 it would require modifications to existing admission control 81 modules that is beyond the scope of RSVP. 83 2. Overview 85 The diagnostic facility introduces two new RSVP message types: 86 Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A DREQ 87 message can be originated by a client in a "requester" host, which 88 may or may not be a participant of the RSVP session to be diagnosed. 89 A client in the requester host invokes the RSVP diagnostic facility 90 by generating a DREQ packet and sending it to the starting node, 91 which should be on the RSVP path to be diagnosed. This DREQ packet 92 specifies the RSVP session and a sender host for that session. The 93 DREQ packet collects information hop-by-hop as it is forwarded 94 towards the sender (see Figure 1), until it reaches the ending node. 95 Specifically, each RSVP-capable hop adds to the DREQ message a 96 response (DIAG_RESPONSE) object containing local RSVP state for the 97 specified RSVP session. When the DREQ packet reaches the ending 98 node, the message type is changed to Diagnostic Reply (DREP) and the 99 completed response is sent to the original requester node. Partial 100 responses may also be returned before the DREQ packet reaches the 101 ending node if an error condition along the path, such as "no path 102 state", prevents further forwarding of the DREQ packet. To avoid 103 packet implosion or explosion, all diagnostic packets are forwarded 104 via unicast only. 106 Thus, there are generally three nodes (hosts and/or routers) involved 107 in performing the diagnostic function: the requester node, the 108 starting node, and the ending node, as shown in Figure 1. It is 109 possible that the client invoking the diagnosis function may reside 110 directly on the starting node, in which case that the first two nodes 111 are the same. The starting node is named "LAST-HOP", meaning the 112 last-hop of the path segment to be diagnosed. The LAST-HOP node can 113 be either a receiver node or an intermediate node along the path. 114 The ending node is usually the specified sender host. However, the 115 client can limit the length of the path segment to be diagnosed by 116 specifying a hop-count limit in the DREQ message. 118 LAST-HOP Ending 119 Receiver node node Sender 120 __ __ __ __ __ 121 | |---------| |------>| |--> ...-->| |--> ...---->| | 122 |__| |__| DREQ |__| DREQ |__| DREQ |__| 123 ^ . | 124 | . | 125 | DREQ . DREP | DREP 126 | . | 127 _|_ DREP V V 128 Requester | | <------------------------------------ 129 (client) |___| 131 Figure 1 133 DREP packets can be unicast from the ending node back to the 134 requester either directly or hop-by-hop along the reverse of the path 135 taken by the DREQ message to the LAST-HOP, and thence to the 136 requester. The direct return is faster and more efficient, but the 137 hop-by-hop reverse-path route may be the only choice if the packets 138 have to cross firewalls. Hop-by-hop return is accomplished using an 139 optional ROUTE object, which is built incrementally to contain a list 140 of node addresses that the DREQ packet has passed through. The ROUTE 141 object is then used in reverse as a source route to forward the DREP 142 hop-by-hop back to the LAST-HOP node. 144 A DREQ message always consists of a single unfragmented IP datagram. 145 On the other hand, one DREQ message can generate multiple DREP 146 packets, each containing a fragment of the total DREQ message. When 147 the path consists of many hops, the total length of a DREP message 148 will exceed the MTU size before reaching the sender; thus, the 149 message has to be fragmented. Relying on IP fragmentation and 150 reassembly, however, can be problematic, especially when DREP 151 messages are returned to the requester hop-by-hop, in which case 152 fragmentation/reassembly would have to be performed at every hop. To 153 avoid such excessive overhead, we let the requester define a default 154 path MTU size that is carried in every DREQ packet. If an 155 intermediate node finds that the default MTU size is bigger than the 156 MTU of the outgoing link, it returns the DREQ packet with the 157 corresponding error bit set. If an intermediate node detects that a 158 DREQ packet size has reached the MTU size, it returns to the 159 requester (in either manner described above) a DREP fragment 160 containing accumulated responses. It then removes these responses 161 from the DREQ and continues to forward it. The requester node can 162 reassemble the resulting DREP fragments into a complete DREP message. 164 When discussing diagnostic packet handling, this document uses 165 direction terminology that is consistent with the RSVP functional 166 specification [RSVP], relative to the direction of data packet flow. 167 Thus, a DREQ packet enters a node through an "outgoing interface" and 168 is forwarded towards the sender through an "incoming interface", 169 because DREQ packets travel in the reverse direction to the data 170 flow. 172 Notice that DREQ packets can be forwarded only after the RSVP path 173 state has been set up. If no path state exists, one may resort to 174 the traceroute or mtrace facility to examine whether the 175 unicast/multicast routing is working correctly. 177 3. Diagnostic Packet Format 179 Like other RSVP messages, DREQ and DREP messages consist of an RSVP 180 Common Header followed by a variable set of typed RSVP data objects. 181 The following sequence must be used: 183 +-----------------------------------+ 184 | RSVP Common Header | 185 +-----------------------------------+ 186 | Session object | 187 +-----------------------------------+ 188 | DIAGNOSTIC object | 189 +-----------------------------------+ 190 | (optional) DIAG_SELECT object | 191 +-----------------------------------+ 192 | (optional) ROUTE object | 193 +-----------------------------------+ 194 | zero or more DIAG_RESPONSE objects| 195 +-----------------------------------+ 197 The session object identifies the RSVP session for which the state 198 information is being collected. We describe each of the other parts. 200 3.1. RSVP Message Common Header 202 The RSVP message common header is defined in [RSVP]. The following 203 specific exceptions and extensions are needed for DREP and DREQ. 205 Type field: define: 207 Type = 8: DREQ Diagnostic Request 209 Type = 9: DREP Diagnostic Reply 211 RSVP length: 213 If this is a DREP message and the MF flag in the DIAGNOSE object 214 (see below) is set, this field indicates the length of this single 215 DREP fragment rather than the total length of the complete DREP 216 reply message (which cannot generally be known in advance). 218 3.2. DIAGNOSTIC Object 220 A DIAGNOSTIC object contains the common diagnostic control 221 information in both DREQ and DREP messages. 223 o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Max-RSVP-hops | RSVP-hop-count| Reserved |H|MF| 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Request ID | 229 +---------------+---------------+---------------+---------------+ 230 | Path MTU | Fragment offset | 231 +---------------+---------------+---------------+---------------+ 232 | | 233 | SENDER_TEMPLATE object | 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | LAST-HOP Address | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 | Requester FILTER_SPEC object | 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 | Next-Hop RSVP_HOP Object | 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Here all IP addresses use the 4 byte IPv4 format, both explicitly in 248 the LAST-HOP Address and by using the IPv4 forms of the embedded 249 FILTER_SPEC and RSVP_HOP objects. 251 o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2 253 The format is the same, except all explicit and embedded IP addresses 254 are 16 byte IPv6 addresses. 256 The fields are as follows: 258 Max-RSVP-hops 260 An octet specifying the maximum number of RSVP hops over which 261 information will be collected. If an error condition in the 262 middle of the path prevents the DREQ packet from reaching the 263 specified ending node, the Max-RSVP-hops field may be used to 264 perform an expanding-length search to reach the point just before 265 the problem. If this value is 1, the LAST-HOP node and the ending 266 node will be the same. If it is zero, there is no hop limit. 268 RSVP-hop-count 270 Records the number of RSVP hops that have been traversed so far. 271 If LAST-HOP and ending nodes are the same, this value will be 1 in 272 the resulting DREP message. 274 Fragment Offset 276 Indicates where this DREP fragment belongs in the complete DREP 277 message, measured in octets. The first fragment has offset zero. 278 Ignored in a DREQ message. 280 H flag 282 Indicates how the reply should be returned. When H = 0, DREP 283 packets should be sent to the response address directly. If H = 284 1, DREP packets must be returned hop-by-hop along the reverse path 285 to the LAST-HOP node and thence to the requester node. 287 MF flag 289 Flag means "more fragments". It must be set to zero (0) in all 290 DREQ messages. It must be set to one (1) in all DREP packets that 291 carry partial results and are returned by intermediate nodes due 292 to the MTU limit. When the DREQ message is converted to a DREP 293 message in the ending node, the MF flag must remain zero. 295 Request ID 297 Identifies an individual DREQ message and the corresponding DREP 298 message (or all the fragments of the reply message). 300 One possible way to defining the Request ID would use 16 bits to 301 specify the ID of the process making the query and 16 bits to 302 distinguish different queries from this process. 304 Path MTU 306 Specifies a default MTU size in octets for DREP and DREQ messages. 308 SENDER_TEMPLATE object 310 This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and 311 the port of a sender for the session being diagnosed. The DREQ 312 packet is forwarded hop-by-hop towards this address. 314 LAST-HOP Address 316 The IP address of the LAST-HOP node. The DREQ message starts 317 collecting information at this node and proceeds toward the 318 sender. 320 Requester FILTER_SPEC Object 322 This IPv4/IPv6 FILTER_SPEC object contains the IP address and the 323 port from which the request originated and to which the DREP 324 message(s) should be sent. 326 Next-Hop RSVP_HOP Object 328 An RSVP_HOP object carrying the IP address and LIH of the 329 interface through which the DREQ will be received. This object is 330 updated hop-by hop. It is used for the same reasons that a RESV 331 message contains an RSVP_HOP object: to distinguish logical 332 interfaces and avoid problems caused by routing asymmetries. 334 3.3. DIAG_SELECT Object 336 o DIAG_SELECT Class = 33, C-Type = 0. 338 A Diagnostic message may optionally contain a DIAG_SELECT object to 339 specify which specific RSVP objects should be reported in a 340 DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the 341 DIAG_RESPONSE object added by the node will contain a default set of 342 object types (see DIAG_RESPONSE object below). 344 The DIAG_SELECT object contains a list of [Class, C-type] pairs, in 345 the following format: 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | class | C-Type | class | C-Type | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 // // 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | class | C-Type | class | C-Type | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 When a DIAG_SELECT object is included in a DREQ message, each RSVP 356 node along the path will add a DIAG_RESPONSE object containing 357 response objects (see below) whose classes and C-Types match entries 358 in the DIAG_SELECT list (and are from matching path and reservation 359 state). A C-type octet of zero is a 'wildcard', matching any C-Type 360 associated with the associated class. 362 If the number of [Class, C-Type] pairs is odd, the last two octets of 363 the DIAG_SELECT object must be zero. 365 3.4. ROUTE Object 367 A diagnostic message may contain a ROUTE object, which is used to 368 record the route of the DREQ message and as a source route for 369 returning the DREP message(s) hop-by-hop. 371 o IPv4 ROUTE object: Class = 31, C-Type = 1. 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | reserved | R-pointer | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 + RSVP Node List | 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 RSVP Node List 383 A list of RSVP node IPv4 addresses. The number of addresses in 384 this list can be computed from the object size. 386 R-pointer 388 Used in DREP messages only (see Section 4.2 for details), but it 389 is incremented as each hop adds its incoming interface address in 390 the ROUTE object. 392 o IPv6 ROUTE object: Class = 31, C-Type = 2 394 The same, except RSVP Node List contains IPv6 addresses. 396 In a DREQ message, RSVP Node List specifies all RSVP hops between the 397 LAST-HOP address specified in the DIAGNOSTIC object, and the last 398 RSVP node the DREQ message has visited. In a DREP message, RSVP Node 399 List specifies all RSVP hops between the LAST-HOP and the node that 400 returns this DREP message. 402 3.5. DIAG_RESPONSE Object 404 Each RSVP node attaches DIAG_RESPONSE object to each DREQ message it 405 receives, before forwarding the message. The DIAG_RESPONSE object 406 contains the state to be reported for this node. It has a fixed- 407 format header and then a variable list of RSVP state objects, or 408 "response objects". 410 o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1. 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | DREQ Arrival Time | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Incoming Interface Address | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Outgoing Interface Address | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Previous-RSVP-Hop Router Address | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | D-TTL |M|R-err| K | Timer value | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | 424 | (optional) TUNNEL object | 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 // Response objects // 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2. 434 This object has the same format, except that all explicit and 435 embedded IP addresses are IPv6 addresses. 437 The fields are as follows: 439 DREQ Arrival Time 441 A 32-bit NTP timestamp specifying the time the DREQ message 442 arrived at this node. The 32-bit form of an NTP timestamp 443 consists of the middle 32 bits of the full 64-bit form, that is, 444 the low 16 bits of the integer part and the high 16 bits of the 445 fractional part. 447 Incoming Interface Address 449 Specifies the IP address of the interface on which messages from 450 the sender are expected to arrive, or 0 if unknown. 452 Outgoing Interface Address 454 Specifies the IP address of the interface through which the DREQ 455 message arrived and to which messages from the given sender and 456 for the specified session address flow, or 0 if unknown. 458 Previous-RSVP-Hop Router Address 460 Specifies the node from which this node receives RSVP PATH 461 messages for this source, or 0 if unknown. This is also the 462 interface through which the DREQ will be forwarded. 464 D-TTL 466 The number of IP hops this DREQ message traveled from the down- 467 stream RSVP node to the current node. 469 M flag 471 A single-bit flag which indicates whether the reservation 472 described by the response objects, is merged with reservations 473 from other downstream interfaces when being forwarded upstream. 475 R-error 477 A 3-bit field that indicates error conditions at a node. 478 Currently defined values are: 480 0x00: no error 481 0x01: no PATH state 482 0x02: MTU too big 483 0x04: ROUTE object too big 485 K 487 The refresh timer multiple (defined in RSVP spec). 489 Timer value 490 The local refresh timer value in seconds. 492 The set of response objects to be included at the end of the 493 DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is 494 present. If no DIAG_SELECT object is present, the response objects 495 belong to the default list of classes: 497 SENDER_TSPEC object FILTER_SPEC object 498 FLOWSPEC object STYLE object 500 Any C-Type present in the local RSVP state will be used. These 501 response objects may be in any order but they must all be at the end 502 of the DIAG_RESPONSE object. 504 3.6. TUNNEL Object 506 The optional TUNNEL object should be inserted when a DREQ message 507 arrives at an RSVP node that acts as a tunnel exit point. 509 The TUNNEL object provides mapping between the end-to-end RSVP 510 session that is being diagnosed and the RSVP session over the tunnel. 511 This mapping information allows the diagnosis client to conduct 512 diagnosis over the involved tunnel session, by invoking a separate 513 Diagnostic query for the corresponding Tunnel Session and Tunnel 514 Sender. Keep in mind, however, that multiple end-to-end sessions may 515 all map to one pre-configured tunnel session that may have totally 516 different parameter settings. 518 The tunnel object is defined in the RSVP Tunnel Specification 519 [RSVPTUN]. 521 4. Diagnostic Packet Forwarding Rules 523 4.1. DREQ Packet Forwarding 525 DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP 526 address to the Sender address, as specified in the DIAGNOSTIC object. 527 At each hop, the following processing is performed before the DREQ 528 message is forwarded to the next hop towards the sender: 530 1. Compute the IP hop count from the previous RSVP hop. This is 531 done by subtracting the value of the TTL value in the IP header 532 from Send_TTL in the RSVP common header. Save the result in the 533 D-TTL field of the DIAG_RESPONSE object. 535 2. If no PATH state exists for the specified session, set R-error = 536 0x01 in the DIAG_RESPONSE object. 538 3. If the path MTU value is too large, set "MTU too large" error 539 bit, and change the MTU value to the MTU value of the incoming 540 interface for the sender. 542 4. Attach the DIAG_RESPONSE object to the end of the DREQ message, 543 and append response objects that describe the reservation in 544 place at the Outgoing Interface for the specified session. 546 If the DREQ message contains a DIAG_SELECT object, the response 547 object classes are those specified in the DIAG_SELECT; 548 otherwise, they are SENDER_TSPEC, FILTER_SPEC, STYLE, and 549 FLOWSPEC objects. If no reservation state exists for the 550 specified RSVP session, the DIAG_RESPONSE object will contain no 551 FILTER_SPEC or FLOWSPEC or STYLE object. If neither PATH nor 552 reservation state exists for the specified RSVP session, then no 553 response objects will be appended to the DIAG_RESPONSE object. 555 5. Increment the RSVP-hop-count field in the diagnostic message 556 header by one. 558 If the resulting value is equal to Max-RSVP-hops, or if the 559 current hop is the sender as identified by the Sender 560 FILTER_SPEC object field in the DIAGNOSTIC object, go to 561 Send_DREP(), and then return. 563 6. If any error bit is set, change the type field in RSVP common 564 header from DREQ to DREP, recompute the checksum, and send the 565 message back to the requester. It is sent either hop-by-hop to 566 the LAST-HOP address (if H = 1), or directly to the requester 567 address (if H = 0). 569 7. If the resulting DREQ message size exceeds the MTU limit, minus 570 some margin to hold the address list object as described below, 571 go to Send_DREP(). 573 8. If no error bit set, then if the H-bit is set, append the 574 "Incoming Interface Address" to the end of the ROUTE object, 575 increment R-Pointer by one, update the Next-Hop RSVP_HOP object 576 to be the Previous Hop from the Path State and update the 577 message length field in the RSVP common header accordingly. 578 Finally, forward the DREQ message to the next hop towards the 579 source, after recomputing the checksum. 581 Send_DREP(): 583 1. If the H flag is off in the DIAGNOSTIC object, set 584 target=response address given in the DREQ header, else set 585 target = the last address in ROUTE. 587 2. Make a copy of the DREQ message and change the type field in 588 RSVP common header from DREQ to DREP. If this host is not the 589 source, set the MF flag on. 591 If the ROUTE object is so large such that (size of ROUTE + size 592 of DIAG_RESPONSE object) > path MTU, then set the "route too 593 big" error bit, recompute the checksum, send the response 594 message and go to 4, else recompute the checksum and send the 595 response message. 597 3. If this host is not the source, then trim off all the 598 DIAG_RESPONSE objects from the original DREQ message, adjust the 599 "Fragment offset" value in the RSVP common header accordingly, 600 recompute the checksum, and forward the modified DREQ message 601 towards the source. 603 4. Return. 605 4.2. DREP Forwarding 607 When the H flag is off, DREP messages are sent directly to the 608 original requester. When H flag is on, however, they are forwarded 609 hop-by-hop towards the requester, by reversing the route as listed in 610 the Route object. 612 When a node receives a DREP message, it simply decreases R-pointer by 613 one (address length), and forwards the message to the address pointed 614 by R-pointer in the route list. 616 When the LAST-HOP node receives a DREP message, it sends the message 617 to the Response address. 619 4.3. MTU Selection and Adjustment 621 Because the DREQ message carries the allowed MTU size of previous 622 hops that the DREP messages will later traverse, this unique feature 623 allows the easy semantic fragmentation as described above. Whenever 624 the DREQ message grows to approach the size of MTU, it can be trimmed 625 before being forwarded again. 627 When a requester sends a DREQ message, the path MTU field in the RSVP 628 Diagnostic Packet header can be set to a configured default value. 630 Whenever a DREQ message size approaches the specified MTU value, an 631 intermediate RSVP node makes a copy of the message, converts it to a 632 DREP message to send back, and then trims off the partial results 633 from DREQ message and forwards it. 635 It is possible that the original MTU value is chosen larger than the 636 actual MTU value along some portion of the path being traced. 637 Therefore each intermediate RSVP node must check the MTU value when 638 processing a DREQ message. If the specified MTU value is larger than 639 the MTU of the incoming interface (that the DREQ message will be 640 forwarded to), the node 642 (1) sets the R-error value, 643 (2) changes the MTU value in the header to the smaller value, and 644 (3) converts the DREQ message to a DREP and sends it back to the 645 requester. 647 In the rare case where some intermediate nodes do not check, or 648 enforce upon, the MTU value carried in the diagnostic messages, it is 649 possible that on the way back to the requester, a DREP message may 650 encounter a link of smaller MTU. 652 When this happens, the node follows steps (1) and (2) as outlined 653 above, and trims off the extra part of the DREP message to fit in the 654 smaller MTU of the link. The trimming must be done at response 655 object boundaries. Such trimming of messages results in information 656 loss. However because the requester learns what is the available MTU 657 size, it can either ignore the loss, or otherwise try again with the 658 smaller MTU value. 660 4.4. Errors 662 If an error condition prevents a DREP message from being forwarded 663 further, the message is simply dropped. 665 If an error condition, such as lack of PATH state, prevents a DREQ 666 message from being forwarded further, the node must change the 667 current message to DREP type and return it to the response address. 669 5. Problem Diagnosis by Using RSVP Diagnostic Facility 671 5.1. Across Firewalls 673 Firewalls may cause problems in diagnostic message forwarding. Let 674 us look at two different cases. 676 First, let us assume that the querier resides on a receiving host of 677 the session to be examined. In this case, firewalls should not 678 prevent the forwarding of the diagnostic messages in a hop-by-hop 679 manner, assuming that proper holes have been punched on the firewall 680 to allow hop-by-hop forwarding of other RSVP messages. The querier 681 may start by setting the H flag off, which can give a faster response 682 delivery and reduced overhead at intermediate nodes. However if no 683 response is received, the querier may resend the DREQ message with H 684 flag turned on. 686 If the requester is a third party host and is separated from the 687 LAST-HOP address by a firewall (either the requester is behind a 688 firewall, or the LAST-HOP is a node behind a firewall, or both), at 689 this time we do not know any other solution but to change the LAST- 690 HOP to a node that is on the same side of the firewall as the 691 requester. 693 5.2. Examination of RSVP Timers 695 One can easily collect information about the current timer value at 696 each RSVP hop along the way. This will be very helpful in situations 697 when the reservation state goes up and down frequently, to find out 698 whether the state changes are due to improper setting of timer 699 values, or K values (when across lossy links), or frequent routing 700 changes. 702 5.3. Discovering Non-RSVP Clouds 704 The D-TTL field in each DIAG_RESPONSE object shows the number of 705 routing hops between adjacent RSVP nodes. Therefore any value 706 greater than one indicates a non-RSVP clouds in between. Together 707 with the arrival timestamps (assuming NTP works), this value can also 708 give some vague, though not necessarily accurate, indication of how 709 big that cloud might be. One might also find out all the 710 intermediate non-RSVP nodes by running either unicast or multicast 711 trace route. 713 5.4. Discovering Reservation Merges 715 The flowspec value in a DIAG_RESPONSE object specifies the amount of 716 resources being reserved for the data stream defined by the filter 717 spec in the same data block. When this value of adjacent 718 DIAG_RESPONSE objects differs, that is, a downstream node Rd has a 719 smaller value than its immediate upstream node Ru, it indicates a 720 merge of reservation with RSVP request(s) from other down stream 721 interface(s) at Rd. Further, in case of SE style reservation, one 722 can examine how the different SE scopes get merged at each hop. 724 In particular, if a receiver sends a DREQ message before sending its 725 own reservation, it can discover (1) how many RSVP hops there are 726 along the path between the specified sender and itself, (2) how many 727 of the hops already have some reservation by other receivers, and (3) 728 possibly a rough prediction of how its reservation request might get 729 merged with other existing ones. 731 5.5. Error Diagnosis 733 In addition to examining the state of a working reservation, RSVP 734 diagnostic messages are more likely to be invoked when things are not 735 working correctly. For example, a receiver has reserved an adequate 736 pipe for a specified incoming data stream, yet the observed delay or 737 loss ratio is much higher than expected. In this case the receiver 738 can use the diagnostic facility to examine the reservation state at 739 each RSVP hop along the way to find out whether the RSVP state is set 740 up correctly, whether there is any blackhole along the way that 741 caused RSVP message losses, or whether there are non-RSVP clouds, and 742 where they are, that may have caused the performance problem. 744 5.6. Crossing "Legacy" RSVP Routers 746 Since this diagnosis facility was developed and added to RSVP after a 747 number of RSVP implementations were in place, it is possible, or even 748 likely, that when performing RSVP diagnosis, one may encounter one or 749 more RSVP-capable nodes that do not understand diagnostic messages 750 and drop them. When this happens, the invoking client will get no 751 response from its requests. 753 One way to by-pass such "legacy" RSVP nodes is to perform RSVP 754 diagnosis repeatedly, guided by information from traceroute, or 755 mtrace in case of multicast. When an RSVP diagnostic query times out 756 (see next section), one may first use traceroute to get the list of 757 nodes along the path, and then gradually increase the value of Max- 758 RSVP-hops field in the DREQ message, starting from a low value until 759 one no longer receives a response. One can then try RSVP diagnosis 760 again by starting with the first node (which is further upstream 761 towards the sender) after the unresponding one. 763 There are two problem with the method mentioned above in the case of 764 unicast sessions. Both problems are related to the fact that 765 traceroute information provides the path from the requester to the 766 sender. The first problem is that the LAST_HOP may not on the path 767 from the requester to the sender. In this case we can get information 768 only from the portion of the path from the LAST_HOP to the sender 769 which intersects with the path from the requester to the sender. If 770 routers that are not on the intersection of the two paths don't have 771 PATH state for the session being diagnosed then they will reply with 772 R-error=0x01. The requester can overcome this problem by sending a 773 DREQ to every router on the path (from itself to the sender) until it 774 reaches the first router that belongs to the path from the sender to 775 the LAST_HOP. 777 The second problem is that traceroute provides the path from the 778 requester to the sender which, due to routing asymmetries, may be 779 different than the path traffic from the sender to the LAST_HOP uses. 780 There are (at least) one case where this asymmetry will cause the 781 diagnosis to fail. We present this case below. 783 Downstream Path Sender 784 __ __ __ __ 785 Receiver +------| |<------| |<-- ...---| |-----| | 786 __ __ / |__| |__| |__| |__| 787 | |--....--|X |_/ ^ 788 |__| |__| Router B | 789 Black __ | 790 Hole +----->| |---->---+ 791 |__| Upstream Path 793 Router A 795 Figure 2 797 Here the first hop upstream of the black hole is different on the 798 upstream path and the downstream path. Traceroute will indicate 799 router A as the previous hop (instead of router B which is the right 800 one). Sending a DREQ to router A will result in A responding with R- 801 error 0x01 (No PATH State). If the two paths converge again then the 802 requester can use the solution proposed above to get any (partial) 803 information from the rest of the path. 805 We don't have, for the moment, any complete solutions for the 806 problematic scenarios described here. 808 6. Comments on Diagnostic Client Implementation. 810 Following the design principle that nodes in the network should not 811 hold more than necessary state, RSVP nodes are responsible only for 812 forwarding Diagnostic messages and filling DIAG_RESPONSE objects. 813 Additional diagnostic functionality should be carried out by the 814 diagnostic clients. Furthermore, if the diagnostic function is 815 invoked from a third-party host, we should not require that host be 816 running RSVP daemon to perform the function. Below we sketch out the 817 basic functions that a diagnostic client daemon should carry out. 819 1. Take input from the user about the session to be diagnosed, the 820 last-hop and the sender address, the Max-RSVP-hops, and possibly 821 the DIAG_SELECT list, create a DREQ message and send to the 822 LAST-HOP RSVP node using raw IP message with protocol number 46 823 (RSVP). The port of the UDP socket on which the Diagnostic 824 Client is listening for replies should be included in the 825 Requester FILTER_SPEC object. 827 2. Set a retransmission timer, waiting for the reply (one or more 828 DREP messages). Listen to the specified UDP port for responses 829 from the LAST-HOP RSVP node. 831 The LAST-HOP RSVP node, upon receiving DREP messages, sends them 832 to the the Diagnostic Client as UDP packets, using the port 833 supplied in the Requester FILTER_SPEC object. 835 3. Upon receiving a DREP message to an outstanding diagnostic 836 request, the client should clear the retransmission timer, check 837 to see if the reply contains the complete result of the 838 requested diagnosis. If so, it should pass the result up to the 839 invoking entity immediately. 841 4. Reassemble DREP fragments. If the first reply to an outstanding 842 diagnostic request contains only a fragment of the expected 843 result, the client should set up a reassembly timer in a way 844 similar to IP packet reassembly timer. If the timer goes off 845 before all fragments arrive, the client should pass the partial 846 result to the invoking entity. 848 5. Use retransmission and reassembly timers to gracefully handle 849 packet losses and reply fragment scenarios. 851 In the absence of response to the first diagnostic request, a 852 client should retransmit the request a few times. If all the 853 retransmissions also fail, the client should invoke traceroute 854 or mtrace to obtain the list of hops along the path segment to 855 be diagnosed, and then perform an iteration of diagnosis with 856 increasing hop count as suggested in Section 5.6 in order to 857 cross RSVP-capable but diagnosis-incapable nodes. 859 6. If all the above efforts fail, the client must notify the 860 invoking entity. 862 7. Security Considerations 864 RSVP Diagnostics, as any other diagnostic tool, can be a security 865 threat since it can reveal possibly sensitive RSVP state information 866 to unwanted third parties. 868 We feel that the threat is minimal, since as explained in the 869 Introduction Diagnostics messages produce no side-effects and 870 therefore they cannot change RSVP state in the nodes. In this respect 871 RSVP Diagnostics is less a security threat than other diagnostic 872 tools and protocols such as SNMP. 874 Furthermore, processing of Diagnostic messages can be disabled if it 875 is felt that is a security threat. 877 8. Acknowledgments 879 The idea of developing a diagnostic facility for RSVP was first 880 suggested by Mark Handley of UCL. Many thanks to Lee Breslau of 881 Xerox PARC and John Krawczyk of Baynetworks for their valuable 882 comments on the first draft of this memo. Lee Breslau, Bob Braden, 883 and John Krawczyk contributed further comments after March 1996 IETF. 884 Steven Berson provided valuable comments on various drafts of the 885 memo. We would also like to acknowledge Intel for providing a 886 research grant as a partial support for this work. Subramaniam 887 Vincent did most of this work while a graduate research assistant at 888 the USC Information Sciences Institute (ISI). 890 9. References 892 [RSVPTUN] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. "RSVP 893 Operation Over IP Tunnels ", Internet Draft draft-ietf-rsvp-tunnel- 894 03.txt, August, 1998. 896 10. Authors' Addresses 898 Lixia Zhang 899 UCLA 900 4531G Boelter Hall 901 Los Angeles, CA 90095 903 Phone: 310-825-2695 904 EMail: lixia@cs.ucla.edu 906 Andreas Terzis 907 UCLA 908 4677 Boelter Hall 909 Los Angeles, CA 90095 911 Phone: 310-267-2190 912 Email: terzis@cs.ucla.edu 914 Subramaniam Vincent 915 Cisco Systems 916 275, E Tasman Drive, MS SJC04/2/1 917 San Jose, CA 95134. 918 Phone: 408 525 3474 919 Email: svincent@cisco.com 921 Bob Braden 922 USC Information Sciences Institute 923 4676 Admiralty Way 924 Marina del Rey, CA 90292 926 Phone: 310 822-1511 927 EMail: braden@isi.edu