idnits 2.17.1 draft-ietf-rsvp-diagnostic-msgs-03.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-20) 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 223: '...ts, the checksum MUST be verified befo...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 162 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 (November 1997) is 9653 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 360, but not defined == Missing Reference: 'C-type' is mentioned on line 360, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-rsvp-tunnel-02 Summary: 10 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: May 1998 UCLA 5 November 1997 6 RSVP Diagnostic Messages 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Distribution of this memo is unlimited. 30 This Internet Draft expires in May, 1998. 32 Abstract 34 This document specifies the RSVP diagnosis facility. As the 35 deployment of RSVP is spreading out, it becomes clear that a method 36 for collecting information about the RSVP state along the path is 37 needed. This specification describes the functionality, diagnostic 38 message formats, and processing rules. 40 1. Introduction 42 In the original design of the RSVP protocol, error messages are the 43 only means for the end hosts to receive feedback information 44 regarding a specific request that has failed, a failure in setting up 45 either a PATH state or reservation state. In the absence of 46 failures, one receives no feedback regarding the details of a 47 reservation that has been put in place, such as whether, or where, or 48 how, one's own reservation request is merged with that of others. In 49 case of a failure, the error message carries back only the 50 information from the failed point, without any information about the 51 state at other hops before or after the failure. Such missing 52 information, however, can be highly desirable for debugging purpose, 53 or for network resource management in general. 55 This document specifies RSVP diagnostic messages that allows one to 56 collect information of RSVP state along the path from a receiver to a 57 specific sender. Diagnostic messages are independent from any other 58 RSVP control messages and produce no side-effects. That is, they do 59 not change any RSVP state at either routers or hosts. Similarly, 60 they do not represent an error report but a collection of RSVP state 61 information as requested. 63 We have the following design goals in mind: 65 - To be able to collect RSVP state information at every hop along 66 the path where the PATH state has been set up, either for an 67 existing reservation or before a reservation request is made; 68 here the "hop" means RSVP-capable routers. 70 More specifically, we want to be able to collect information 71 about flowspec, refresh timer values, and reservation merging at 72 each hop along the path. 74 - To be able to collect the routing hop count for each non-RSVP 75 cloud. 77 - To avoid diagnostic packet implosion or explosion. 79 The following are specifically identified as non-goals: 81 - Checking the resource availability along a path. Such 82 functionality may be useful for future reservation requests, but 83 would require modifications to existing admission control module 84 which is beyond the scope of RSVP. 86 2. Overview 88 We define two types of RSVP diagnostic packets, diagnostic request 89 (DREQ) and reply (DREP). This diagnostic tool can be invoked by a 90 client from any host that may or may not be a participant of the RSVP 91 session to be diagnosed. Thus generally speaking three nodes are 92 involved in performing the diagnostic function: the requester, the 93 starting and the ending nodes of the diagnosis, as shown in Figure 1. 94 It is possible that the client invoking the diagnosis function may 95 reside directly on the LAST-HOP, in which case that the first two 96 nodes are the the same. The starting node of the diagnosis is named 97 "LAST-HOP", meaning the last-hop of the path segment to be diagnosed, 98 which can be either the receiving end or an intermediate router along 99 a reserved path. The ending node is the sender host in general, 100 although one can also limit the length of the path segment to be 101 diagnosed by specifying a hop-count limit for the diagnosis messages. 102 To avoid packet implosion or explosion, all diagnostic packets are 103 forwarded via unicast only. 105 A client invokes RSVP diagnostic functions by generating a DREQ 106 packet and sending to the LAST-HOP node which should be on the RSVP 107 path to be diagnosed. This DREQ packet specifies the RSVP session 108 and a sender host to that session. The DREQ packet starts collecting 109 information at the LAST-HOP node and proceeds toward the sender (see 110 Figure 1). 112 Receiver LAST-HOP Sender 113 __ __ __ __ __ __ __ 114 | |---------| |------>| |-->| |-->| |-->| |---->| | 115 |__| |__| DREQ |__| |__| |__| |__| |__| 116 ^ 117 | RSVP routers 118 | 119 |request 120 _|_ 121 | | Requester 122 |___| 124 Figure 1 126 Each RSVP-capable router receiving the DREQ packet adds to the packet 127 a response data object containing the router's RSVP state for the 128 specified RSVP session, and then forwards the request via unicast to 129 the router that it believes to be the previous hop for the given 130 sender. Each subsequent RSVP router attaches its own response data 131 object to the end of the DREQ packet, then forwards via unicast to 132 the previous hop. When the DREQ packet reaches the sender, the 133 sender changes the packet type to Diagnostic Reply (DREP) and sends 134 the completed response to the original requester. Partial response 135 may also be returned before the DREQ packet reaches the sender if any 136 error condition along the path, such as "no path state", prevents 137 further forwarding of the DREQ packet, or if the specified hop-count 138 for the diagnosis has been reached. 140 DREP packets can be unicast back to the requester either directly, or 141 in a hop-by-hop manner by reversing the exact path that the DREQ 142 packet has taken. The former is faster and more efficient, but the 143 latter may be the only choice if the packets have to cross firewalls, 144 due to the way that firewalls operate. 146 To facilitate the latter case, a DREQ packet may optionally carry a 147 ROUTE object, which is a list of router addresses that the DREQ 148 packet has passed through on the way to the sender; this ROUTE object 149 is built incrementally as the DREQ packet passes through the 150 intermediate routers. The DREP packet can then be returned to the 151 requester by reversing the path. 153 When the path consists of many hops, it is possible that the total 154 length of a DREP packet will exceed the path MTU size before reaching 155 the sender, thus the packet has to be fragmented. Relying on IP 156 fragmentation and reassembly, however, can be problematic, especially 157 when DREP packets are returned to the requester hop-by-hop, in which 158 case fragmentation/reassembly would have to be performed at every 159 hop. To avoid such excessive overhead, we let the requester define a 160 default path MTU size which is carried in every DREQ packet. If an 161 intermediate router finds that the default MTU size is bigger than 162 that of the outgoing link, it returns the DREQ packet with the 163 corresponding error bit set. If an intermediate router detects that 164 a DREQ packet size reaches the MTU size, it sends a partial DREP, 165 consisting of the collected responses back, to the requester and then 166 continues to forward the trimmed DREQ packet to the next hop towards 167 the sender. 169 Through out this document we use the word "DREQ packet", rather the 170 word "message" to call a diagnostic request since it always consists 171 of a single packet. On the other hand, one DREQ packet can generate 172 multiple DREP packets, each containing a fragment of the total reply. 173 Furthermore, when discussing diagnostic packet handling, the 174 terminology used refers to the direction of data packet flow, thus 175 "outgoing interface" of a router is the interface a DREQ packet comes 176 from. THE DREQ then gets forwarded to an "incoming interface", 177 because DREQ packets travel in the reverse direction of the data 178 flow. 180 Notice that one can forward DREQ packets only after the RSVP PATH 181 state has been set up. If no PATH state exists, one may resort to 182 the traceroute or mtrace facility to examine whether the 183 unicast/multicast routing is working correctly. 185 3. Diagnostic Packet Format 187 A diagnostic packet consists of the following parts: 189 +-----------------------------------+ 190 | RSVP common header | 191 +-----------------------------------+ 192 | Diagnostic packet header object | 193 +-----------------------------------+ 194 | session object | 195 +-----------------------------------+ 196 | (optional) SELECT object | 197 +-----------------------------------+ 198 | (optional) ROUTE object | 199 +-----------------------------------+ 200 | zero or more Response Object | 201 +-----------------------------------+ 203 3.1. RSVP Message Common Header 205 In the RSVP message common header, 207 0 1 2 3 208 +-------------+-------------+-------------+-------------+ 209 | Vers | Flags| Type | RSVP Checksum | 210 +-------------+-------------+-------------+-------------+ 211 | Send_TTL | reserved | RSVP Length | 212 +-------------+-------------+-------------+-------------+ 214 The Flags field is unused for now and must be set to zero. 216 Type = 8: DREQ 218 Type = 9: DREP 220 The RSVP Checksum is the 16-bit one's complement of the one's 221 complement sum of the whole diagnosis message (including this 222 header). For computing the checksum, the checksum field is set to 223 zero. When receiving packets, the checksum MUST be verified before 224 processing a packet. 226 Send_TTL: the TTL value that a router puts in the IP packet header 227 when forwarding the DREQ packet to the previous hop. 229 RSVP length: the total length of this diagnostic packet in bytes, 230 including the common header. If this is a DREP packet and the MF 231 flag in the diagnostic packet header (see below) is set, this length 232 field indicate the length of this single DREP fragment, rather than 233 the total length of the the complete DREP reply (which may not be 234 known in advance). 236 3.2. RSVP Diagnostic Packet Header Object 238 Both DREQ and DREP headers are a concatenation of Diagnostic Packet 239 Header Object and an RSVP Session object, as defined below: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | length | class | c-type | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Max-RSVP-hops | RSVP-hop-count| Reserved |H|MF| 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Message ID | 249 +---------------+---------------+---------------+---------------+ 250 | path MTU | Fragment offset | 251 +---------------+---------------+---------------+---------------+ 252 | | 253 | Sender Filter-Spec | 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | LAST-HOP Address | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 | Response Address Filter-Spec | 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 | Next-Hop RSVP_HOP Object | 264 | | 265 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 266 | | 267 + Followed by RSVP Session Object | 268 | | 270 Length is the length of this diagnostic header object. 272 Class = 30. 274 C-type field is used to distinguish between IPv4 (C-type = 1) and 275 IPv6 (Ctype = 2). In the IPv6 case addresses will be 16 bytes each. 277 Max-RSVP-hops specifies the maximum number of RSVP hops that the 278 requester wants to collect information from. In case an error 279 condition in the middle of the path prevents the DREQ packet from 280 reaching the specified sender, one may use this field to perform an 281 expanding-length search to reach the point just before the problem. 283 The fragment offset field indicates where in the total reply this 284 fragment belongs. The fragment offset is measured in octets. The 285 first fragment has offset zero. 287 RSVP-hop-count field records the number of RSVP hops that have been 288 traversed so far. 290 The H flag indicates how the reply should be returned. When H = 0, 291 DREP packets should be sent to the response address directly. If H = 292 1, DREP packets must be returned to the LAST-HOP address in a hop- 293 by-hop way. The node specified by the LAST-HOP address then forwards 294 DREP packets to the response address. 296 The MF flag means "more fragments". It must be set to zero (0) on 297 all DREQ packets, and set to one (1) on all DREP packets that carry 298 partial results and are returned by intermediate routers due to the 299 MTU limit. When the sender converts a DREQ packet to DREP, the MF 300 flag remains zero. An intermediate router may also converts a DREQ 301 packet to DREP when the DREQ packet has traversed the specified 302 number of Max-RSVP-hops, in which case the MF flag remains zero. 304 Message ID identifies an individual DREQ packet and the corresponding 305 reply (or all the fragments of the reply). A possible way of using 306 the message ID is the 16 bits to specify the ID of the process doing 307 the query and the low 16 bits to be the sequence number of the query. 308 This way processes on the same machine can distinguish between each 309 other's replies and between different copies of the same query. 311 The path MTU is a 16-bit field that specifies a default MTU size, in 312 number of bytes, that all diagnostic packets must fit within. 314 Sender Filter-Spec is the IP address plus the port of the sender 315 being traced. The DREQ packet proceeds hop-by-hop towards this 316 address. 318 LAST-HOP address is the IP address of the last hop at the receiving 319 end for the path being traced. The DREQ packet starts collecting 320 information at this node and proceeds toward the sender. 322 Response Address Filter-Spec contains the IP address and the port to 323 which the DREP packet(s) should be sent. This Response Address 324 Filter-Spec specifies the process originating the request. 326 The Next-Hop RSVP_HOP object carries the IP address of the interface 327 to which the DREQ must be forwarded to. This object is updated on a 328 hop by hop basis, and is used for the same reasons that a RESV 329 message contains an RSVP_HOP object. That is, to distinguish logical 330 interfaces and avoid problems caused by routing asymmetries. 332 The session object identifies the RSVP session for which the state 333 information is being collected. 335 Optionally, the diagnostic packet may contain a SELECT object which 336 carries a list of [Class, C-type] pairs, each pair specifies one type 337 of RSVP object the diagnosis invoking client wants to examine. When 338 a SELECT object is included in the DREQ packet, each RSVP router 339 along the way should attach to the response object each type of the 340 objects specified in the SELECT list. In the absence of a SELECT 341 object, the router will attach a set of default objects. 343 The SELECT object has the following format: 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | length | class | c-type | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | class | c-type | class | c-type | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | ................... | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 The Length field represents the total length of the object in number 354 of bytes. 356 Class = 33 358 C-type field is not used at the moment and must be set to zero. 360 The object payload part carries a list of [Class, C-type] pairs. In 361 case where the requested number of objects is an odd number, the last 362 two bytes must be set to zero. 364 Optionally, the diagnostic packet may also contain a ROUTE object, as 365 defined below. The ROUTE object is to be used to return DREP packets 366 hop-by-hop. 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | length | class | c-type | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | reserved | R-pointer | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | 374 + List of RSVP routers | 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 The Length field represents the total length of the object in number 379 of bytes, from which the number of addresses in the RSVP router list 380 can be easily computed. 382 Class = 31. 384 C-type field is used to distinguish between IPv4 (C-type = 1) and 385 IPv6 (Ctype = 2) ROUTE object. 387 R-pointer is used in DREP packets only (see Section 4.2 for details), 388 but is incremented as each hop adds its incoming interface address in 389 the ROUTE object. 391 In a DREQ packet, the List of RSVP routers lists all the RSVP hops 392 between the LAST-HOP address, as specified in the Diagnostic packet 393 header object, and the last RSVP router the DREQ packet has visited. 394 In a DREP packet, List of RSVP routers lists all the RSVP hops 395 between the LAST-HOP and the router that returns this DREP packet. 397 3.3. Response Data Object 399 When receiving a DREQ packet, each RSVP router attaches a "response 400 data" object to it before forwarding on. The response data object is 401 defined as follows: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | length | class | C-type | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | DREQ Arrival Time | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Incoming Interface Address | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Outgoing Interface Address | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Previous-RSVP-Hop Router Address | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | reservation style | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | D-TTL |M|R-err| K | timer value | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 | (TUNNEL object) | 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | 425 | Tspec object | 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | | 429 | filter spec object | 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 | flowspec object | 434 | | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Class = 32. 439 Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data, 440 respectively. 442 DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival 443 time of the DREQ packet at this router. The 32-bit form of an NTP 444 timestamp consists of the middle 32 bits of the full 64-bit form; 445 that is, the low 16 bits of the integer part and the high 16 bits of 446 the fractional part. 448 Incoming Interface Address specifies the IP address of the interface 449 on which packets from the sender, as defined in the Diagnostic Packet 450 Header, are expected to arrive, or 0 if unknown. 452 Outgoing Interface Address specifies the IP address of the interface 453 from which the DREQ packet comes, and to which packets from the given 454 sender and for the specified session address flow, or 0 if unknown. 456 Previous-RSVP-Hop Router Address specifies the router from which this 457 router receives RSVP PATH messages for this source, or 0 if unknown. 459 Notice that the response object format as shown above assumes IPv4 460 addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2), 461 these three addresses will be 16 bytes each. 463 Reservation style is the 4-byte value of RSVP Style Object as defined 464 in the RSVP specification. 466 D-TTL contains the routing hop count this DREQ packet traveled from 467 the down-stream RSVP router to the current router. 469 M is a single-bit flag which indicates whether the reservation, as 470 described by the objects below, is merged with reservations from 471 other downstream interfaces when being forwarded upstream. 473 R-error is a 3-bit field that indicates error conditions at a router. 474 Currently defined values are 475 0x00: no error 476 0x01: no PATH state 477 0x02: MTU too big 478 0x04: ROUTE object too big 480 K is the refresh timer parameter defined in RSVP, and timer value is 481 the local refresh timer value in seconds. 483 The next part, TUNNEL object, is an optional one which should be 484 inserted when a DREQ packet arrives at an RSVP router that acts as a 485 tunnel exit point. The TUNNEL object provides mapping between the 486 end-to-end RSVP session that is being diagnosed and the RSVP session 487 over the tunnel. This mapping information allows the diagnosis client 488 to conduct diagnosis over the involved tunnel session when so 489 desired, by invoking a separate Diagnostic query for the 490 corresponding Tunnel Session and Tunnel Sender. Keep in mind, 491 however, that multiple end-to-end sessions may all map to one pre- 492 configured tunnel session which may have totally different parameter 493 settings. 495 The tunnel object is defined in the RSVP Tunnel Specification 496 [RSVPTUN], with the following format: 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | length | class | c-type | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | | 502 | Session object (for the end-to-end session) | 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | | 506 | Sender Filter-Spec (for the tunnel sender) | 507 | | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 SESSION_ASSOC Object 512 Class=192. Ctype 1 specifies IPv4 sessions, Ctype 2 specifies IPv6 513 sessions, and Ctypes 3 and 4 specify sessions with IPSEC Generalized 514 Port Id for IPv4 and IPv6 respectively. 516 The remaining parts, Tspec, filter spec, and flowspec objects follow 517 the definitions given in RSVP specification. The latter two may be 518 absent (see Section 4.1 on DREQ forwarding). In the case of a SE 519 reservation the filter spec is actually the set of all filter specs 520 that share the reservation. The flowspec describes the actual 521 reservation in place. 523 Also note that the length of these object is varying so the lengths 524 used on the diagram above are not representative. 526 4. Diagnostic Packet Forwarding Rules 528 4.1. DREQ Packet Forwarding 530 DREQ packets are forwarded via hop-by-hop unicast from the LAST-HOP 531 address to the Sender address as specified in the diagnostic packet 532 header. Each hop performs the following processing before forwarding 533 the packet to the next hop towards the sender: 535 1. Compute the routing hop count from the previous RSVP hop. This 536 is done by subtracting the value of the TTL value in the IP 537 header from Send_TTL in RSVP common header. The result is then 538 saved in the D-TTL field of the response data object. 540 2. If no PATH state exists for the specified session, set R-error = 541 0x01 in the Response Data object. 543 3. If the path MTU value is too large, set "MTU too large" error 544 bit, and change the MTU value to the MTU value of the incoming 545 interface for PATH messages for the current router. 547 4. Attach the response data object to the end of the DREQ packet. 548 If the DREQ packet contains a SELECT object, attach one copy of 549 each of the objects specified in the SELECT. Otherwise attach 550 Tspec, filter spec, and flowspec objects to the response object. 551 Tspec, filter spec, and flowspec objects describe the 552 reservation in place at the Outgoing Interface for the specified 553 session. 555 If no reservation state exists for the specified RSVP session, 556 the response object will contain no filter-spec or flowspec 557 object. 559 If neither PATH nor reservation state exists for the specified 560 RSVP session, then the response object contains none of the 561 Tspec, filter or flow spec object. 563 5. If any error bit is set, change the type field in RSVP common 564 header from DREQ to DREP, recompute the checksum and send the 565 packet back to either the LAST-HOP address (if H = 1), or to the 566 response address directly via unicast (if H = 0). 568 6. Increment the RSVP-hop-count field in the diagnostic packet 569 header by one. 571 If the resulting value is equal to that of Max-RSVP-hops, or if 572 the current hop is the sender as identified by the "Source 573 Address" in the RSVP diagnostic header, go to Send_DREP(), and 574 then return. 576 7. If the resulting DREQ packet size exceeds the MTU limit, minus 577 some margin to hold the address list object as described below, 578 go to Send_DREP(). 580 8. If no error bit set ,then if the H-bit is set, append the 581 "Incoming Interface Address" to the end of the ROUTE object, 582 increment R-Pointer by one, update the Next-Hop RSVP_HOP object 583 to be the Previous Hop from the Path State and update the packet 584 length field in the RSVP common header accordingly. Finally 585 forward the DREQ packet to the next hop towards the source, 586 after recomputing the checksum. 588 Send_DREP(): 590 1. If the H flag in the Diagnostic Header header is off, set 591 target=response address given in the DREQ header, else set 592 target = the last address in ROUTE. 594 2. Make a copy of the DREQ packet and change the type field in RSVP 595 common header from DREQ to DREP. If this host is not the source 596 set the MF flag on. 598 If the ROUTE object is so large such that (size of ROUTE + size 599 of response data object) > path MTU, then set the "route too 600 big" error bit, recompute the checksum, send the response packet 601 and go to 4, else recompute the checksum and send the response 602 packet. 604 3. If this host is not the source, then trim off all the response 605 data objects from the original DREQ packet, adjust the "Fragment 606 offset" value in the RSVP common header accordingly and forward 607 the modified DREQ packet towards the source, after recomputing 608 the checksum. 610 4. Return. 612 4.2. DREP Forwarding 614 When the H flag is off, DREP packets are sent directly to the 615 original requester. When H flag is on, however, they are forwarded 616 hop-by-hop towards the requester, by reversing the route as listed in 617 the Route object. 619 When a router receives a DREP packet, it simply decreases R-pointer 620 by one (address length), and forward the packet to the address 621 pointed by R-pointer in the route list. 623 When the LAST-HOP router receives a DREP packet, it sends the packet 624 to the Response address. 626 4.3. MTU Selection and Adjustment 628 Because the DREQ packet carries the allowed MTU size of previous hops 629 that the DREP packets will later traverse, this unique feature allows 630 the easy semantic fragmentation as described above. Whenever the 631 DREQ packet grows to approach the size of MTU, it can be trimmed 632 before being forwarded again. 634 When a requester sends a DREQ packet, the path MTU field in the RSVP 635 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 676 5.1. Across Firewalls 678 Firewalls may cause problems in diagnostic packet forwarding. Let us 679 look at two different cases. 681 First, let us assume that the querier resides on a receiving host of 682 the session to be examined. In this case, firewalls should not 683 prevent the forwarding of the diagnostic packets in a hop-by-hop 684 manner, assuming that proper holes have been punched on the firewall 685 to allow hop-by-hop forwarding of other RSVP packets. The querier 686 may start by setting the H flag off, which can give a faster response 687 delivery and reduced overhead at intermediate routers. However if no 688 response is received, the querier may resend the DREQ packet with H 689 flag turned on. 691 If the requester is a third party host and is separated from the 692 LAST-HOP address by a firewall (either the requester is behind a 693 firewall, or the LAST-HOP is a router behind a firewall, or both), at 694 this time we do not know any other solution but to change the LAST- 695 HOP to a node that is on the same side of the firewall as the 696 requester. 698 5.2. Examination of RSVP Timers 700 One can easily collect information about the current timer value at 701 each RSVP hop along the way. This will be very helpful in situations 702 when the reservation state goes up and down frequently, to find out 703 whether the state changes are due to improper setting of timer 704 values, or K values (when across lossy links), or frequent routing 705 changes. 707 5.3. Discovering Non-RSVP Clouds 709 The D-TTL field in each response data block shows the number of 710 routing hops between adjacent RSVP routers. Therefore any value 711 greater than one indicates a non-RSVP clouds in between. Together 712 with the arrival timestamps (assuming NTP works), this value can also 713 give some vague, though not necessarily accurate, indication of how 714 big that cloud might be. One might also find out all the 715 intermediate non-RSVP routers by running either unicast or multicast 716 trace route. 718 5.4. Discovering Reservation Merges 720 The flowspec value in a response data block specifies the amount of 721 resources being reserved for the data stream defined by the filter 722 spec in the same data block. When this value of adjacent response 723 data blocks differs, that is, a downstream router Rd has a smaller 724 value than its immediate upstream router Ru, it indicates a merge of 725 reservation with RSVP request(s) from other down stream interface(s) 726 at Rd. Further, in case of SE style reservation, one can examine how 727 the different SE scopes get merged at each hop. 729 In particular, if a receiver sends a DREQ packet before sending its 730 own reservation, it can discover (1) how many RSVP hops there are 731 along the path between the specified sender and itself, (2) how many 732 of the hops already have some reservation by other receivers, and (3) 733 possibly a rough prediction of how its reservation request might get 734 merged with other existing ones. 736 5.5. Error Diagnosis 738 In addition to examining the state of a working reservation, RSVP 739 diagnostic packets are more likely to be invoked when things are not 740 working correctly. For example, a receiver has reserved an adequate 741 pipe for a specified incoming data stream, yet the observed delay or 742 loss ratio is much higher than expected. In this case the receiver 743 can use the diagnostic facility to examine the reservation state at 744 each RSVP hop along the way to find out whether the RSVP state is set 745 up correctly, whether there is any blackhole along the way that 746 caused RSVP message losses, or whether there are non-RSVP clouds, and 747 where they are, that may have caused the performance problem. 749 5.6. Crossing "Legacy" RSVP Routers 751 Given that this diagnosis function is developed and added to RSVP 752 after a number of RSVP implementations have been in place, it is 753 possible, or even likely, that when performing RSVP diagnosis, one 754 may encounter one or more RSVP-capable routers that do not understand 755 diagnostic packets, thus drop them. When this happens, the invoking 756 client will get no response from its requests. 758 One way to by-pass such "legacy" RSVP routers is running an iteration 759 of RSVP diagnosis by using information from traceroute, or mtrace in 760 case of multicast. When an RSVP diagnostic query times out (see next 761 section), one may first use traceroute to get the list of routers 762 along the path, and then gradually increases the value of Max-RSVP- 763 hops field in the DREQ packet, starting from a low value until one no 764 longer receives a response. One can then try RSVP diagnosis again by 765 starting with the first router (which is further upstream towards the 766 sender) after the unresponding one. 768 6. Comments on Diagnostic Client Implementation. 770 Following the design principle that routers in the network should not 771 hold more than necessary state, RSVP nodes are responsible only for 772 forwarding Diagnostic packets and filling Response Data Objects. 773 Additional diagnostic functionalities should be carried out by the 774 Diagnostic Clients. Furthermore, if the diagnostic function is 775 invoked from a third-party host, we should not not require that host 776 be running RSVP daemon to perform the function. Below we sketch out 777 the basic functions that a diagnostic client daemon should carry out. 779 1. Take input from the user about the session to be diagnosed, the 780 last-hop and the sender address, the Max-RSVP-hops, and possibly 781 the SELECT list, create a DREQ packet and send to the LAST-HOP 782 RSVP node using raw IP packet with protocol number 46 (RSVP). 783 The port of the UDP socket that the Diagnostic Client is 784 listening to for replies, should be included in the Response 785 Address Filter-Spec. 787 2. Set a retransmission timer, waiting for the reply (one or more 788 DREP packets). Listen to the UDP port specified in the Response 789 Address Filter-Spec for responses from the LAST-HOP RSVP node. 791 The LAST-HOP RSVP node upon receiving DREP packets sends them to 792 the the Diagnostic Client as UDP packets, using the port 793 supplied to in the Response Address Filter-Spec. 795 3. Upon receiving a DREP packet to an outstanding diagnostic 796 request, the client should clear the retransmission timer, check 797 to see if the reply contains the complete result of the 798 requested diagnosis. If so, it should pass the result up to the 799 invoking entity immediately. 801 4. Reassemble DREP fragments. If the first reply to an outstanding 802 diagnostic request contains only a fragment of the expected 803 result, the client should set up a reassembly timer in a way 804 similar to IP packet reassembly timer. If the timer goes off 805 before all fragments arrive, the client should pass the partial 806 result to the invoking entity. 808 5. Use retransmission and reassembly timers to gracefully handle 809 packet losses and reply fragment scenarios. In the absence of 810 response to the first diagnostic request, a client should 811 retransmit the request a few times. If all the retransmissions 812 also fail, the client should invoke traceroute or mtrace to 813 obtain the list of hops along the path segment to be diagnosed, 814 and then perform an iteration of diagnosis with increasing hop 815 count as suggested in Section 5.6 in order to cross RSVP-capable 816 but diagnosis-incapable routers. 818 6. If all the above efforts fail, the client must notify the 819 invoking entity. 821 7. Acknowledgments 823 The idea of developing a diagnostic facility for RSVP was first 824 suggested by Mark Handley of UCL. Many thanks to Lee Breslau of 825 Xerox PARC and John Krawczyk of Baynetworks for their valuable 826 comments on the first draft of this memo. Lee Breslau, Bob Braden, 827 and John Krawczyk contributed further comments after March 1996 IETF. 828 Vincent Subramaniam and Steven Berson provided valuable comments on 829 variable drafts of the memo. We would also like to acknowledge Intel 830 for providing a research grant as a partial support for this work. 832 8. References 834 [RSVPTUN] L. Zhang, A. Terzis, "RSVP Operation Over IP Tunnels ", 835 Internet Draft draft-ietf-rsvp-tunnel-02.txt, November, 1997. 837 9. Authors' Addresses 839 Lixia Zhang 840 UCLA 841 4531G Boelter Hall 842 Los Angeles, CA 90095 844 Phone: 310-825-2695 845 EMail: lixia@cs.ucla.edu 847 Andreas Terzis 848 UCLA 849 4677 Boelter Hall 850 Los Angeles, CA 90095 851 Phone: 310-267-2190 852 Email: terzis@cs.ucla.edu