idnits 2.17.1 draft-ietf-rsvp-diagnostic-msgs-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 390 has weird spacing: '...must be zero....' == Line 566 has weird spacing: '...rwarded hop-b...' == Line 569 has weird spacing: '...message that ...' -- 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 (April 1999) is 9143 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: 'Class' is mentioned on line 391, but not defined == Missing Reference: 'C-type' is mentioned on line 391, but not defined == Missing Reference: 'C-Type' is mentioned on line 389, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-rsvp-tunnel-02 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Andreas Terzis 3 Expires: October 1999 UCLA 4 Bob Braden 5 ISI 6 Subramaniam Vincent 7 Cisco Systems 8 Lixia Zhang 9 UCLA 10 April 1999 11 RSVP Diagnostic Messages 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies the RSVP diagnostic facility, which allows a 39 user to collect information about the RSVP state along a path. This 40 specification describes the functionality, diagnostic message 41 formats, and processing rules. 43 Changes 45 A summary of the changes from the previous version (06) of this 46 document follows: 48 -Some editorial changes were made, using input from Tim Gleeson. 49 The technical content of the document has not changed from the 50 previous version. 52 1. Introduction 54 In the basic RSVP protocol [RSVP], error messages are the only means 55 for an end host to receive feedback regarding a failure in setting up 56 either path state or reservation state. An error message carries 57 back only the information from the failed point, without any 58 information about the state at other hops before or after the 59 failure. In the absence of failures, a host receives no feedback 60 regarding the details of a reservation that has been put in place, 61 such as whether, or where, or how, its own reservation request is 62 being merged with that of others. Such missing information can be 63 highly desirable for debugging purposes, or for network resource 64 management in general. 66 This document specifies the RSVP diagnostic facility, which is 67 designed to fill this information gap. The diagnostic facility can 68 be used to collect and report RSVP state information along the path 69 from a receiver to a specific sender. It uses Diagnostic messages 70 that are independent of other RSVP control messages and produce no 71 side-effects; that is, they do not change any RSVP state at either 72 nodes or hosts. Similarly, they provide not an error report but 73 rather a collection of requested RSVP state information. 75 The RSVP diagnostic facility was designed with the following goals: 77 - To collect RSVP state information from every RSVP-capable hop 78 along a path defined by path state, either for an existing 79 reservation or before a reservation request is made. More 80 specifically, we want to be able to collect information about 81 flowspecs, refresh timer values, and reservation merging at each 82 hop along the path. 84 - To collect the IP hop count across each non-RSVP cloud. 86 - To avoid diagnostic packet implosion or explosion. 88 The following is specifically identified as a non-goal: 90 - Checking the resource availability along a path. Such 91 functionality may be useful for future reservation requests, but 92 it would require modifications to existing admission control 93 modules that is beyond the scope of RSVP. 95 2. Overview 97 The diagnostic facility introduces two new RSVP message types: 98 Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A DREQ 99 message can be originated by a client in a "requester" host, which 100 may or may not be a participant of the RSVP session to be diagnosed. 101 A client in the requester host invokes the RSVP diagnostic facility 102 by generating a DREQ packet and sending it towards the LAST-HOP node, 103 which should be on the RSVP path to be diagnosed. This DREQ packet 104 specifies the RSVP session and a sender host for that session. 105 Starting from the LAST-HOP, the DREQ packet collects information 106 hop-by-hop as it is forwarded towards the sender (see Figure 1), 107 until it reaches the ending node. Specifically, each RSVP-capable 108 hop adds to the DREQ message a response (DIAG_RESPONSE) object 109 containing local RSVP state for the specified RSVP session. 111 When the DREQ packet reaches the ending node, the message type is 112 changed to Diagnostic Reply (DREP) and the completed response is sent 113 to the original requester node. Partial responses may also be 114 returned before the DREQ packet reaches the ending node if an error 115 condition along the path, such as "no path state", prevents further 116 forwarding of the DREQ packet. To avoid packet implosion or 117 explosion, all diagnostic packets are forwarded via unicast only. 119 Thus, there are generally three nodes (hosts and/or routers) involved 120 in performing the diagnostic function: the requester node, the 121 starting node, and the ending node, as shown in Figure 1. It is 122 possible that the client invoking the diagnosis function may reside 123 directly on the starting node, in which case that the first two nodes 124 are the same. The starting node is named "LAST-HOP", meaning the 125 last-hop of the path segment to be diagnosed. The LAST-HOP node can 126 be either a receiver node or an intermediate node along the path. 127 The ending node is usually the specified sender host. However, the 128 client can limit the length of the path segment to be diagnosed by 129 specifying a hop-count limit in the DREQ message. 131 LAST-HOP Ending 132 Receiver node node Sender 133 __ __ __ __ __ 134 | |---------| |------>| |--> ...-->| |--> ...---->| | 135 |__| |__| DREQ |__| DREQ |__| DREQ |__| 136 ^ . | 137 | . | 138 | DREQ . DREP | DREP 139 | . | 140 _|_ DREP V V 141 Requester | | <------------------------------------ 142 (client) |___| 144 Figure 1 146 DREP packets can be unicast from the ending node back to the 147 requester either directly or hop-by-hop along the reverse of the path 148 taken by the DREQ message to the LAST-HOP, and thence to the 149 requester. The direct return is faster and more efficient, but the 150 hop-by-hop reverse-path route may be the only choice if the packets 151 have to cross firewalls. Hop-by-hop return is accomplished using an 152 optional ROUTE object, which is built incrementally to contain a list 153 of node addresses that the DREQ packet has passed through. The ROUTE 154 object is then used in reverse as a source route to forward the DREP 155 hop-by-hop back to the LAST-HOP node. 157 A DREQ message always consists of a single unfragmented IP datagram. 158 On the other hand, one DREQ message can generate multiple DREP 159 packets, each containing a fragment of the total DREQ message. When 160 the path consists of many hops, the total length of a DREP message 161 will exceed the MTU size before reaching the ending node; thus, the 162 message has to be fragmented. Relying on IP fragmentation and 163 reassembly, however, can be problematic, especially when DREP 164 messages are returned to the requester hop-by-hop, in which case 165 fragmentation/reassembly would have to be performed at every hop. To 166 avoid such excessive overhead, we let the requester define a default 167 path MTU size that is carried in every DREQ packet. If an 168 intermediate node finds that the default MTU size is bigger than the 169 MTU of the incoming interface, it reduces the default MTU size to the 170 MTU size of the incoming interface. If an intermediate node detects 171 that a DREQ packet size is larger than the default MTU size, it 172 returns to the requester (in either manner described above) a DREP 173 fragment containing accumulated responses. It then removes these 174 responses from the DREQ and continues to forward it. The requester 175 node can reassemble the resulting DREP fragments into a complete DREP 176 message. 178 When discussing diagnostic packet handling, this document uses 179 direction terminology that is consistent with the RSVP functional 180 specification [RSVP], relative to the direction of data packet flow. 181 Thus, a DREQ packet enters a node through an "outgoing interface" and 182 is forwarded towards the sender through an "incoming interface", 183 because DREQ packets travel in the reverse direction to the data 184 flow. 186 Notice that DREQ packets can be forwarded only after the RSVP path 187 state has been set up. If no path state exists, one may resort to 188 the traceroute or mtrace facility to examine whether the 189 unicast/multicast routing is working correctly. 191 3. Diagnostic Packet Format 193 Like other RSVP messages, DREQ and DREP messages consist of an RSVP 194 Common Header followed by a variable set of typed RSVP data objects. 195 The following sequence must be used: 197 +-----------------------------------+ 198 | RSVP Common Header | 199 +-----------------------------------+ 200 | Session object | 201 +-----------------------------------+ 202 | Next-Hop RSVP_HOP object | 203 +-----------------------------------+ 204 | DIAGNOSTIC object | 205 +-----------------------------------+ 206 | (optional) DIAG_SELECT object | 207 +-----------------------------------+ 208 | (optional) ROUTE object | 209 +-----------------------------------+ 210 | zero or more DIAG_RESPONSE objects| 211 +-----------------------------------+ 213 The session object identifies the RSVP session for which the state 214 information is being collected. We describe each of the other parts. 216 3.1. RSVP Message Common Header 218 The RSVP message common header is defined in [RSVP]. The following 219 specific exceptions and extensions are needed for DREP and DREQ. 221 Type field: define: 223 Type = 8: DREQ Diagnostic Request 225 Type = 9: DREP Diagnostic Reply 227 RSVP length: 229 If this is a DREP message and the MF flag in the DIAGNOSTIC object 230 (see below) is set, this field indicates the length of this single 231 DREP fragment rather than the total length of the complete DREP 232 reply message (which cannot generally be known in advance). 234 3.2. Next-Hop RSVP_HOP Object 236 This RSVP_HOP object carries the LIH of the interface through which 237 the DREQ should be received at the upstream node. This object is 238 updated hop-by hop. It is used for the same reasons that a RESV 239 message contains an RSVP_HOP object: to distinguish logical 240 interfaces and avoid problems caused by routing asymmetries and non- 241 RSVP clouds. 243 While the IP address is not really used during DREQ processing , for 244 consistency with the use of the RSVP_HOP object in other RSVP 245 messages, the IP address in the RSVP_HOP object to contain the 246 address of the interface through which the DREQ was sent. 248 3.3. DIAGNOSTIC Object 250 A DIAGNOSTIC object contains the common diagnostic control 251 information in both DREQ and DREP messages. 253 o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Max-RSVP-hops | RSVP-hop-count| Reserved |MF| 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Request ID | 258 +---------------+---------------+---------------+---------------+ 259 | Path MTU | Fragment Offset | 260 +---------------+---------------+---------------+---------------+ 261 | LAST-HOP Address | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 | SENDER_TEMPLATE object | 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 | Requester FILTER_SPEC object | 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Here all IP addresses use the 4 byte IPv4 format, both explicitly in 273 the LAST-HOP Address and by using the IPv4 forms of the embedded 274 FILTER_SPEC and RSVP_HOP objects. 276 o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2 278 The format is the same, except all explicit and embedded IP addresses 279 are 16 byte IPv6 addresses. 281 The fields are as follows: 283 Max-RSVP-hops 285 An octet specifying the maximum number of RSVP hops over which 286 information will be collected. If an error condition in the 287 middle of the path prevents the DREQ packet from reaching the 288 specified ending node, the Max-RSVP-hops field may be used to 289 perform an expanding-length search to reach the point just before 290 the problem. If this value is 1, the starting node and the ending 291 node of the query will be the same. If it is zero, there is no 292 hop limit. 294 RSVP-hop-count 296 Records the number of RSVP hops that have been traversed so far. 297 If the starting and ending nodes are the same, this value will be 298 1 in the resulting DREP message. 300 Fragment Offset 302 Indicates where this DREP fragment belongs in the complete DREP 303 message, measured in octets. The first fragment has offset zero. 304 Fragment Offset is used to determine if a DREQ message containing 305 zero DIAG_RESPONSE objects should be processed at an RSVP capable 306 node. 308 MF flag 310 Flag means "more fragments". It must be set to zero (0) in all 311 DREQ messages. It must be set to one (1) in all DREP packets that 312 carry partial results and are returned by intermediate nodes due 313 to the MTU limit. When the DREQ message is converted to a DREP 314 message in the ending node, the MF flag must remain zero. 316 Request ID 318 Identifies an individual DREQ message and the corresponding DREP 319 message (or all the fragments of the reply message). 321 One possible way to define the Request ID would use 16 bits to 322 specify the ID of the process making the query and 16 bits to 323 distinguish different queries from this process. 325 Path MTU 327 Specifies a default MTU size in octets for DREP and DREQ messages. 328 This value should not be smaller than the size of the "base" DREQ 329 packet. A "base" DREQ packet is one that contains a Common Header, 330 a Session object , a Next-Hop RSVP_HOP object, a DIAGNOSTIC 331 object, an empty ROUTE object and a single default DIAG_RESPONSE 332 (see below). The assumption made here is that a diagnostic packet 333 of this size can always be forwarded without being fragmented. 335 LAST-HOP Address 337 The IP address of the LAST-HOP node. The DREQ message starts 338 collecting information at this node and proceeds toward the 339 sender. 341 SENDER_TEMPLATE object 343 This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and 344 the port of a sender for the session being diagnosed. The DREQ 345 packet is forwarded hop-by-hop towards this address. 347 Requester FILTER_SPEC Object 349 This IPv4/IPv6 FILTER_SPEC object contains the IP address and the 350 port from which the request originated and to which the DREP 351 message(s) should be sent. 353 3.4. DIAG_SELECT Object 355 o DIAG_SELECT Class = 33, C-Type = 0. 357 A Diagnostic message may optionally contain a DIAG_SELECT object to 358 specify which specific RSVP objects should be reported in a 359 DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the 360 DIAG_RESPONSE object added by the node will contain a default set of 361 object types (see DIAG_RESPONSE object below). 363 The DIAG_SELECT object contains a list of [Class, C-type] pairs, in 364 the following format: 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | class | C-Type | class | C-Type | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 // // 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | class | C-Type | class | C-Type | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 When a DIAG_SELECT object is included in a DREQ message, each RSVP 375 node along the path will add a DIAG_RESPONSE object containing 376 response objects (see below) whose classes and C-Types match entries 377 in the DIAG_SELECT list (and are from matching path and reservation 378 state). A C-type octet of zero is a 'wildcard', matching any C-Type 379 associated with the associated class. 381 Depending on the type of objects requested, a node can find the 382 associated information in the path or reservation state stored for 383 the session described in the SESSION object. Specifically, 384 information for the RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC 385 and FILTER_SPEC objects can be extracted from the node's path state, 386 while information for the FLOWSPEC, CONFIRM, STYLE and SCOPE objects 387 can be found in the node's reservation state (if existent). 389 If the number of [Class, C-Type] pairs is odd, the last two octets of 390 the DIAG_SELECT object must be zero. A maximum DIAG_SELECT object is 391 one that contains the [Class, C-type] pairs for all the RSVP objects 392 that can be requested in a Diagnostic query. 394 3.5. ROUTE Object 396 A diagnostic message may contain a ROUTE object, which is used to 397 record the route of the DREQ message and as a source route for 398 returning the DREP message(s) hop-by-hop. 400 o IPv4 ROUTE object: Class = 31, C-Type = 1. 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | reserved | R-pointer | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | 406 + RSVP Node List | 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 This message signifies how the reply should be returned. If it does 411 not exist in the DREQ packet then DREP packets should be sent to the 412 requester directly. If it does exist, DREP packets must be returned 413 hop-by-hop along the reverse path to the LAST-HOP node and thence to 414 the requester node. 416 An empty ROUTE object is one that has an empty RSVP Node list and R- 417 pointer is equal to zero. 419 RSVP Node List 421 A list of RSVP node IPv4 addresses. The number of addresses in 422 this list can be computed from the object size. 424 R-pointer 426 Used in DREP messages only (see Section 4.2 for details), but it 427 is incremented as each hop adds its incoming interface address in 428 the ROUTE object. 430 o IPv6 ROUTE object: Class = 31, C-Type = 2 432 The same, except RSVP Node List contains IPv6 addresses. 434 In a DREQ message, RSVP Node List specifies all RSVP hops between the 435 LAST-HOP address specified in the DIAGNOSTIC object, and the last 436 RSVP node the DREQ message has visited. In a DREP message, RSVP Node 437 List specifies all RSVP hops between the LAST-HOP and the node that 438 returns this DREP message. 440 3.6. DIAG_RESPONSE Object 442 Each RSVP node attaches a DIAG_RESPONSE object to each DREQ message 443 it receives, before forwarding the message. The DIAG_RESPONSE object 444 contains the state to be reported for this node. It has a fixed- 445 format header and then a variable list of RSVP state objects, or 446 "response objects". 448 o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1. 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | DREQ Arrival Time | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Incoming Interface Address | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Outgoing Interface Address | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Previous-RSVP-Hop Router Address | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | D-TTL |M|R-err| K | Timer value | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 | (optional) TUNNEL object | 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | 466 // Response objects // 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2. 472 This object has the same format, except that all explicit and 473 embedded IP addresses are IPv6 addresses. 475 The fields are as follows: 477 DREQ Arrival Time 478 A 32-bit NTP timestamp specifying the time the DREQ message 479 arrived at this node. The 32-bit form of an NTP timestamp 480 consists of the middle 32 bits of the full 64-bit form, that is, 481 the low 16 bits of the integer part and the high 16 bits of the 482 fractional part. 484 Incoming Interface Address 486 Specifies the IP address of the interface on which messages from 487 the sender are expected to arrive, or 0 if unknown. 489 Outgoing Interface Address 491 Specifies the IP address of the interface through which the DREQ 492 message arrived and to which messages from the given sender and 493 for the specified session address flow, or 0 if unknown. 495 Previous-RSVP-Hop Router Address 497 Specifies the IP address from which this node receives RSVP PATH 498 messages for this source, or 0 if unknown. This is also the 499 interface to which the DREQ will be forwarded. 501 D-TTL 503 The number of IP hops this DREQ message traveled from the down- 504 stream RSVP node to the current node. 506 M flag 508 A single-bit flag which indicates whether the reservation 509 described by the response objects is merged with reservations from 510 other downstream interfaces when being forwarded upstream. 512 R-error 514 A 3-bit field that indicates error conditions at a node. Currently 515 defined values are: 517 0x00: no error 518 0x01: No PATH state 519 0x02: packet too big 520 0x04: ROUTE object too big 522 K 524 The refresh timer multiple (defined in [RSVP]). 526 Timer value 528 The local refresh timer value in seconds. 530 The set of response objects to be included at the end of the 531 DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is 532 present. If no DIAG_SELECT object is present, the response objects 533 belong to the default list of classes: 535 SENDER_TSPEC object FILTER_SPEC object 536 FLOWSPEC object STYLE object 538 Any C-Type present in the local RSVP state will be used. These 539 response objects may be in any order but they must all be at the end 540 of the DIAG_RESPONSE object. 542 A default DIAG_RESPONSE object is one containing the default list of 543 classes described above. 545 3.7. TUNNEL Object 547 The optional TUNNEL object should be inserted when a DREQ message 548 arrives at an RSVP node that acts as a tunnel exit point. 550 The TUNNEL object provides the mapping between the end-to-end RSVP 551 session that is being diagnosed and the RSVP session over the tunnel. 552 This mapping information allows the diagnosis client to conduct 553 diagnosis over the involved tunnel session, by invoking a separate 554 Diagnostic query for the corresponding Tunnel Session and Tunnel 555 Sender. Keep in mind, however, that multiple end-to-end sessions may 556 all map to one pre-configured tunnel session that may have totally 557 different parameter settings. 559 The tunnel object is defined in the RSVP Tunnel Specification 560 [RSVPTUN]. 562 4. Diagnostic Packet Forwarding Rules 564 4.1. DREQ Packet Forwarding 566 DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP 567 address to the Sender address, as specified in the DIAGNOSTIC object. 568 If an RSVP capable node, other than the LAST-HOP node, receives a 569 DREQ message that contains no DIAG_RESPONSE objects and has a zero 570 Fragment Offset, the node should forward the DREQ packet towards the 571 LAST-HOP without doing any of the processing mentioned below. The 572 reason is that such conditions apply only for nodes downstream of the 573 LAST-HOP where no information should be collected. 575 Processing begins when a DREQ message, DREQ_in, arrives at a node. 576 The following processing is performed before DREQ_in is forwarded: 578 1. Create a new DIAG_RESPONSE object. Compute the IP hop count from 579 the previous RSVP hop. This is done by subtracting the value of 580 the TTL value in the IP header from Send_TTL in the RSVP common 581 header. Save the result in the D-TTL field of the DIAG_RESPONSE 582 object. 584 2. Set the DREQ Arrival Time and the Outgoing Interface Address in 585 the DIAG_RESPONSE object. If this node is the LAST-HOP, then 586 the Outgoing Interface Address field in the DIAG_RESPONSE object 587 contains the following value depending on the session being 588 diagnosed. 590 * If the session in question is a unicast session, then the 591 Outgoing Interface Address field contains the address of 592 the interface LAST-HOP uses to send PATH messages and data 593 to the receiver specified by the session address. 595 * Otherwise, if it is a multicast session and there is at 596 least one receiver for this session, LAST_HOP should use 597 the address of one of local interfaces used to reach one of 598 the receivers. 600 * Otherwise Outgoing Interface Address should be zero. 602 If no PATH state exists for the specified session, set R-error = 603 0x01 (No PATH state). 605 3. Increment the RSVP-hop-count field in the DIAGNOSTIC message 606 object by one. 608 4. If the "No PATH state" bit is set, goto Send_DREP. 610 5. Set the rest of the fields in the DIAG_RESPONSE object. If 611 DREQ_in contains a DIAG_SELECT object, the response object 612 classes are those specified in the DIAG_SELECT; otherwise, they 613 are SENDER_TSPEC, FILTER_SPEC, STYLE, and FLOWSPEC objects. If 614 no reservation state exists for the specified RSVP session, the 615 DIAG_RESPONSE object will contain no FILTER_SPEC or FLOWSPEC or 616 STYLE object. If neither PATH nor reservation state exists for 617 the specified RSVP session, then no response objects will be 618 appended to the DIAG_RESPONSE object. 620 6. If RSVP-hop-count is equal to Max-RSVP-hops or this node is the 621 sender, go to Send_DREP. 623 7. If the Path MTU value is larger than the MTU size of the 624 incoming interface for the sender being diagnosed, change the 625 Path MTU value to the MTU value of the incoming interface. 627 8. If the size of DREQ_in plus the size of the new DIAG_RESPONSE 628 object plus the size of an IP address ,if a ROUTE object exists, 629 is larger than Path MTU set the "packet too big" (0x02) error 630 bit in DIAG_RESPONSE, goto Send_DREP. 632 9. If a ROUTE object exists, append the "Incoming Interface 633 Address" to the end of the ROUTE object, increment R-Pointer by 634 one, update the Next-Hop RSVP_HOP object, append the new 635 DIAG_RESPONSE object to the list of DIAG_RESPONSE object and 636 update the message length field in the RSVP common header 637 accordingly. Finally, forward DREQ_in to the next hop towards 638 the sender, after recomputing the checksum. Return. 640 Send_DREP: 642 1. If the size of DREQ_in plus the size of the new DIAG_RESPONSE 643 object plus the size of an IP address ,if a ROUTE object exists, 644 is larger than Path MTU set the "packet too big" (0x02) error 645 bit in DIAG_RESPONSE, otherwise goto step 11. 647 2. Make a copy of DREQ_in and change the type field in RSVP common 648 header from DREQ to DREP. Trim all DIAG_RESPONSE objects from 649 DREQ_in and adjust the Fragment Offset. 651 3. If a ROUTE object is present in the DREP message, decrement the 652 R-pointer and set target address to the last address in the 653 ROUTE object, otherwise set target address to the requester 654 address. Set the MF bit, recompute the checksum and send the 655 DREP message back to the target address. 657 4. If the size of DREQ_in plus the size of DIAG_RESPONSE plus the 658 size of an IP address ,if a ROUTE object exists, is smaller than 659 Path MTU goto Step 9. 661 5. Make a copy of DREQ_in and change the type field in RSVP common 662 header from DREQ to DREP. If a ROUTE object exists, replace the 663 ROUTE object in DREQ_in with an empty ROUTE object. Turn on the 664 "ROUTE object too big" (0x04) error bit in the DIAG_RESPONSE. 666 6. If the "No PATH state" (0x01) error bit is set or if RSVP-hop- 667 count is equal to Max-RSVP-hops or if this node is the sender, 668 goto Step 8. 670 7. If a ROUTE object exists, append the "Incoming Interface 671 Address" to the end of the ROUTE object, increment R-Pointer by 672 one, update the Next-Hop RSVP_HOP object, append the new 673 DIAG_RESPONSE object to the list of DIAG_RESPONSE object, update 674 the message length field in the RSVP common header accordingly 675 and adjust the Fragment Offset. Finally, forward DREQ_in to the 676 next hop towards the sender, after recomputing the checksum. 678 8. Append the DIAG_RESPONSE object to the end of DREP. Set target 679 address to the requester address. Turn on the MF bit. Update the 680 packet length, recompute the checksum in the DREP message and 681 send it towards the target address. Return 683 9. If the "No PATH state" (0x01) error bit is set or if RSVP-hop- 684 count is equal to Max-RSVP-hops or if this node is the sender, 685 goto Step 11. 687 10. If a ROUTE object exists, append the "Incoming Interface 688 Address" to the end of the ROUTE object, increment R-Pointer by 689 one, update the Next-Hop RSVP_HOP object, append the new 690 DIAG_RESPONSE object to the list of DIAG_RESPONSE object and 691 update the message length field in the RSVP common header 692 accordingly. Finally, forward DREQ_in to the next hop towards 693 the sender, after recomputing the checksum. Return. 695 11. Append the DIAG_RESPONSE object to the end of DREQ_in. If a 696 ROUTE object is present in the message, decrement the R-pointer 697 and set target address to the last address in the ROUTE object, 698 otherwise set target address to the requester address. Change 699 the Type Field in the Common header from DREQ to DREP.Update the 700 packet length, recompute the checksum in the DREP message and 701 send it towards the target address. The MF bit in this case must 702 be off. 704 4.2. DREP Forwarding 706 When a ROUTE object is present, DREP messages are forwarded hop-by- 707 hop towards the requester, by reversing the route as listed in the 708 ROUTE object. Otherwise, DREP messages are sent directly to the 709 original requester. 711 When a node receives a DREP message, it simply decreases R-pointer by 712 one (address length), recomputes the checksum and forwards the 713 message to the address pointed to by R-pointer in the route list. If 714 a node, other than the LAST-HOP, receives a DREP packet where R- 715 pointer is equal to zero, it must send it directly to the requester. 717 When the LAST-HOP node receives a DREP message, it sends the message 718 to the requester. 720 4.3. MTU Selection and Adjustment 722 Because the DREQ message carries the allowed MTU size of previous 723 hops that the DREP messages will later traverse, this unique feature 724 allows easy semantic fragmentation as described above. Whenever the 725 DREQ message approaches the size of Path MTU, it can be trimmed 726 before being forwarded again. 728 When a requester sends a DREQ message, the Path MTU field in the 729 DIAGNOSTIC object can be set to a configured default value. It is 730 possible that the original Path MTU value is chosen larger than the 731 actual MTU value along some portion of the path being traced. 732 Therefore each intermediate RSVP node must check the MTU value when 733 processing a DREQ message. If the specified MTU value is larger than 734 the MTU of the incoming interface (that the DREQ message will be 735 forwarded to), the node changes the MTU value in the header to the 736 smaller value. 738 Whenever a DREQ message size becomes larger than the Path MTU value, 739 an intermediate RSVP node makes a copy of the message, converts it to 740 a DREP message to send back, and then trims off the partial results 741 from the DREQ message. If in this case also the DREQ cannot be 742 forwarded upstream due to a large ROUTE object, the "ROUTE object too 743 big" is set and the ROUTE object is trimmed. As a result of the ROUTE 744 object trimming, DREP(s) will come hop-by-hop up to this node and 745 will then immediately be forwarded to the requester address. 747 Even if the steps shown above are followed there are a few cases 748 where fragmentation at the IP layer will happen. For example, non- 749 RSVP hops with smaller MTUs may exist before LAST-HOP is reached, or 750 if the response is sent directly back to requester (as opposed to hop 751 by hop) the DREP may take a different route to the requester than the 752 DREQ took from the requester. Another case is when there exists a 753 link with MTU smaller than the minimum Path MTU value defined in 754 Section 3.2. 756 4.4. Errors 758 If an error condition prevents a DREP message from being forwarded 759 further, the message is simply dropped. 761 If an error condition, such as lack of PATH state, prevents a DREQ 762 message from being forwarded further, the node must change the 763 current message to DREP type and return it to the response address. 765 5. Problem Diagnosis by Using RSVP Diagnostic Facility 767 5.1. Across Firewalls 769 Firewalls may cause problems in diagnostic message forwarding. Let 770 us look at two different cases. 772 First, let us assume that the querier resides on a receiving host of 773 the session to be examined. In this case, firewalls should not 774 prevent the forwarding of the diagnostic messages in a hop-by-hop 775 manner, assuming that proper holes have been punched on the firewall 776 to allow hop-by-hop forwarding of other RSVP messages. The querier 777 may start by not including a ROUTE object, which can give a faster 778 response delivery and reduced overhead at intermediate nodes. 779 However if no response is received, the querier may resend the DREQ 780 message with a ROUTE object, specifying that a hop-by-hop reply 781 should be sent. 783 If the requester is a third party host and is separated from the 784 LAST-HOP address by a firewall (either the requester is behind a 785 firewall, or the LAST-HOP is a node behind a firewall, or both), at 786 this time we do not know any other solution but to change the LAST- 787 HOP to a node that is on the same side of the firewall as the 788 requester. 790 5.2. Examination of RSVP Timers 792 One can easily collect information about the current timer value at 793 each RSVP hop along the way. This will be very helpful in situations 794 when the reservation state goes up and down frequently, to find out 795 whether the state changes are due to improper setting of timer 796 values, or K values (when across lossy links), or frequent routing 797 changes. 799 5.3. Discovering Non-RSVP Clouds 801 The D-TTL field in each DIAG_RESPONSE object shows the number of 802 routing hops between adjacent RSVP nodes. Therefore any value 803 greater than one indicates a non-RSVP cloud in between. Together 804 with the arrival timestamps (assuming NTP works), this value can also 805 give some vague, though not necessarily accurate, indication of how 806 big that cloud might be. One might also find out all the 807 intermediate non-RSVP nodes by running either unicast or multicast 808 trace route. 810 5.4. Discovering Reservation Merges 812 The flowspec value in a DIAG_RESPONSE object specifies the amount of 813 resources being reserved for the data stream defined by the filter 814 spec in the same data block. When this value of adjacent 815 DIAG_RESPONSE objects differs, that is, a downstream node Rd has a 816 smaller value than its immediate upstream node Ru, it indicates a 817 merge of reservation with RSVP request(s) from other down stream 818 interface(s) at Rd. Further, in case of SE style reservation, one 819 can examine how the different SE scopes get merged at each hop. 821 In particular, if a receiver sends a DREQ message before sending its 822 own reservation, it can discover (1) how many RSVP hops there are 823 along the path between the specified sender and itself, (2) how many 824 of the hops already have some reservation by other receivers, and (3) 825 possibly a rough prediction of how its reservation request might get 826 merged with other existing ones. 828 5.5. Error Diagnosis 830 In addition to examining the state of a working reservation, RSVP 831 diagnostic messages are more likely to be invoked when things are not 832 working correctly. For example, a receiver has reserved an adequate 833 pipe for a specified incoming data stream, yet the observed delay or 834 loss ratio is much higher than expected. In this case the receiver 835 can use the diagnostic facility to examine the reservation state at 836 each RSVP hop along the way to find out whether the RSVP state is set 837 up correctly, whether there is any blackhole along the way that 838 caused RSVP message losses, or whether there are non-RSVP clouds, and 839 where they are, that may have caused the performance problem. 841 5.6. Crossing "Legacy" RSVP Routers 843 Since this diagnosis facility was developed and added to RSVP after a 844 number of RSVP implementations were in place, it is possible, or even 845 likely, that when performing RSVP diagnosis, one may encounter one or 846 more RSVP-capable nodes that do not understand diagnostic messages 847 and drop them. When this happens, the invoking client will get no 848 response from its requests. 850 One way to by-pass such "legacy" RSVP nodes is to perform RSVP 851 diagnosis repeatedly, guided by information from traceroute, or 852 mtrace in case of multicast. When an RSVP diagnostic query times out 853 (see next section), one may first use traceroute to get the list of 854 nodes along the path, and then gradually increase the value of Max- 855 RSVP-hops field in the DREQ message, starting from a low value until 856 one no longer receives a response. One can then try RSVP diagnosis 857 again by starting with the first node (which is further upstream 858 towards the sender) after the unresponding one. 860 There are two problem with the method mentioned above in the case of 861 unicast sessions. Both problems are related to the fact that 862 traceroute information provides the path from the requester to the 863 sender. The first problem is that the LAST-HOP may not be on the path 864 from the requester to the sender. In this case we can get information 865 only from the portion of the path from the LAST-HOP to the sender 866 which intersects with the path from the requester to the sender. If 867 routers that are not on the intersection of the two paths don't have 868 PATH state for the session being diagnosed then they will reply with 869 R-error=0x01. The requester can overcome this problem by sending a 870 DREQ to every router on the path (from itself to the sender) until it 871 reaches the first router that belongs to the path from the sender to 872 the LAST-HOP. 874 The second problem is that traceroute provides the path from the 875 requester to the sender which, due to routing asymmetries, may be 876 different than the path traffic from the sender to the LAST-HOP uses. 877 There is (at least) one case where this asymmetry will cause the 878 diagnosis to fail. We present this case below. 880 Downstream Path Sender 881 __ __ __ __ 882 Receiver +------| |<------| |<-- ...---| |-----| | 883 __ __ / |__| |__| |__| |__| 884 | |--....--|X |_/ ^ 885 |__| |__| Router B | 886 Black __ | 887 Hole +----->| |---->---+ 888 |__| Upstream Path 890 Router A 892 Figure 2 894 Here the first hop upstream of the black hole is different on the 895 upstream path and the downstream path. Traceroute will indicate 896 router A as the previous hop (instead of router B which is the right 897 one). Sending a DREQ to router A will result in A responding with R- 898 error 0x01 (No PATH State). If the two paths converge again then the 899 requester can use the solution proposed above to get any (partial) 900 information from the rest of the path. 902 We don't have, for the moment, any complete solutions for the 903 problematic scenarios described here. 905 6. Comments on Diagnostic Client Implementation. 907 Following the design principle that nodes in the network should not 908 hold more than necessary state, RSVP nodes are responsible only for 909 forwarding Diagnostic messages and filling DIAG_RESPONSE objects. 910 Additional diagnostic functionality should be carried out by the 911 diagnostic clients. Furthermore, if the diagnostic function is 912 invoked from a third-party host, we should not require that host be 913 running an RSVP daemon to perform the function. Below we sketch out 914 the basic functions that a diagnostic client daemon should carry out. 916 1. Take input from the user about the session to be diagnosed, the 917 last-hop and the sender address, the Max-RSVP-hops, and possibly 918 the DIAG_SELECT list, create a DREQ message and send to the 919 LAST-HOP RSVP node using raw IP message with protocol number 46 920 (RSVP). If the user specified that the response should be sent 921 hop-by-hop include an empty ROUTE object to the DREQ message 922 sent. Set the Path_MTU to the smaller of the user request and 923 the MTU of the link through which the DREQ will be sent. 925 The port of the UDP socket on which the Diagnostic Client is 926 listening for replies should be included in the Requester 927 FILTER_SPEC object. 929 2. Set a retransmission timer, waiting for the reply (one or more 930 DREP messages). Listen to the specified UDP port for responses 931 from the LAST-HOP RSVP node. 933 The LAST-HOP RSVP node, upon receiving DREP messages, sends them 934 to the Diagnostic Client as UDP packets, using the port supplied 935 in the Requester FILTER_SPEC object. 937 3. Upon receiving a DREP message to an outstanding diagnostic 938 request, the client should clear the retransmission timer, check 939 to see if the reply contains the complete result of the 940 requested diagnosis. If so, it should pass the result up to the 941 invoking entity immediately. 943 4. Reassemble DREP fragments. If the first reply to an outstanding 944 diagnostic request contains only a fragment of the expected 945 result, the client should set up a reassembly timer in a way 946 similar to IP packet reassembly timer. If the timer goes off 947 before all fragments arrive, the client should pass the partial 948 result to the invoking entity. 950 5. Use retransmission and reassembly timers to gracefully handle 951 packet losses and reply fragment scenarios. 953 In the absence of response to the first diagnostic request, a 954 client should retransmit the request a few times. If all the 955 retransmissions also fail, the client should invoke traceroute 956 or mtrace to obtain the list of hops along the path segment to 957 be diagnosed, and then perform an iteration of diagnosis with 958 increasing hop count as suggested in Section 5.6 in order to 959 cross RSVP-capable but diagnosis-incapable nodes. 961 6. If all the above efforts fail, the client must notify the 962 invoking entity. 964 7. Security Considerations 966 RSVP Diagnostics, as any other diagnostic tool, can be a security 967 threat since it can reveal possibly sensitive RSVP state information 968 to unwanted third parties. 970 We feel that the threat is minimal, since as explained in the 971 Introduction Diagnostics messages produce no side-effects and 972 therefore they cannot change RSVP state in the nodes. In this respect 973 RSVP Diagnostics is less a security threat than other diagnostic 974 tools and protocols such as SNMP. 976 Furthermore, processing of Diagnostic messages can be disabled if it 977 is felt that is a security threat. 979 8. Acknowledgments 981 The idea of developing a diagnostic facility for RSVP was first 982 suggested by Mark Handley of UCL. Many thanks to Lee Breslau of 983 Xerox PARC and John Krawczyk of Baynetworks for their valuable 984 comments on the first draft of this memo. Lee Breslau, Bob Braden, 985 and John Krawczyk contributed further comments after March 1996 IETF. 986 Steven Berson provided valuable comments on various drafts of the 987 memo. Tim Gleeson contributed an extensive list of editorial 988 comments. We would also like to acknowledge Intel for providing a 989 research grant as a partial support for this work. Subramaniam 990 Vincent did most of this work while a graduate research assistant at 991 the USC Information Sciences Institute (ISI). 993 9. References 995 [RSVP] Braden, R. Ed. et al, "Resource ReserVation Protocol -- 996 Version 1 Functional Specification", RFC 2205, September 1997. 998 [RSVPTUN] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. "RSVP 999 Operation Over IP Tunnels ", Internet Draft. draft-ietf-rsvp-tunnel- 1000 02.txt, February, 1999. 1002 10. Authors' Addresses 1004 Andreas Terzis 1005 UCLA 1006 4677 Boelter Hall 1007 Los Angeles, CA 90095 1009 Phone: 310-267-2190 1010 Email: terzis@cs.ucla.edu 1012 Bob Braden 1013 USC Information Sciences Institute 1014 4676 Admiralty Way 1015 Marina del Rey, CA 90292 1017 Phone: 310 822-1511 1018 EMail: braden@isi.edu 1020 Subramaniam Vincent 1021 Cisco Systems 1022 275, E Tasman Drive, MS SJC04/2/1 1023 San Jose, CA 95134. 1024 Phone: 408 525 3474 1025 Email: svincent@cisco.com 1027 Lixia Zhang 1028 UCLA 1029 4531G Boelter Hall 1030 Los Angeles, CA 90095 1032 Phone: 310-825-2695 1033 EMail: lixia@cs.ucla.edu