idnits 2.17.1 draft-ietf-rsvp-diagnostic-msgs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 224: '...ts, the checksum MUST be verified befo...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 164 has weird spacing: '...utgoing link,...' -- 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 (August 1998) is 9383 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 361, but not defined == Missing Reference: 'C-type' is mentioned on line 361, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-rsvp-tunnel-02 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Lixia Zhang 3 Andreas Terzis 4 Expiration: February 1999 UCLA 5 Subramaniam Vincent 7 August 1998 8 RSVP Diagnostic Messages 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Distribution of this memo is unlimited. 32 This Internet Draft expires in February, 1999. 34 Abstract 36 This document specifies the RSVP diagnosis facility. As the 37 deployment of RSVP is spreading out, it becomes clear that a method 38 for collecting information about the RSVP state along the path is 39 needed. This specification describes the functionality, diagnostic 40 message formats, and processing rules. 42 1. Introduction 44 In the original design of the RSVP protocol, error messages are the 45 only means for the end hosts to receive feedback information 46 regarding a specific request that has failed, a failure in setting up 47 either a PATH state or reservation state. In the absence of 48 failures, one receives no feedback regarding the details of a 49 reservation that has been put in place, such as whether, or where, or 50 how, one's own reservation request is merged with that of others. In 51 case of a failure, the error message carries back only the 52 information from the failed point, without any information about the 53 state at other hops before or after the failure. Such missing 54 information, however, can be highly desirable for debugging purpose, 55 or for network resource management in general. 57 This document specifies RSVP diagnostic messages that allows one to 58 collect information of RSVP state along the path from a receiver to a 59 specific sender. Diagnostic messages are independent from any other 60 RSVP control messages and produce no side-effects. That is, they do 61 not change any RSVP state at either routers or hosts. Similarly, 62 they do not represent an error report but a collection of RSVP state 63 information as requested. 65 We have the following design goals in mind: 67 - To be able to collect RSVP state information at every hop along 68 the path where the PATH state has been set up, either for an 69 existing reservation or before a reservation request is made; 70 here the "hop" means RSVP-capable routers. 72 More specifically, we want to be able to collect information 73 about flowspec, refresh timer values, and reservation merging at 74 each hop along the path. 76 - To be able to collect the routing hop count for each non-RSVP 77 cloud. 79 - To avoid diagnostic packet implosion or explosion. 81 The following are specifically identified as non-goals: 83 - Checking the resource availability along a path. Such 84 functionality may be useful for future reservation requests, but 85 would require modifications to existing admission control module 86 which is beyond the scope of RSVP. 88 2. Overview 90 We define two types of RSVP diagnostic packets, diagnostic request 91 (DREQ) and reply (DREP). This diagnostic tool can be invoked by a 92 client from any host that may or may not be a participant of the RSVP 93 session to be diagnosed. Thus generally speaking three nodes are 94 involved in performing the diagnostic function: the requester, the 95 starting and the ending nodes of the diagnosis, as shown in Figure 1. 96 It is possible that the client invoking the diagnosis function may 97 reside directly on the LAST-HOP, in which case that the first two 98 nodes are the the same. The starting node of the diagnosis is named 99 "LAST-HOP", meaning the last-hop of the path segment to be diagnosed, 100 which can be either the receiving end or an intermediate router along 101 a reserved path. The ending node is the sender host in general, 102 although one can also limit the length of the path segment to be 103 diagnosed by specifying a hop-count limit for the diagnosis messages. 104 To avoid packet implosion or explosion, all diagnostic packets are 105 forwarded via unicast only. 107 A client invokes RSVP diagnostic functions by generating a DREQ 108 packet and sending to the LAST-HOP node which should be on the RSVP 109 path to be diagnosed. This DREQ packet specifies the RSVP session 110 and a sender host to that session. The DREQ packet starts collecting 111 information at the LAST-HOP node and proceeds toward the sender (see 112 Figure 1). 114 Receiver LAST-HOP Sender 115 __ __ __ __ __ __ __ 116 | |---------| |------>| |-->| |-->| |-->| |---->| | 117 |__| |__| DREQ |__| |__| |__| |__| |__| 118 ^ 119 | RSVP routers 120 | 121 |request 122 _|_ 123 | | Requester 124 |___| 126 Figure 1 128 Each RSVP-capable router receiving the DREQ packet adds to the packet 129 a response data object containing the router's RSVP state for the 130 specified RSVP session, and then forwards the request via unicast to 131 the router that it believes to be the previous hop for the given 132 sender. Each subsequent RSVP router attaches its own response data 133 object to the end of the DREQ packet, then forwards via unicast to 134 the previous hop. When the DREQ packet reaches the sender, the 135 sender changes the packet type to Diagnostic Reply (DREP) and sends 136 the completed response to the original requester. Partial response 137 may also be returned before the DREQ packet reaches the sender if any 138 error condition along the path, such as "no path state", prevents 139 further forwarding of the DREQ packet, or if the specified hop-count 140 for the diagnosis has been reached. 142 DREP packets can be unicast back to the requester either directly, or 143 in a hop-by-hop manner by reversing the exact path that the DREQ 144 packet has taken. The former is faster and more efficient, but the 145 latter may be the only choice if the packets have to cross firewalls, 146 due to the way that firewalls operate. 148 To facilitate the latter case, a DREQ packet may optionally carry a 149 ROUTE object, which is a list of router addresses that the DREQ 150 packet has passed through on the way to the sender; this ROUTE object 151 is built incrementally as the DREQ packet passes through the 152 intermediate routers. The DREP packet can then be returned to the 153 requester by reversing the path. 155 When the path consists of many hops, it is possible that the total 156 length of a DREP packet will exceed the path MTU size before reaching 157 the sender, thus the packet has to be fragmented. Relying on IP 158 fragmentation and reassembly, however, can be problematic, especially 159 when DREP packets are returned to the requester hop-by-hop, in which 160 case fragmentation/reassembly would have to be performed at every 161 hop. To avoid such excessive overhead, we let the requester define a 162 default path MTU size which is carried in every DREQ packet. If an 163 intermediate router finds that the default MTU size is bigger than 164 that of the outgoing link, it returns the DREQ packet with the 165 corresponding error bit set. If an intermediate router detects that 166 a DREQ packet size reaches the MTU size, it sends a partial DREP, 167 consisting of the collected responses back, to the requester and then 168 continues to forward the trimmed DREQ packet to the next hop towards 169 the sender. 171 Through out this document we use the word "DREQ packet", rather the 172 word "message" to call a diagnostic request since it always consists 173 of a single packet. On the other hand, one DREQ packet can generate 174 multiple DREP packets, each containing a fragment of the total reply. 175 Furthermore, when discussing diagnostic packet handling, the 176 terminology used refers to the direction of data packet flow, thus 177 "outgoing interface" of a router is the interface a DREQ packet comes 178 from. THE DREQ then gets forwarded to an "incoming interface", 179 because DREQ packets travel in the reverse direction of the data 180 flow. 182 Notice that one can forward DREQ packets only after the RSVP PATH 183 state has been set up. If no PATH state exists, one may resort to 184 the traceroute or mtrace facility to examine whether the 185 unicast/multicast routing is working correctly. 187 3. Diagnostic Packet Format 189 A diagnostic packet consists of the following parts: 191 +-----------------------------------+ 192 | RSVP common header | 193 +-----------------------------------+ 194 | Diagnostic packet header object | 195 +-----------------------------------+ 196 | session object | 197 +-----------------------------------+ 198 | (optional) SELECT object | 199 +-----------------------------------+ 200 | (optional) ROUTE object | 201 +-----------------------------------+ 202 | zero or more Response Object | 203 +-----------------------------------+ 205 3.1. RSVP Message Common Header 207 In the RSVP message common header, 209 0 1 2 3 210 +-------------+-------------+-------------+-------------+ 211 | Vers | Flags| Type | RSVP Checksum | 212 +-------------+-------------+-------------+-------------+ 213 | Send_TTL | reserved | RSVP Length | 214 +-------------+-------------+-------------+-------------+ 216 The Flags field is unused for now and must be set to zero. 218 Type = 8: DREQ 220 Type = 9: DREP 221 The RSVP Checksum is the 16-bit one's complement of the one's 222 complement sum of the whole diagnosis message (including this 223 header). For computing the checksum, the checksum field is set to 224 zero. When receiving packets, the checksum MUST be verified before 225 processing a packet. 227 Send_TTL: the TTL value that a router puts in the IP packet header 228 when forwarding the DREQ packet to the previous hop. 230 RSVP length: the total length of this diagnostic packet in bytes, 231 including the common header. If this is a DREP packet and the MF 232 flag in the diagnostic packet header (see below) is set, this length 233 field indicate the length of this single DREP fragment, rather than 234 the total length of the the complete DREP reply (which may not be 235 known in advance). 237 3.2. RSVP Diagnostic Packet Header Object 239 Both DREQ and DREP headers are a concatenation of Diagnostic Packet 240 Header Object and an RSVP Session object, as defined below: 242 0 1 2 3 243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | length | class | c-type | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Max-RSVP-hops | RSVP-hop-count| Reserved |H|MF| 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Message ID | 250 +---------------+---------------+---------------+---------------+ 251 | path MTU | Fragment offset | 252 +---------------+---------------+---------------+---------------+ 253 | | 254 | Sender Filter-Spec | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | LAST-HOP Address | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 | Response Address Filter-Spec | 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 | Next-Hop RSVP_HOP Object | 265 | | 266 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 267 | | 268 + Followed by RSVP Session Object | 269 | | 271 Length is the length of this diagnostic header object. 273 Class = 30. 275 C-type field is used to distinguish between IPv4 (C-type = 1) and 276 IPv6 (Ctype = 2). In the IPv6 case addresses will be 16 bytes each. 278 Max-RSVP-hops specifies the maximum number of RSVP hops that the 279 requester wants to collect information from. In case an error 280 condition in the middle of the path prevents the DREQ packet from 281 reaching the specified sender, one may use this field to perform an 282 expanding-length search to reach the point just before the problem. 284 The fragment offset field indicates where in the total reply this 285 fragment belongs. The fragment offset is measured in octets. The 286 first fragment has offset zero. 288 RSVP-hop-count field records the number of RSVP hops that have been 289 traversed so far. 291 The H flag indicates how the reply should be returned. When H = 0, 292 DREP packets should be sent to the response address directly. If H = 293 1, DREP packets must be returned to the LAST-HOP address in a hop- 294 by-hop way. The node specified by the LAST-HOP address then forwards 295 DREP packets to the response address. 297 The MF flag means "more fragments". It must be set to zero (0) on 298 all DREQ packets, and set to one (1) on all DREP packets that carry 299 partial results and are returned by intermediate routers due to the 300 MTU limit. When the sender converts a DREQ packet to DREP, the MF 301 flag remains zero. An intermediate router may also converts a DREQ 302 packet to DREP when the DREQ packet has traversed the specified 303 number of Max-RSVP-hops, in which case the MF flag remains zero. 305 Message ID identifies an individual DREQ packet and the corresponding 306 reply (or all the fragments of the reply). A possible way of using 307 the message ID is the 16 bits to specify the ID of the process doing 308 the query and the low 16 bits to be the sequence number of the query. 309 This way processes on the same machine can distinguish between each 310 other's replies and between different copies of the same query. 312 The path MTU is a 16-bit field that specifies a default MTU size, in 313 number of bytes, that all diagnostic packets must fit within. 315 Sender Filter-Spec is the IP address plus the port of the sender 316 being traced. The DREQ packet proceeds hop-by-hop towards this 317 address. 319 LAST-HOP address is the IP address of the last hop at the receiving 320 end for the path being traced. The DREQ packet starts collecting 321 information at this node and proceeds toward the sender. 323 Response Address Filter-Spec contains the IP address and the port to 324 which the DREP packet(s) should be sent. This Response Address 325 Filter-Spec specifies the process originating the request. 327 The Next-Hop RSVP_HOP object carries the IP address of the interface 328 to which the DREQ must be forwarded to. This object is updated on a 329 hop by hop basis, and is used for the same reasons that a RESV 330 message contains an RSVP_HOP object. That is, to distinguish logical 331 interfaces and avoid problems caused by routing asymmetries. 333 The session object identifies the RSVP session for which the state 334 information is being collected. 336 Optionally, the diagnostic packet may contain a SELECT object which 337 carries a list of [Class, C-type] pairs, each pair specifies one type 338 of RSVP object the diagnosis invoking client wants to examine. When 339 a SELECT object is included in the DREQ packet, each RSVP router 340 along the way should attach to the response object each type of the 341 objects specified in the SELECT list. In the absence of a SELECT 342 object, the router will attach a set of default objects. 344 The SELECT object has the following format: 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | length | class | c-type | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | class | c-type | class | c-type | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | ................... | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 The Length field represents the total length of the object in number 355 of bytes. 357 Class = 33 359 C-type field is not used at the moment and must be set to zero. 361 The object payload part carries a list of [Class, C-type] pairs. In 362 case where the requested number of objects is an odd number, the last 363 two bytes must be set to zero. 365 Optionally, the diagnostic packet may also contain a ROUTE object, as 366 defined below. The ROUTE object is to be used to return DREP packets 367 hop-by-hop. 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | length | class | c-type | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | reserved | R-pointer | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 + List of RSVP routers | 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 The Length field represents the total length of the object in number 380 of bytes, from which the number of addresses in the RSVP router list 381 can be easily computed. 383 Class = 31. 385 C-type field is used to distinguish between IPv4 (C-type = 1) and 386 IPv6 (Ctype = 2) ROUTE object. 388 R-pointer is used in DREP packets only (see Section 4.2 for details), 389 but is incremented as each hop adds its incoming interface address in 390 the ROUTE object. 392 In a DREQ packet, the List of RSVP routers lists all the RSVP hops 393 between the LAST-HOP address, as specified in the Diagnostic packet 394 header object, and the last RSVP router the DREQ packet has visited. 395 In a DREP packet, List of RSVP routers lists all the RSVP hops 396 between the LAST-HOP and the router that returns this DREP packet. 398 3.3. Response Data Object 400 When receiving a DREQ packet, each RSVP router attaches a "response 401 data" object to it before forwarding on. The response data object is 402 defined as follows: 404 0 1 2 3 405 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | length | class | C-type | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | DREQ Arrival Time | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Incoming Interface Address | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Outgoing Interface Address | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Previous-RSVP-Hop Router Address | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | reservation style | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | D-TTL |M|R-err| K | timer value | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 | (TUNNEL object) | 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | | 426 | Tspec object | 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 | filter spec object | 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 | flowspec object | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Class = 32. 440 Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data, 441 respectively. 443 DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival 444 time of the DREQ packet at this router. The 32-bit form of an NTP 445 timestamp consists of the middle 32 bits of the full 64-bit form; 446 that is, the low 16 bits of the integer part and the high 16 bits of 447 the fractional part. 449 Incoming Interface Address specifies the IP address of the interface 450 on which packets from the sender, as defined in the Diagnostic Packet 451 Header, are expected to arrive, or 0 if unknown. 453 Outgoing Interface Address specifies the IP address of the interface 454 from which the DREQ packet comes, and to which packets from the given 455 sender and for the specified session address flow, or 0 if unknown. 457 Previous-RSVP-Hop Router Address specifies the router from which this 458 router receives RSVP PATH messages for this source, or 0 if unknown. 460 Notice that the response object format as shown above assumes IPv4 461 addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2), 462 these three addresses will be 16 bytes each. 464 Reservation style is the 4-byte value of RSVP Style Object as defined 465 in the RSVP specification. 467 D-TTL contains the routing hop count this DREQ packet traveled from 468 the down-stream RSVP router to the current router. 470 M is a single-bit flag which indicates whether the reservation, as 471 described by the objects below, is merged with reservations from 472 other downstream interfaces when being forwarded upstream. 474 R-error is a 3-bit field that indicates error conditions at a router. 475 Currently defined values are 476 0x00: no error 477 0x01: no PATH state 478 0x02: MTU too big 479 0x04: ROUTE object too big 481 K is the refresh timer parameter defined in RSVP, and timer value is 482 the local refresh timer value in seconds. 484 The next part, TUNNEL object, is an optional one which should be 485 inserted when a DREQ packet arrives at an RSVP router that acts as a 486 tunnel exit point. The TUNNEL object provides mapping between the 487 end-to-end RSVP session that is being diagnosed and the RSVP session 488 over the tunnel. This mapping information allows the diagnosis client 489 to conduct diagnosis over the involved tunnel session when so 490 desired, by invoking a separate Diagnostic query for the 491 corresponding Tunnel Session and Tunnel Sender. Keep in mind, 492 however, that multiple end-to-end sessions may all map to one pre- 493 configured tunnel session which may have totally different parameter 494 settings. 496 The tunnel object is defined in the RSVP Tunnel Specification 497 [RSVPTUN], with the following format: 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | length | class | c-type | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | | 503 | Session object (for the end-to-end session) | 504 | | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | | 507 | Sender Filter-Spec (for the tunnel sender) | 508 | | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 SESSION_ASSOC Object 513 Class=192. Ctype 1 specifies IPv4 sessions, Ctype 2 specifies IPv6 514 sessions, and Ctypes 3 and 4 specify sessions with IPSEC Generalized 515 Port Id for IPv4 and IPv6 respectively. 517 The remaining parts, Tspec, filter spec, and flowspec objects follow 518 the definitions given in RSVP specification. The latter two may be 519 absent (see Section 4.1 on DREQ forwarding). In the case of a SE 520 reservation the filter spec is actually the set of all filter specs 521 that share the reservation. The flowspec describes the actual 522 reservation in place. 524 Also note that the length of these object is varying so the lengths 525 used on the diagram above are not representative. 527 4. Diagnostic Packet Forwarding Rules 529 4.1. DREQ Packet Forwarding 531 DREQ packets are forwarded via hop-by-hop unicast from the LAST-HOP 532 address to the Sender address as specified in the diagnostic packet 533 header. Each hop performs the following processing before forwarding 534 the packet to the next hop towards the sender: 536 1. Compute the routing hop count from the previous RSVP hop. This 537 is done by subtracting the value of the TTL value in the IP 538 header from Send_TTL in RSVP common header. The result is then 539 saved in the D-TTL field of the response data object. 541 2. If no PATH state exists for the specified session, set R-error = 542 0x01 in the Response Data object. 544 3. If the path MTU value is too large, set "MTU too large" error 545 bit, and change the MTU value to the MTU value of the incoming 546 interface for PATH messages for the current router. 548 4. Attach the response data object to the end of the DREQ packet. 549 If the DREQ packet contains a SELECT object, attach one copy of 550 each of the objects specified in the SELECT. Otherwise attach 551 Tspec, filter spec, and flowspec objects to the response object. 552 Tspec, filter spec, and flowspec objects describe the 553 reservation in place at the Outgoing Interface for the specified 554 session. 556 If no reservation state exists for the specified RSVP session, 557 the response object will contain no filter-spec or flowspec 558 object. 560 If neither PATH nor reservation state exists for the specified 561 RSVP session, then the response object contains none of the 562 Tspec, filter or flow spec object. 564 5. Increment the RSVP-hop-count field in the diagnostic packet 565 header by one. If the resulting value is equal to that of Max- 566 RSVP-hops, or if the current hop is the sender as identified by 567 the "Source Address" in the RSVP diagnostic header, go to 568 Send_DREP(), and then return. 570 6. If any error bit is set, change the type field in RSVP common 571 header from DREQ to DREP, recompute the checksum and send the 572 packet back to either the LAST-HOP address (if H = 1), or to the 573 response address directly via unicast (if H = 0). 575 7. If the resulting DREQ packet size exceeds the MTU limit, minus 576 some margin to hold the address list object as described below, 577 go to Send_DREP(). 579 8. If no error bit set ,then if the H-bit is set, append the 580 "Incoming Interface Address" to the end of the ROUTE object, 581 increment R-Pointer by one, update the Next-Hop RSVP_HOP object 582 to be the Previous Hop from the Path State and update the packet 583 length field in the RSVP common header accordingly. Finally 584 forward the DREQ packet to the next hop towards the source, 585 after recomputing the checksum. 587 Send_DREP(): 589 1. If the H flag in the Diagnostic Header header is off, set 590 target=response address given in the DREQ header, else set 591 target = the last address in ROUTE. 593 2. Make a copy of the DREQ packet and change the type field in RSVP 594 common header from DREQ to DREP. If this host is not the source 595 set the MF flag on. 597 If the ROUTE object is so large such that (size of ROUTE + size 598 of response data object) > path MTU, then set the "route too 599 big" error bit, recompute the checksum, send the response packet 600 and go to 4, else recompute the checksum and send the response 601 packet. 603 3. If this host is not the source, then trim off all the response 604 data objects from the original DREQ packet, adjust the "Fragment 605 offset" value in the RSVP common header accordingly and forward 606 the modified DREQ packet towards the source, after recomputing 607 the checksum. 609 4. Return. 611 4.2. DREP Forwarding 613 When the H flag is off, DREP packets are sent directly to the 614 original requester. When H flag is on, however, they are forwarded 615 hop-by-hop towards the requester, by reversing the route as listed in 616 the Route object. 618 When a router receives a DREP packet, it simply decreases R-pointer 619 by one (address length), and forward the packet to the address 620 pointed by R-pointer in the route list. 622 When the LAST-HOP router receives a DREP packet, it sends the packet 623 to the Response address. 625 4.3. MTU Selection and Adjustment 627 Because the DREQ packet carries the allowed MTU size of previous hops 628 that the DREP packets will later traverse, this unique feature allows 629 the easy semantic fragmentation as described above. Whenever the 630 DREQ packet grows to approach the size of MTU, it can be trimmed 631 before being forwarded again. 633 When a requester sends a DREQ packet, the path MTU field in the RSVP 634 Diagnostic Packet header can be set to a configured default value. 636 Whenever a DREQ packet size approaches the specified MTU value, an 637 intermediate RSVP router makes a copy of the packet, converts it to a 638 DREP packet to send back, and then trims off the partial results from 639 DREQ packet and forwards it. 641 It is possible that the original MTU value is chosen larger than the 642 actual MTU value along some portion of the path being traced. 643 Therefore each intermediate RSVP router must check the MTU value when 644 processing a DREQ packet. If the specified MTU value is larger than 645 the MTU of the incoming interface (that the DREQ packet will be 646 forwarded to), the router 648 (1) sets the R-error value, 649 (2) changes the MTU value in the header to the smaller value, and 650 (3) converts the DREQ packet to a DREP and sends it back to the 651 requester. 653 In the rare case where some intermediate routers do not check, or 654 enforce upon, the MTU value carried in the diagnostic packets, it is 655 possible that on the way back to the requester, a DREP packet may 656 encounter a link of smaller MTU. 658 When this happens, the router follows steps (1) and (2) as outlined 659 above, and trims off the extra part of the DREP packet to fit in the 660 smaller MTU of the link. The trimming must be done at response 661 object boundaries. Such trimming of packets results in information 662 loss. However because the requester learns what is the available MTU 663 size, it can either ignore the loss, or otherwise try again with the 664 smaller MTU value. 666 4.4. Errors 668 If an error condition prevents a DREP packet from being forwarded 669 further, the packet is simply dropped. 671 If an error condition, such as lack of PATH state, prevents a DREQ 672 packet from being forwarded further, the router must change the 673 current packet to DREP type and return it to the response address. 675 5. Problem Diagnosis by Using RSVP Diagnostic Facility 677 5.1. Across Firewalls 679 Firewalls may cause problems in diagnostic packet forwarding. Let us 680 look at two different cases. 682 First, let us assume that the querier resides on a receiving host of 683 the session to be examined. In this case, firewalls should not 684 prevent the forwarding of the diagnostic packets in a hop-by-hop 685 manner, assuming that proper holes have been punched on the firewall 686 to allow hop-by-hop forwarding of other RSVP packets. The querier 687 may start by setting the H flag off, which can give a faster response 688 delivery and reduced overhead at intermediate routers. However if no 689 response is received, the querier may resend the DREQ packet with H 690 flag turned on. 692 If the requester is a third party host and is separated from the 693 LAST-HOP address by a firewall (either the requester is behind a 694 firewall, or the LAST-HOP is a router behind a firewall, or both), at 695 this time we do not know any other solution but to change the LAST- 696 HOP to a node that is on the same side of the firewall as the 697 requester. 699 5.2. Examination of RSVP Timers 701 One can easily collect information about the current timer value at 702 each RSVP hop along the way. This will be very helpful in situations 703 when the reservation state goes up and down frequently, to find out 704 whether the state changes are due to improper setting of timer 705 values, or K values (when across lossy links), or frequent routing 706 changes. 708 5.3. Discovering Non-RSVP Clouds 710 The D-TTL field in each response data block shows the number of 711 routing hops between adjacent RSVP routers. Therefore any value 712 greater than one indicates a non-RSVP clouds in between. Together 713 with the arrival timestamps (assuming NTP works), this value can also 714 give some vague, though not necessarily accurate, indication of how 715 big that cloud might be. One might also find out all the 716 intermediate non-RSVP routers by running either unicast or multicast 717 trace route. 719 5.4. Discovering Reservation Merges 721 The flowspec value in a response data block specifies the amount of 722 resources being reserved for the data stream defined by the filter 723 spec in the same data block. When this value of adjacent response 724 data blocks differs, that is, a downstream router Rd has a smaller 725 value than its immediate upstream router Ru, it indicates a merge of 726 reservation with RSVP request(s) from other down stream interface(s) 727 at Rd. Further, in case of SE style reservation, one can examine how 728 the different SE scopes get merged at each hop. 730 In particular, if a receiver sends a DREQ packet before sending its 731 own reservation, it can discover (1) how many RSVP hops there are 732 along the path between the specified sender and itself, (2) how many 733 of the hops already have some reservation by other receivers, and (3) 734 possibly a rough prediction of how its reservation request might get 735 merged with other existing ones. 737 5.5. Error Diagnosis 739 In addition to examining the state of a working reservation, RSVP 740 diagnostic packets are more likely to be invoked when things are not 741 working correctly. For example, a receiver has reserved an adequate 742 pipe for a specified incoming data stream, yet the observed delay or 743 loss ratio is much higher than expected. In this case the receiver 744 can use the diagnostic facility to examine the reservation state at 745 each RSVP hop along the way to find out whether the RSVP state is set 746 up correctly, whether there is any blackhole along the way that 747 caused RSVP message losses, or whether there are non-RSVP clouds, and 748 where they are, that may have caused the performance problem. 750 5.6. Crossing "Legacy" RSVP Routers 752 Given that this diagnosis function is developed and added to RSVP 753 after a number of RSVP implementations have been in place, it is 754 possible, or even likely, that when performing RSVP diagnosis, one 755 may encounter one or more RSVP-capable routers that do not understand 756 diagnostic packets, thus drop them. When this happens, the invoking 757 client will get no response from its requests. 759 One way to by-pass such "legacy" RSVP routers is running an iteration 760 of RSVP diagnosis by using information from traceroute, or mtrace in 761 case of multicast. When an RSVP diagnostic query times out (see next 762 section), one may first use traceroute to get the list of routers 763 along the path, and then gradually increases the value of Max-RSVP- 764 hops field in the DREQ packet, starting from a low value until one no 765 longer receives a response. One can then try RSVP diagnosis again by 766 starting with the first router (which is further upstream towards the 767 sender) after the unresponding one. 769 6. Comments on Diagnostic Client Implementation. 771 Following the design principle that routers in the network should not 772 hold more than necessary state, RSVP nodes are responsible only for 773 forwarding Diagnostic packets and filling Response Data Objects. 774 Additional diagnostic functionalities should be carried out by the 775 Diagnostic Clients. Furthermore, if the diagnostic function is 776 invoked from a third-party host, we should not not require that host 777 be running RSVP daemon to perform the function. Below we sketch out 778 the basic functions that a diagnostic client daemon should carry out. 780 1. Take input from the user about the session to be diagnosed, the 781 last-hop and the sender address, the Max-RSVP-hops, and possibly 782 the SELECT list, create a DREQ packet and send to the LAST-HOP 783 RSVP node using raw IP packet with protocol number 46 (RSVP). 784 The port of the UDP socket that the Diagnostic Client is 785 listening to for replies, should be included in the Response 786 Address Filter-Spec. 788 2. Set a retransmission timer, waiting for the reply (one or more 789 DREP packets). Listen to the UDP port specified in the Response 790 Address Filter-Spec for responses from the LAST-HOP RSVP node. 792 The LAST-HOP RSVP node upon receiving DREP packets sends them to 793 the the Diagnostic Client as UDP packets, using the port 794 supplied to in the Response Address Filter-Spec. 796 3. Upon receiving a DREP packet to an outstanding diagnostic 797 request, the client should clear the retransmission timer, check 798 to see if the reply contains the complete result of the 799 requested diagnosis. If so, it should pass the result up to the 800 invoking entity immediately. 802 4. Reassemble DREP fragments. If the first reply to an outstanding 803 diagnostic request contains only a fragment of the expected 804 result, the client should set up a reassembly timer in a way 805 similar to IP packet reassembly timer. If the timer goes off 806 before all fragments arrive, the client should pass the partial 807 result to the invoking entity. 809 5. Use retransmission and reassembly timers to gracefully handle 810 packet losses and reply fragment scenarios. In the absence of 811 response to the first diagnostic request, a client should 812 retransmit the request a few times. If all the retransmissions 813 also fail, the client should invoke traceroute or mtrace to 814 obtain the list of hops along the path segment to be diagnosed, 815 and then perform an iteration of diagnosis with increasing hop 816 count as suggested in Section 5.6 in order to cross RSVP-capable 817 but diagnosis-incapable routers. 819 6. If all the above efforts fail, the client must notify the 820 invoking entity. 822 7. Security Considerations 824 RSVP Diagnostics, as any other diagnostic tool, can be a security 825 threat since it can reveal possibly sensitive RSVP state information 826 to unwanted third parties. 828 We feel that the threat is minimal, since as explained in the 829 Introduction Diagnostics messages produce no side-effects and 830 therefore they cannot change RSVP state in the routers. In this 831 respect RSVP Diagnostics is less a security threat than other 832 diagnostic tools and protocols such as SNMP. 834 Furthermore, processing of Diagnostic messages can be disabled if it 835 is felt that is a security threat. 837 8. Acknowledgments 839 The idea of developing a diagnostic facility for RSVP was first 840 suggested by Mark Handley of UCL. Many thanks to Lee Breslau of 841 Xerox PARC and John Krawczyk of Baynetworks for their valuable 842 comments on the first draft of this memo. Lee Breslau, Bob Braden, 843 and John Krawczyk contributed further comments after March 1996 IETF. 844 Steven Berson provided valuable comments on various drafts of the 845 memo. We would also like to acknowledge Intel for providing a 846 research grant as a partial support for this work. 848 9. References 850 [RSVPTUN] L. Zhang, A. Terzis, "RSVP Operation Over IP Tunnels ", 851 Internet Draft draft-ietf-rsvp-tunnel-02.txt, November, 1997. 853 10. Authors' Addresses 855 Lixia Zhang 856 UCLA 857 4531G Boelter Hall 858 Los Angeles, CA 90095 859 Phone: 310-825-2695 860 EMail: lixia@cs.ucla.edu 862 Andreas Terzis 863 UCLA 864 4677 Boelter Hall 865 Los Angeles, CA 90095 867 Phone: 310-267-2190 868 Email: terzis@cs.ucla.edu 870 Subramaniam Vincent