idnits 2.17.1 draft-ietf-rsvp-diagnostic-msgs-08.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 378 has weird spacing: '...must be zero....' == Line 552 has weird spacing: '...rwarded hop-b...' == Line 555 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 (June 1999) is 9081 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 379, but not defined == Missing Reference: 'C-type' is mentioned on line 379, but not defined == Missing Reference: 'C-Type' is mentioned on line 377, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-rsvp-tunnel-02 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Andreas Terzis 2 Expires: December 1999 UCLA 3 Bob Braden 4 ISI 5 Subramaniam Vincent 6 Cisco Systems 7 Lixia Zhang 8 UCLA 9 June 1999 10 RSVP Diagnostic Messages 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document specifies the RSVP diagnostic facility, which allows a 37 user to collect information about the RSVP state along a path. This 38 specification describes the functionality, diagnostic message formats, 39 and processing rules. 41 Changes 43 A summary of the changes from the previous version (07) of this document 44 follows: 46 The processing rules have been rewritten in a more compact form. 48 1. Introduction 50 In the basic RSVP protocol [RSVP], error messages are the only means for 51 an end host to receive feedback regarding a failure in setting up either 52 path state or reservation state. An error message carries back only the 53 information from the failed point, without any information about the 54 state at other hops before or after the failure. In the absence of 55 failures, a host receives no feedback regarding the details of a reser- 56 vation that has been put in place, such as whether, or where, or how, 57 its own reservation request is being merged with that of others. Such 58 missing information can be highly desirable for debugging purposes, or 59 for network resource management in general. 61 This document specifies the RSVP diagnostic facility, which is designed 62 to fill this information gap. The diagnostic facility can be used to 63 collect and report RSVP state information along the path from a receiver 64 to a specific sender. It uses Diagnostic messages that are independent 65 of other RSVP control messages and produce no side-effects; that is, 66 they do not change any RSVP state at either nodes or hosts. Similarly, 67 they provide not an error report but rather a collection of requested 68 RSVP state information. 70 The RSVP diagnostic facility was designed with the following goals: 72 - To collect RSVP state information from every RSVP-capable hop along 73 a path defined by path state, either for an existing reservation or 74 before a reservation request is made. More specifically, we want 75 to be able to collect information about flowspecs, refresh timer 76 values, and reservation merging at each hop along the path. 78 - To collect the IP hop count across each non-RSVP cloud. 80 - To avoid diagnostic packet implosion or explosion. 82 The following is specifically identified as a non-goal: 84 - Checking the resource availability along a path. Such functional- 85 ity may be useful for future reservation requests, but it would 86 require modifications to existing admission control modules that is 87 beyond the scope of RSVP. 89 2. Overview 91 The diagnostic facility introduces two new RSVP message types: Diagnos- 92 tic Request (DREQ) and Diagnostic Reply (DREP). A DREQ message can be 93 originated by a client in a "requester" host, which may or may not be a 94 participant of the RSVP session to be diagnosed. A client in the 95 requester host invokes the RSVP diagnostic facility by generating a DREQ 96 packet and sending it towards the LAST-HOP node, which should be on the 97 RSVP path to be diagnosed. This DREQ packet specifies the RSVP session 98 and a sender host for that session. Starting from the LAST-HOP, the DREQ 99 packet collects information hop-by-hop as it is forwarded towards the 100 sender (see Figure 1), until it reaches the ending node. Specifically, 101 each RSVP-capable hop adds to the DREQ message a response 102 (DIAG_RESPONSE) object containing local RSVP state for the specified 103 RSVP session. 105 When the DREQ packet reaches the ending node, the message type is 106 changed to Diagnostic Reply (DREP) and the completed response is sent to 107 the original requester node. Partial responses may also be returned 108 before the DREQ packet reaches the ending node if an error condition 109 along the path, such as "no path state", prevents further forwarding of 110 the DREQ packet. To avoid packet implosion or explosion, all diagnostic 111 packets are forwarded via unicast only. 113 Thus, there are generally three nodes (hosts and/or routers) involved in 114 performing the diagnostic function: the requester node, the starting 115 node, and the ending node, as shown in Figure 1. It is possible that 116 the client invoking the diagnosis function may reside directly on the 117 starting node, in which case that the first two nodes are the same. The 118 starting node is named "LAST-HOP", meaning the last-hop of the path seg- 119 ment to be diagnosed. The LAST-HOP node can be either a receiver node 120 or an intermediate node along the path. The ending node is usually the 121 specified sender host. However, the client can limit the length of the 122 path segment to be diagnosed by specifying a hop-count limit in the DREQ 123 message. 125 LAST-HOP Ending 126 Receiver node node Sender 127 __ __ __ __ __ 128 | |---------| |------>| |--> ...-->| |--> ...---->| | 129 |__| |__| DREQ |__| DREQ |__| DREQ |__| 130 ^ . | 131 | . | 132 | DREQ . DREP | DREP 133 | . | 134 _|_ DREP V V 135 Requester | | <------------------------------------ 136 (client) |___| 138 Figure 1 140 DREP packets can be unicast from the ending node back to the requester 141 either directly or hop-by-hop along the reverse of the path taken by the 142 DREQ message to the LAST-HOP, and thence to the requester. The direct 143 return is faster and more efficient, but the hop-by-hop reverse-path 144 route may be the only choice if the packets have to cross firewalls. 145 Hop-by-hop return is accomplished using an optional ROUTE object, which 146 is built incrementally to contain a list of node addresses that the DREQ 147 packet has passed through. The ROUTE object is then used in reverse as 148 a source route to forward the DREP hop-by-hop back to the LAST-HOP node. 150 A DREQ message always consists of a single unfragmented IP datagram. On 151 the other hand, one DREQ message can generate multiple DREP packets, 152 each containing a fragment of the total DREQ message. When the path 153 consists of many hops, the total length of a DREP message will exceed 154 the MTU size before reaching the ending node; thus, the message has to 155 be fragmented. Relying on IP fragmentation and reassembly, however, can 156 be problematic, especially when DREP messages are returned to the 157 requester hop-by-hop, in which case fragmentation/reassembly would have 158 to be performed at every hop. To avoid such excessive overhead, we let 159 the requester define a default path MTU size that is carried in every 160 DREQ packet. If an intermediate node finds that the default MTU size is 161 bigger than the MTU of the incoming interface, it reduces the default 162 MTU size to the MTU size of the incoming interface. If an intermediate 163 node detects that a DREQ packet size is larger than the default MTU 164 size, it returns to the requester (in either manner described above) a 165 DREP fragment containing accumulated responses. It then removes these 166 responses from the DREQ and continues to forward it. The requester node 167 can reassemble the resulting DREP fragments into a complete DREP mes- 168 sage. 170 When discussing diagnostic packet handling, this document uses direction 171 terminology that is consistent with the RSVP functional specification 172 [RSVP], relative to the direction of data packet flow. Thus, a DREQ 173 packet enters a node through an "outgoing interface" and is forwarded 174 towards the sender through an "incoming interface", because DREQ packets 175 travel in the reverse direction to the data flow. 177 Notice that DREQ packets can be forwarded only after the RSVP path state 178 has been set up. If no path state exists, one may resort to the tracer- 179 oute or mtrace facility to examine whether the unicast/multicast routing 180 is working correctly. 182 3. Diagnostic Packet Format 184 Like other RSVP messages, DREQ and DREP messages consist of an RSVP Com- 185 mon Header followed by a variable set of typed RSVP data objects. The 186 following sequence must be used: 188 +-----------------------------------+ 189 | RSVP Common Header | 190 +-----------------------------------+ 191 | Session object | 192 +-----------------------------------+ 193 | Next-Hop RSVP_HOP object | 194 +-----------------------------------+ 195 | DIAGNOSTIC object | 196 +-----------------------------------+ 197 | (optional) DIAG_SELECT object | 198 +-----------------------------------+ 199 | (optional) ROUTE object | 200 +-----------------------------------+ 201 | zero or more DIAG_RESPONSE objects| 202 +-----------------------------------+ 204 The session object identifies the RSVP session for which the state 205 information is being collected. We describe each of the other parts. 207 3.1. RSVP Message Common Header 209 The RSVP message common header is defined in [RSVP]. The following spe- 210 cific exceptions and extensions are needed for DREP and DREQ. 212 Type field: define: 214 Type = 8: DREQ Diagnostic Request 216 Type = 9: DREP Diagnostic Reply 218 RSVP length: 220 If this is a DREP message and the MF flag in the DIAGNOSTIC object 221 (see below) is set, this field indicates the length of this single 222 DREP fragment rather than the total length of the complete DREP reply 223 message (which cannot generally be known in advance). 225 3.2. Next-Hop RSVP_HOP Object 227 This RSVP_HOP object carries the LIH of the interface through which the 228 DREQ should be received at the upstream node. This object is updated 229 hop-by hop. It is used for the same reasons that a RESV message contains 230 an RSVP_HOP object: to distinguish logical interfaces and avoid problems 231 caused by routing asymmetries and non-RSVP clouds. 233 While the IP address is not really used during DREQ processing , for 234 consistency with the use of the RSVP_HOP object in other RSVP messages, 235 the IP address in the RSVP_HOP object to contain the address of the 236 interface through which the DREQ was sent. 238 3.3. DIAGNOSTIC Object 240 A DIAGNOSTIC object contains the common diagnostic control information 241 in both DREQ and DREP messages. 243 o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Max-RSVP-hops | RSVP-hop-count| Reserved |MF| 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Request ID | 248 +---------------+---------------+---------------+---------------+ 249 | Path MTU | Fragment Offset | 250 +---------------+---------------+---------------+---------------+ 251 | LAST-HOP Address | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 | SENDER_TEMPLATE object | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 | Requester FILTER_SPEC object | 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Here all IP addresses use the 4 byte IPv4 format, both explicitly in the 263 LAST-HOP Address and by using the IPv4 forms of the embedded FILTER_SPEC 264 and RSVP_HOP objects. 266 o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2 268 The format is the same, except all explicit and embedded IP addresses 269 are 16 byte IPv6 addresses. 271 The fields are as follows: 273 Max-RSVP-hops 275 An octet specifying the maximum number of RSVP hops over which infor- 276 mation will be collected. If an error condition in the middle of the 277 path prevents the DREQ packet from reaching the specified ending 278 node, the Max-RSVP-hops field may be used to perform an expanding- 279 length search to reach the point just before the problem. If this 280 value is 1, the starting node and the ending node of the query will 281 be the same. If it is zero, there is no hop limit. 283 RSVP-hop-count 285 Records the number of RSVP hops that have been traversed so far. If 286 the starting and ending nodes are the same, this value will be 1 in 287 the resulting DREP message. 289 Fragment Offset 291 Indicates where this DREP fragment belongs in the complete DREP mes- 292 sage, measured in octets. The first fragment has offset zero. Frag- 293 ment Offset is used also to determine if a DREQ message containing 294 zero DIAG_RESPONSE objects should be processed at an RSVP capable 295 node. 297 MF flag 299 Flag means "more fragments". It must be set to zero (0) in all DREQ 300 messages. It must be set to one (1) in all DREP packets that carry 301 partial results and are returned by intermediate nodes due to the MTU 302 limit. When the DREQ message is converted to a DREP message in the 303 ending node, the MF flag must remain zero. 305 Request ID 307 Identifies an individual DREQ message and the corresponding DREP mes- 308 sage (or all the fragments of the reply message). 310 One possible way to define the Request ID would use 16 bits to spec- 311 ify the ID of the process making the query and 16 bits to distinguish 312 different queries from this process. 314 Path MTU 316 Specifies a default MTU size in octets for DREP and DREQ messages. 317 This value should not be smaller than the size of the "base" DREQ 318 packet. A "base" DREQ packet is one that contains a Common Header, a 319 Session object, a Next-Hop RSVP_HOP object, a DIAGNOSTIC object, an 320 empty ROUTE object and a single default DIAG_RESPONSE (see below). 321 The assumption made here is that a diagnostic packet of this size can 322 always be forwarded without IP fragmentation. 324 LAST-HOP Address 326 The IP address of the LAST-HOP node. The DREQ message starts col- 327 lecting information at this node and proceeds toward the sender. 329 SENDER_TEMPLATE object 331 This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and the 332 port of a sender for the session being diagnosed. The DREQ packet is 333 forwarded hop-by-hop towards this address. 335 Requester FILTER_SPEC Object 337 This IPv4/IPv6 FILTER_SPEC object contains the IP address and the 338 port from which the request originated and to which the DREP mes- 339 sage(s) should be sent. 341 3.4. DIAG_SELECT Object 343 o DIAG_SELECT Class = 33, C-Type = 1. 345 A Diagnostic message may optionally contain a DIAG_SELECT object to 346 specify which specific RSVP objects should be reported in a 347 DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the 348 DIAG_RESPONSE object added by the node will contain a default set of 349 object types (see DIAG_RESPONSE object below). 351 The DIAG_SELECT object contains a list of [Class, C-type] pairs, in the 352 following format: 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | class | C-Type | class | C-Type | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 // // 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | class | C-Type | class | C-Type | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 When a DIAG_SELECT object is included in a DREQ message, each RSVP node 363 along the path will add a DIAG_RESPONSE object containing response 364 objects (see below) whose classes and C-Types match entries in the 365 DIAG_SELECT list (and are from matching path and reservation state). A 366 C-type octet of zero is a 'wildcard', matching any C-Type associated 367 with the associated class. 369 Depending on the type of objects requested, a node can find the associ- 370 ated information in the path or reservation state stored for the session 371 described in the SESSION object. Specifically, information for the 372 RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC objects can be extracted 373 from the node's path state, while information for the FLOWSPEC, FIL- 374 TER_SPEC, CONFIRM, STYLE and SCOPE objects can be found in the node's 375 reservation state (if existent). 377 If the number of [Class, C-Type] pairs is odd, the last two octets of 378 the DIAG_SELECT object must be zero. A maximum DIAG_SELECT object is 379 one that contains the [Class, C-type] pairs for all the RSVP objects 380 that can be requested in a Diagnostic query. 382 3.5. ROUTE Object 384 A diagnostic message may contain a ROUTE object, which is used to record 385 the route of the DREQ message and as a source route for returning the 386 DREP message(s) hop-by-hop. 388 o IPv4 ROUTE object: Class = 31, C-Type = 1. 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | reserved | R-pointer | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 + RSVP Node List | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 This message signifies how the reply should be returned. If it does not 399 exist in the DREQ packet then DREP packets should be sent to the 400 requester directly. If it does exist, DREP packets must be returned hop- 401 by-hop along the reverse path to the LAST-HOP node and thence to the 402 requester node. 404 An empty ROUTE object is one that has an empty RSVP Node list and R- 405 pointer is equal to zero. 407 RSVP Node List 409 A list of RSVP node IPv4 addresses. The number of addresses in this 410 list can be computed from the object size. 412 R-pointer 414 Used in DREP messages only (see Section 4.2 for details), but it is 415 incremented as each hop adds its incoming interface address in the 416 ROUTE object. 418 o IPv6 ROUTE object: Class = 31, C-Type = 2 420 The same, except RSVP Node List contains IPv6 addresses. 422 In a DREQ message, RSVP Node List specifies all RSVP hops between the 423 LAST-HOP address specified in the DIAGNOSTIC object, and the last RSVP 424 node the DREQ message has visited. In a DREP message, RSVP Node List 425 specifies all RSVP hops between the LAST-HOP and the node that returns 426 this DREP message. 428 3.6. DIAG_RESPONSE Object 430 Each RSVP node attaches a DIAG_RESPONSE object to each DREQ message it 431 receives, before forwarding the message. The DIAG_RESPONSE object con- 432 tains the state to be reported for this node. It has a fixed-format 433 header and then a variable list of RSVP state objects, or "response 434 objects". 436 o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1. 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | DREQ Arrival Time | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Incoming Interface Address | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Outgoing Interface Address | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Previous-RSVP-Hop Router Address | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | D-TTL |M|R-err| K | Timer value | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 | (optional) TUNNEL object | 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 // Response objects // 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2. 460 This object has the same format, except that all explicit and embedded 461 IP addresses are IPv6 addresses. 463 The fields are as follows: 465 DREQ Arrival Time 466 A 32-bit NTP timestamp specifying the time the DREQ message arrived 467 at this node. The 32-bit form of an NTP timestamp consists of the 468 middle 32 bits of the full 64-bit form, that is, the low 16 bits of 469 the integer part and the high 16 bits of the fractional part. 471 Incoming Interface Address 473 Specifies the IP address of the interface on which messages from the 474 sender are expected to arrive, or 0 if unknown. 476 Outgoing Interface Address 478 Specifies the IP address of the interface through which the DREQ mes- 479 sage arrived and to which messages from the given sender and for the 480 specified session address flow, or 0 if unknown. 482 Previous-RSVP-Hop Router Address 484 Specifies the IP address from which this node receives RSVP PATH mes- 485 sages for this source, or 0 if unknown. This is also the interface 486 to which the DREQ will be forwarded. 488 D-TTL 490 The number of IP hops this DREQ message traveled from the down-stream 491 RSVP node to the current node. 493 M flag 495 A single-bit flag which indicates whether the reservation described 496 by the response objects is merged with reservations from other down- 497 stream interfaces when being forwarded upstream. 499 R-error 501 A 3-bit field that indicates error conditions at a node. Currently 502 defined values are: 504 0x00: no error 505 0x01: No PATH state 506 0x02: packet too big 507 0x04: ROUTE object too big 509 K 511 The refresh timer multiple (defined in [RSVP]). 513 Timer value 515 The local refresh timer value in seconds. 517 The set of response objects to be included at the end of the 518 DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is 519 present. If no DIAG_SELECT object is present, the response objects 520 belong to the default list of classes: 522 SENDER_TSPEC object FILTER_SPEC object FLOWSPEC object 523 STYLE object 525 Any C-Type present in the local RSVP state will be used. These response 526 objects may be in any order but they must all be at the end of the 527 DIAG_RESPONSE object. 529 A default DIAG_RESPONSE object is one containing the default list of 530 classes described above. 532 3.7. TUNNEL Object 534 The optional TUNNEL object should be inserted when a DREQ message 535 arrives at an RSVP node that acts as a tunnel exit point. 537 The TUNNEL object provides the mapping between the end-to-end RSVP ses- 538 sion that is being diagnosed and the RSVP session over the tunnel. This 539 mapping information allows the diagnosis client to conduct diagnosis 540 over the involved tunnel session, by invoking a separate Diagnostic 541 query for the corresponding Tunnel Session and Tunnel Sender. Keep in 542 mind, however, that multiple end-to-end sessions may all map to one pre- 543 configured tunnel session that may have totally different parameter set- 544 tings. 546 The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN]. 548 4. Diagnostic Packet Forwarding Rules 550 4.1. DREQ Packet Forwarding 552 DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP 553 address to the Sender address, as specified in the DIAGNOSTIC object. 554 If an RSVP capable node, other than the LAST-HOP node, receives a DREQ 555 message that contains no DIAG_RESPONSE objects and has a zero Fragment 556 Offset, the node should forward the DREQ packet towards the LAST-HOP 557 without doing any of the processing mentioned below. The reason is that 558 such conditions apply only for nodes downstream of the LAST-HOP where no 559 information should be collected. 561 Processing begins when a DREQ message, DREQ_in, arrives at a node. 563 1. Create a new DIAG_RESPONSE object. Compute the IP hop count from 564 the previous RSVP hop. This is done by subtracting the value of the 565 TTL value in the IP header from Send_TTL in the RSVP common header. 566 Save the result in the D-TTL field of the DIAG_RESPONSE object. 568 2. Set the DREQ Arrival Time and the Outgoing Interface Address in the 569 DIAG_RESPONSE object. If this node is the LAST-HOP, then the Out- 570 going Interface Address field in the DIAG_RESPONSE object contains 571 the following value depending on the session being diagnosed. 573 * If the session in question is a unicast session, then the Out- 574 going Interface Address field contains the address of the 575 interface LAST-HOP uses to send PATH messages and data to the 576 receiver specified by the session address. 578 * Otherwise, if it is a multicast session and there is at least 579 one receiver for this session, LAST_HOP should use the address 580 of one of local interfaces used to reach one of the receivers. 582 * Otherwise Outgoing Interface Address should be zero. 584 3. Increment the RSVP-hop-count field in the DIAGNOSTIC message object 585 by one. 587 4. If no PATH state exists for the specified session, set R-error = 588 0x01 (No PATH state) and goto step 7. 590 5. Set the rest of the fields in the DIAG_RESPONSE object. If DREQ_in 591 contains a DIAG_SELECT object, the response object classes are 592 those specified in the DIAG_SELECT; otherwise, they are 593 SENDER_TSPEC, STYLE, and FLOWSPEC objects. If no reservation state 594 exists for the specified RSVP session, the DIAG_RESPONSE object 595 will contain no FLOWSPEC, FILTER_SPEC or STYLE object. If neither 596 PATH nor reservation state exists for the specified RSVP session, 597 then no response objects will be appended to the DIAG_RESPONSE 598 object. 600 6. If RSVP-hop-count is less than Max-RSVP-hops and this node is not 601 the sender, then the DREQ is eligible for forwarding; set the Path 602 MTU to the min of the Path MTU and the MTU size of the incoming 603 interface for the sender being diagnosed. 605 7. If the size of DREQ_in plus the size of the new DIAG_RESPONSE 606 object plus the size of an IP address (if a ROUTE object exists and 607 R-error= 0) is larger than Path MTU, then the new diagnostic mes- 608 sage will be too large to be forwarded or returned without fragmen- 609 tation; set the "packet too big" (0x02) error bit in DIAG_RESPONSE 610 and goto Step SD1 in Send_DREP (below). 612 8. If the "No PATH state" (0x01) error bit is set or if RSVP-hop-count 613 is equal to Max-RSVP-hops or if this node is the sender, then the 614 DREQ cannot be forwarded further; goto Step 10. 616 9. Forward the DREQ towards the sender, as follows. If a ROUTE object 617 exists, append the "Incoming Interface Address" to the end of the 618 ROUTE object and increment R-Pointer by one. Update the Next-Hop 619 RSVP_HOP object, append the new DIAG_RESPONSE object to the list of 620 DIAG_RESPONSE object, and update the message length field in the 621 RSVP common header accordingly. Finally, recompute the checksum, 622 forward DREQ_in to the next hop towards the sender, and return. 624 10. Turn the DREQ into a DREP and return to the requester, as follows. 625 Append the DIAG_RESPONSE object to the end of DREQ_in and update 626 the packet length. If a ROUTE object is present in the message, 627 decrement the R-pointer and set target address to the last address 628 in the ROUTE object, otherwise set target address to the requester 629 address. Change the Type Field in the Common header from DREQ to 630 DREP. Finally, recompute the checksum, send the DREP to the target 631 address, and return. Note that the MF bit must be off in this 632 case. 634 Send_DREP: 636 This sequence is entered if the DREQ message augmented with the new 637 DIAG_RESPONSE object is too large to be forwarded towards the sender or, 638 if it is not eligible for forwarding, too large to be returned as a 639 DREP. 641 SD1. Make a copy of DREQ_in and change the message type field from DREQ 642 to DREP. Trim all DIAG_RESPONSE objects from DREQ_in and adjust 643 the Fragment Offset. The DREP message contains the DIAG_RESPONSE 644 objects accumulated by prior nodes. 646 SD2. Send the DREP message towards the requester, as follows. If a 647 ROUTE object is present in the DREP message, decrement the R- 648 pointer and set target address to the last address in the ROUTE 649 object, otherwise set target address to the requester address. Set 650 the MF bit, recompute the checksum and send the DREP message back 651 to the target address. 653 SD3. If the reduced size of DREQ_in plus the size of DIAG_RESPONSE plus 654 the size of an IP address (if a ROUTE object exists) is smaller 655 than or equal to Path MTU, then return to Step 8 of the main DREQ 656 processing sequence above. 658 SD4. If a ROUTE object exists, replace the ROUTE object in DREQ_in with 659 an empty ROUTE object and turn on the "ROUTE object too big" (0x04) 660 error bit in the DIAG_RESPONSE. In either case, return to Step 8 661 of the main DREQ processing sequence above. 663 4.2. DREP Forwarding 665 When a ROUTE object is present, DREP messages are forwarded hop-by-hop 666 towards the requester, by reversing the route as listed in the ROUTE 667 object. Otherwise, DREP messages are sent directly to the original 668 requester. 670 When a node receives a DREP message, it simply decreases R-pointer by 671 one (address length), recomputes the checksum and forwards the message 672 to the address pointed to by R-pointer in the route list. If a node, 673 other than the LAST-HOP, receives a DREP packet where R-pointer is equal 674 to zero, it must send it directly to the requester. 676 When the LAST-HOP node receives a DREP message, it sends the message to 677 the requester. 679 4.3. MTU Selection and Adjustment 681 Because the DREQ message carries the allowed MTU size of previous hops 682 that the DREP messages will later traverse, this unique feature allows 683 easy semantic fragmentation as described above. Whenever the DREQ mes- 684 sage approaches the size of Path MTU, it can be trimmed before being 685 forwarded again. 687 When a requester sends a DREQ message, the Path MTU field in the DIAG- 688 NOSTIC object can be set to a configured default value. It is possible 689 that the original Path MTU value is chosen larger than the actual MTU 690 value along some portion of the path being traced. Therefore each 691 intermediate RSVP node must check the MTU value when processing a DREQ 692 message. If the specified MTU value is larger than the MTU of the 693 incoming interface (that the DREQ message will be forwarded to), the 694 node changes the MTU value in the header to the smaller value. 696 Whenever a DREQ message size becomes larger than the Path MTU value, an 697 intermediate RSVP node makes a copy of the message, converts it to a 698 DREP message to send back, and then trims off the partial results from 699 the DREQ message. If in this case also the DREQ cannot be forwarded 700 upstream due to a large ROUTE object, the "ROUTE object too big" is set 701 and the ROUTE object is trimmed. As a result of the ROUTE object trim- 702 ming, DREP(s) will come hop-by-hop up to this node and will then immedi- 703 ately be forwarded to the requester address. 705 Even if the steps shown above are followed there are a few cases where 706 fragmentation at the IP layer will happen. For example, non-RSVP hops 707 with smaller MTUs may exist before LAST-HOP is reached, or if the 708 response is sent directly back to requester (as opposed to hop by hop) 709 the DREP may take a different route to the requester than the DREQ took 710 from the requester. Another case is when there exists a link with MTU 711 smaller than the minimum Path MTU value defined in Section 3.3. 713 4.4. Errors 715 If an error condition prevents a DREP message from being forwarded fur- 716 ther, the message is simply dropped. 718 If an error condition, such as lack of PATH state, prevents a DREQ mes- 719 sage from being forwarded further, the node must change the current mes- 720 sage to DREP type and return it to the response address. 722 5. Problem Diagnosis by Using RSVP Diagnostic Facility 724 5.1. Across Firewalls 726 Firewalls may cause problems in diagnostic message forwarding. Let us 727 look at two different cases. 729 First, let us assume that the querier resides on a receiving host of the 730 session to be examined. In this case, firewalls should not prevent the 731 forwarding of the diagnostic messages in a hop-by-hop manner, assuming 732 that proper holes have been punched on the firewall to allow hop-by-hop 733 forwarding of other RSVP messages. The querier may start by not includ- 734 ing a ROUTE object, which can give a faster response delivery and 735 reduced overhead at intermediate nodes. However if no response is 736 received, the querier may resend the DREQ message with a ROUTE object, 737 specifying that a hop-by-hop reply should be sent. 739 If the requester is a third party host and is separated from the LAST- 740 HOP address by a firewall (either the requester is behind a firewall, or 741 the LAST-HOP is a node behind a firewall, or both), at this time we do 742 not know any other solution but to change the LAST-HOP to a node that is 743 on the same side of the firewall as the requester. 745 5.2. Examination of RSVP Timers 747 One can easily collect information about the current timer value at each 748 RSVP hop along the way. This will be very helpful in situations when 749 the reservation state goes up and down frequently, to find out whether 750 the state changes are due to improper setting of timer values, or K val- 751 ues (when across lossy links), or frequent routing changes. 753 5.3. Discovering Non-RSVP Clouds 755 The D-TTL field in each DIAG_RESPONSE object shows the number of routing 756 hops between adjacent RSVP nodes. Therefore any value greater than one 757 indicates a non-RSVP cloud in between. Together with the arrival times- 758 tamps (assuming NTP works), this value can also give some vague, though 759 not necessarily accurate, indication of how big that cloud might be. 760 One might also find out all the intermediate non-RSVP nodes by running 761 either unicast or multicast trace route. 763 5.4. Discovering Reservation Merges 765 The flowspec value in a DIAG_RESPONSE object specifies the amount of 766 resources being reserved for the data stream defined by the filter spec 767 in the same data block. When this value of adjacent DIAG_RESPONSE 768 objects differs, that is, a downstream node Rd has a smaller value than 769 its immediate upstream node Ru, it indicates a merge of reservation with 770 RSVP request(s) from other down stream interface(s) at Rd. Further, in 771 case of SE style reservation, one can examine how the different SE 772 scopes get merged at each hop. 774 In particular, if a receiver sends a DREQ message before sending its own 775 reservation, it can discover (1) how many RSVP hops there are along the 776 path between the specified sender and itself, (2) how many of the hops 777 already have some reservation by other receivers, and (3) possibly a 778 rough prediction of how its reservation request might get merged with 779 other existing ones. 781 5.5. Error Diagnosis 783 In addition to examining the state of a working reservation, RSVP diag- 784 nostic messages are more likely to be invoked when things are not work- 785 ing correctly. For example, a receiver has reserved an adequate pipe 786 for a specified incoming data stream, yet the observed delay or loss 787 ratio is much higher than expected. In this case the receiver can use 788 the diagnostic facility to examine the reservation state at each RSVP 789 hop along the way to find out whether the RSVP state is set up 790 correctly, whether there is any blackhole along the way that caused RSVP 791 message losses, or whether there are non-RSVP clouds, and where they 792 are, that may have caused the performance problem. 794 5.6. Crossing "Legacy" RSVP Routers 796 Since this diagnosis facility was developed and added to RSVP after a 797 number of RSVP implementations were in place, it is possible, or even 798 likely, that when performing RSVP diagnosis, one may encounter one or 799 more RSVP-capable nodes that do not understand diagnostic messages and 800 drop them. When this happens, the invoking client will get no response 801 from its requests. 803 One way to by-pass such "legacy" RSVP nodes is to perform RSVP diagnosis 804 repeatedly, guided by information from traceroute, or mtrace in case of 805 multicast. When an RSVP diagnostic query times out (see next section), 806 one may first use traceroute to get the list of nodes along the path, 807 and then gradually increase the value of Max-RSVP-hops field in the DREQ 808 message, starting from a low value until one no longer receives a 809 response. One can then try RSVP diagnosis again by starting with the 810 first node (which is further upstream towards the sender) after the 811 unresponding one. 813 There are two problem with the method mentioned above in the case of 814 unicast sessions. Both problems are related to the fact that traceroute 815 information provides the path from the requester to the sender. The 816 first problem is that the LAST-HOP may not be on the path from the 817 requester to the sender. In this case we can get information only from 818 the portion of the path from the LAST-HOP to the sender which intersects 819 with the path from the requester to the sender. If routers that are not 820 on the intersection of the two paths don't have PATH state for the ses- 821 sion being diagnosed then they will reply with R-error=0x01. The 822 requester can overcome this problem by sending a DREQ to every router on 823 the path (from itself to the sender) until it reaches the first router 824 that belongs to the path from the sender to the LAST-HOP. 826 The second problem is that traceroute provides the path from the 827 requester to the sender which, due to routing asymmetries, may be dif- 828 ferent than the path traffic from the sender to the LAST-HOP uses. There 829 is (at least) one case where this asymmetry will cause the diagnosis to 830 fail. We present this case below. 832 Downstream Path Sender 833 __ __ __ __ 834 Receiver +------| |<------| |<-- ...---| |-----| | 835 __ __ / |__| |__| |__| |__| 836 | |--....--|X |_/ ^ 837 |__| |__| \ Router B | 838 Black \ __ | 839 Hole +----->| |---->---+ 840 |__| Upstream Path 842 Router A 844 Figure 2 846 Here the first hop upstream of the black hole is different on the 847 upstream path and the downstream path. Traceroute will indicate router A 848 as the previous hop (instead of router B which is the right one). Send- 849 ing a DREQ to router A will result in A responding with R-error 0x01 (No 850 PATH State). If the two paths converge again then the requester can use 851 the solution proposed above to get any (partial) information from the 852 rest of the path. 854 We don't have, for the moment, any complete solutions for the problem- 855 atic scenarios described here. 857 6. Comments on Diagnostic Client Implementation. 859 Following the design principle that nodes in the network should not hold 860 more than necessary state, RSVP nodes are responsible only for forward- 861 ing Diagnostic messages and filling DIAG_RESPONSE objects. Additional 862 diagnostic functionality should be carried out by the diagnostic 863 clients. Furthermore, if the diagnostic function is invoked from a 864 third-party host, we should not require that host be running an RSVP 865 daemon to perform the function. Below we sketch out the basic functions 866 that a diagnostic client daemon should carry out. 868 1. Take input from the user about the session to be diagnosed, the 869 last-hop and the sender address, the Max-RSVP-hops, and possibly 870 the DIAG_SELECT list, create a DREQ message and send to the LAST- 871 HOP RSVP node using raw IP message with protocol number 46 (RSVP). 872 If the user specified that the response should be sent hop-by-hop 873 include an empty ROUTE object to the DREQ message sent. Set the 874 Path_MTU to the smaller of the user request and the MTU of the link 875 through which the DREQ will be sent. 877 The port of the UDP socket on which the Diagnostic Client is 878 listening for replies should be included in the Requester FIL- 879 TER_SPEC object. 881 2. Set a retransmission timer, waiting for the reply (one or more DREP 882 messages). Listen to the specified UDP port for responses from the 883 LAST-HOP RSVP node. 885 The LAST-HOP RSVP node, upon receiving DREP messages, sends them to 886 the Diagnostic Client as UDP packets, using the port supplied in 887 the Requester FILTER_SPEC object. 889 3. Upon receiving a DREP message to an outstanding diagnostic request, 890 the client should clear the retransmission timer, check to see if 891 the reply contains the complete result of the requested diagnosis. 892 If so, it should pass the result up to the invoking entity immedi- 893 ately. 895 4. Reassemble DREP fragments. If the first reply to an outstanding 896 diagnostic request contains only a fragment of the expected result, 897 the client should set up a reassembly timer in a way similar to IP 898 packet reassembly timer. If the timer goes off before all frag- 899 ments arrive, the client should pass the partial result to the 900 invoking entity. 902 5. Use retransmission and reassembly timers to gracefully handle 903 packet losses and reply fragment scenarios. 905 In the absence of response to the first diagnostic request, a 906 client should retransmit the request a few times. If all the 907 retransmissions also fail, the client should invoke traceroute or 908 mtrace to obtain the list of hops along the path segment to be 909 diagnosed, and then perform an iteration of diagnosis with increas- 910 ing hop count as suggested in Section 5.6 in order to cross RSVP- 911 capable but diagnosis-incapable nodes. 913 6. If all the above efforts fail, the client must notify the invoking 914 entity. 916 7. Security Considerations 918 RSVP Diagnostics, as any other diagnostic tool, can be a security threat 919 since it can reveal possibly sensitive RSVP state information to 920 unwanted third parties. 922 We feel that the threat is minimal, since as explained in the Introduc- 923 tion Diagnostics messages produce no side-effects and therefore they 924 cannot change RSVP state in the nodes. In this respect RSVP Diagnostics 925 is less a security threat than other diagnostic tools and protocols such 926 as SNMP. 928 Furthermore, processing of Diagnostic messages can be disabled if it is 929 felt that is a security threat. 931 8. Acknowledgments 933 The idea of developing a diagnostic facility for RSVP was first sug- 934 gested by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox PARC 935 and John Krawczyk of Baynetworks for their valuable comments on the 936 first draft of this memo. Lee Breslau, Bob Braden, and John Krawczyk 937 contributed further comments after March 1996 IETF. Steven Berson pro- 938 vided valuable comments on various drafts of the memo. Tim Gleeson con- 939 tributed an extensive list of editorial comments. We would also like to 940 acknowledge Intel for providing a research grant as a partial support 941 for this work. Subramaniam Vincent did most of this work while a gradu- 942 ate research assistant at the USC Information Sciences Institute (ISI). 944 9. References 946 [RSVP] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 947 Functional Specification", RFC 2205, September 1997. 949 [RSVPTUN] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. "RSVP Opera- 950 tion Over IP Tunnels ", Internet Draft. draft-ietf-rsvp-tunnel-02.txt, 951 February, 1999. 953 10. Authors' Addresses 955 Andreas Terzis 956 UCLA 957 4677 Boelter Hall 958 Los Angeles, CA 90095 960 Phone: 310-267-2190 961 Email: terzis@cs.ucla.edu 963 Bob Braden 964 USC Information Sciences Institute 965 4676 Admiralty Way 966 Marina del Rey, CA 90292 967 Phone: 310 822-1511 968 EMail: braden@isi.edu 970 Subramaniam Vincent 971 Cisco Systems 972 275, E Tasman Drive, MS SJC04/2/1 973 San Jose, CA 95134. 974 Phone: 408 525 3474 975 Email: svincent@cisco.com 977 Lixia Zhang 978 UCLA 979 4531G Boelter Hall 980 Los Angeles, CA 90095 982 Phone: 310-825-2695 983 EMail: lixia@cs.ucla.edu