idnits 2.17.1 draft-perkins-manet-aodvqos-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 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 68: '...ed words such as MUST, SHOULD, etc., t...' RFC 2119 keyword, line 76: '...icular, the RREQ MAY include a QoS Obj...' RFC 2119 keyword, line 96: '...ained, that node MUST transmit a ICMP ...' RFC 2119 keyword, line 107: '... RREQ MUST adjust the accumulated va...' RFC 2119 keyword, line 113: '...cified typically SHOULD always rebroad...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 268 has weird spacing: '... Object varl...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2463 (ref. '2') (Obsoleted by RFC 4443) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad Hoc Networking Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 14 October 2003 Elizabeth M. Belding-Royer 4 University of California, Santa Barbara 6 Quality of Service for Ad hoc On-Demand Distance Vector Routing 7 draft-perkins-manet-aodvqos-01.txt 9 Status of This Memo 11 This document is a submission by the Mobile Ad Hoc Networking Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the manet@itd.nrl.navy.mil mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 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 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material 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 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The Ad hoc On-Demand Distance Vector (AODV) routing protocol is 36 intended for use by mobile nodes in an ad hoc network. It offers 37 quick adaptation to dynamic link conditions, low processing and 38 memory overhead, low network utilization, and determines routes 39 between source and destination addresses. To provide quality of 40 service, extensions can be added to the messages used during route 41 discovery. These extensions specify the service requirements which 42 must be met by nodes rebroadcasting a Route Request or returning a 43 Route Reply for a destination. This draft describes how service 44 partners discover routes that can satisfy QoS service conditions by 45 using these extensions. 47 1. Introduction 49 Route discovery in AODV is on-demand and follows a route 50 request/route reply query cycle. When a source is needs a route 51 to a destination, it broadcasts a Route Request (RREQ) control in 52 search of a route. Nodes having a current route to the indicated 53 destination respond by unicasting a Route Reply (RREP) to the source 54 node. To provide quality of service, extensions can be added to 55 these messages during the route discovery process. A node which 56 receives a RREQ with a quality of service extension must agree to 57 meet that service requirement in order to either rebroadcast the RREQ 58 (if it does not have a route to the destination) or unicast a RREP to 59 the source. For more details on the route discovery process, please 60 see the AODV base specification [3]. 62 In particular, this document specifies extensions which can be used 63 to ensure that delay does not exceed a maximum value, or to ensure 64 that a certain amount of network capacity (i.e., bandwidth) is made 65 available along a route between communication partners. 67 This protocol specification uses conventional meanings [1] for 68 capitalized words such as MUST, SHOULD, etc., to indicate requirement 69 levels for various protocol features. 71 2. Quality of Service Overview 73 Using the extensions in this document, AODV enables mobile nodes 74 in an ad hoc network to specify, as part of a RREQ, Quality of 75 Service requirements that a route to a destination must satisfy. 76 In particular, the RREQ MAY include a QoS Object extension (see 77 Section 3) which specifies bandwidth and/or delay parameters. In 78 order to enable measurements to be accumulated for end-to-end delay, 79 AODV also provides an Accumulated Value extension (see Section 4.3). 80 Any QoS parameters that have to be measured and accumulated at each 81 hop along the way can be stored along with the associated RREQ 82 message. 84 Every RREQ QoS extension also carries with it a "session-ID" value 85 which is used to identify the particular QoS flow that will be 86 established according to the parameters of the RREQ. The session-ID 87 has to be stored along with the route table information associated 88 with the particular flow that might be created because of the 89 extended RREQ. Every flow is uniquely identified by the triplet 90 including the source IP address, the destination IP address, and the 91 session-ID. This places a limitation of 65,535 unique flows between 92 any two nodes in an ad hoc network. 94 If, after establishment of such a route, any node along the path 95 detects that the requested Quality of Service parameters can no 96 longer be maintained, that node MUST transmit a ICMP QOS_LOST 97 message back to the node which had originally requested the now 98 unmaintainable level of service. This typically requires additional 99 information to be stored in each per-destination route table entry 100 (see section 4.1). The ICMP QOS_LOST message identifies the broken 101 flow by including the session-ID value associated with the flow. 103 For QoS parameters that are affected by cumulative measures at each 104 intermediate node of a routing path, an extension is defined to 105 enable a running total to be maintained for that measure as the RREQ 106 is propagated. Each intermediate node that elects to forward a 107 RREQ MUST adjust the accumulated value in the extension so that an 108 accurate determination must be made. This approach is better than 109 modifying the values in the QoS object directly, because it enables 110 the original request to be authenticated whenever that is required. 112 An intermediate node that can satisfy a RREQ with QoS parameters 113 specified typically SHOULD always rebroadcast the RREQ, even if it 114 has a route to the destination. This contrasts with the situation 115 with unconstrained RREQ messages, because without any need for QoS 116 an intermediate is allowed to answer with an RREP message if it has 117 a route to the destination. Unfortunately, the intermediate node 118 is not likely to have current enough information about whether the 119 remaining nodes along the path to the destination can also satisfy 120 the requested QoS. Effectively, according to this specification, 121 every QoS path to the destination will be ultimately approved by the 122 destination itself along with every intermedate node along the path 123 from the source to the destination. 125 When the destination issues the RREP message, it MUST also copy 126 over the QoS extension into the RREP message. Each intermediate 127 node forwarding the RREP message back to the originator of the RREQ 128 message also MUST copy over the QoS extension. 130 In the future, if a specification is made enabling an intermediate 131 node to have reliable information about the remaining nodes along 132 the path, then the node could issue an RREP, along with a gratuitous 133 RREP unicast towards the destination. The gratuitous RREP would 134 then enable the remaining nodes to make the appropriate resource 135 reservations that would be needed to satisfy the QoS route discovery 136 request. 138 3. QoS Object Format 140 QoS information is expected to be encoded into a standard format, 141 illustrated in figure 1. The standard format allows both complete 142 flexibility for specification of arbitrary values for various QoS 143 requirements, and also allows very compact representation, especially 144 for the well-known requirements of common applications such as voice 145 over IP (VoIP). In this section, we present the standard object 146 format. This object format is used as the main part of the QoS 147 Object Extension (see section 4.2). 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |A|N|rsv| QoS Profile Type | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Session ID |Non-Dflt Bit Vect. (if present)| 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 :N| Additional Non-Default Values Bit Vector (if present) : 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Authentication Data (32 bits) (if present) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 : QoS fields with non-default values (if present) : 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 : More QoS fields with non-default values (if present) : 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1: QoS Object Format 167 rsv Sent as 0, value unused and undefined on reception 169 QoS Profile Type 170 If nonzero, an index for a list of QoS parameter 171 field definitions and default values for those 172 fields. If zero, the fields are as listed below in 173 this section, and there are no default values. 175 A If this bit is set, the Authentication Data field 176 is present following the bit vectors indicating the 177 non-default values. 179 N If QoS Profile Type is zero, this bit MUST be zero. 180 Otherwise, if if the QoS Profile Type is nonzero, 181 when the `N' bit is set, the 16 bits following the 182 "session-ID" field are present and part of the 183 "Non-Default Values" bit vector 185 Session-ID 16-bit value identifying the flow which could be 186 set up as a result of the extended route discovery 187 operation controlled by this RREQ message. 189 Non-Default Values Bit Vector 190 a bit vector with one bit for each field parameter 191 field defined for the particular QoS Profile Type 192 number. 194 Authentication Data 195 When present, supplies authentication data so that 196 nodes receiving the RREQ can check whether or not the 197 data in the QoS object is the same as specified by 198 the source node. 200 QoS Parameter Fields 201 defined in accordance with the QoS Profile Type. If 202 the profile type is 0, then the fields are as defined 203 below in this section. 205 For QoS Profile Type zero, the following parameter fields are 206 defined, and MUST appear in this order as indicated by the 207 corresponding bit in the "Non-Default Values Bit Vector": 209 Capacity Requirement 210 32-bit number, measured in bits/second 212 Maximum Permissible Delay 213 16-bit number, measured in milliseconds 215 Maximum Permissible Jitter 216 16-bit number, measured in milliseconds 218 Traffic Class 219 According to Differentiated Services Code Points 221 Some fields that might occur for profile type not equal 0 222 Peak data rate, Maximum permissible BER, ... 224 4. Extensions 226 Several extensions are needed in the routing table structure and 227 the RREQ and RREP messages for supporting QoS routing. We first 228 describe the extensions needed for the routing table. The extensions 229 defined in the section after that conform to the format defined for 230 extensions to RREQ and RREP messages as specified in [3]. 232 4.1. Routing Table Extensions 234 Certain fields are conceptually added to each route table entry 235 corresponding to each network node requesting QoS. The fields are 236 needed to notify endpoint nodes in cases where QoS parameter value 237 are agreed upon, but the associated service qualities can no longer 238 be supplied or maintained. The specific additional fields depend on 239 the QoS object field entries (see section 3), but the following list 240 illustrates the general idea. 242 - Session-ID 244 - Maximum Delay 246 - Minimum Available Bandwidth 248 - List of Sources Requesting Delay Guarantees 250 - List of Sources Requesting Bandwidth Guarantees 252 4.2. QoS Object Extension Format 254 A node appends a QoS Object extension to a RREQ in order to disover a 255 path that satisfies the QoS parameters which are present in the QoS 256 Object, which is situated within the QoS Object extension data. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length | QoS Object (variable) ... : 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Type TBD 266 Length variable 268 QoS Object varliable length; as defined in section 3. 270 A node originating a RREQ message MAY append a QoS Object Extension 271 after the RREQ data, optionally followed by one or more Accumulated 272 Value extensions according to the specific data in the QoS Object 273 extension. 275 4.3. Accumulated Value Extension Format 277 The Accumulated Value Extension Format may be applied to RREQ 278 messages containing the QoS Object extension. It provides 279 information about the cumulative value that has been experienced by 280 nodes along the path from the originating node to the node currently 281 processing the RREQ. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type | Length | Value Type | Reserved | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Accumulated Value | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Type TBD 293 Length 2 295 Value Type 8 bits specifying the type of the value stored in the 296 Accumulated Value field. 298 Reserved Sent as zero, ignored on reception 300 Accumulated Value 301 This field indicates the current estimate of 302 cumulative parameter value from the originating node 303 up to the intermediate node retransmitting the RREQ 304 on behalf of the originating node. 306 The Accumulated Value Extension MUST be appended to a RREQ by a node 307 rebroadcasting a request for a QoS route whenever it is needed to 308 measure the accumulated value of the parameter of the type given in 309 the Value Type field; the accumulation occurs at each node starting 310 from the originating node. This allows each next intermediate node, 311 or the destination, to determine whether the path can still meet the 312 required parameter specification within the QoS Object data. 314 The following table gives the currently specified subtype values 315 for the Accumulated Value extension. The last column gives the 316 conventional name of the Accumulated Value extension when used with 317 the particular subtype. 319 Delay == 1 Accumulated Delay Extension 321 Jitter == 2 Accumulated Jitter Extension 323 4.4. QoS Object Authentication Extension 325 The QoS Object Authentication Extension may be used so that nodes 326 receiving QoS route discovery message may verify that the QoS request 327 was in fact originated by the source node. This extension does 328 not verify the contents of any extension other than the QoS Object 329 extension, because other extensions may have mutable fields that are 330 modified in transit. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type | Length |S| Reserved | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | SPI (32 bits) (if present) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 : Authentication Data : 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 2: QoS Object Authentication Extension Format 344 S If this bit is set, the SPI field is present. 346 Authentication Data 347 When present, supplies authentication data so that 348 nodes receiving the RREQ can check whether or not the 349 data in the QoS object is the same as specified by 350 the source node. 352 5. Link Capacity 354 A capacity (bandwidth) specification in a QoS object does not require 355 the inclusion of any Accumulated Value extension in the RREQ. Any 356 node that has sufficient unreserved link capacity to forward data, 357 or in the case of the destination to supply data, does not modify 358 any contents of the RREQ for the purpose of fulfilling a bandwidth 359 specification in the QoS object. 361 Note, however, that in order to properly fulfill such a 362 specification, a node has to take into account neighborhood 363 traffic conditions. If recent history indicates that neighboring 364 transmissions will likely interfere with the node's ability to carry 365 out the indicated bandwidth specification, then the node SHOULD NOT 366 rebroadcast the RREQ. Exact mechanisms for estimating neighborhood 367 traffic levels are beyond the scope of this document. Additional 368 signaling and protocols may be defined in the future in order to 369 obtain a higher probability of collecting the necessary neighborhood 370 bandwidth utilization information. 372 6. Delay 374 If the QoS object in the RREQ specifies a delay parameter, then any 375 node forwarding the request MUST ensure that an Accumulated Delay 376 extension is present in the RREQ before forwarding the message. A 377 node that agrees to satisfy delay constraints has to measure the 378 average time it is currently requiring to forward a data packet, 379 including processing time, average queuing delays and propagation 380 delays. Call this average time the FORWARDING_DELAY. Before 381 forwarding the RREQ, an intermediate node MUST compare the current 382 value of its FORWARDING_DELAY to the current value of the difference 383 between the Maximum Delay value in the QoS object extension, and 384 the value in the Accumulated Delay Extension. If the remaining 385 delay is less, the node MUST discard the RREQ and not retransmit it. 386 Otherwise, the node subtracts FORWARDING_DELAY from the value in the 387 Accumulated Value extension and continues processing the RREQ as 388 specified in [3]. 390 A node forwarding a RREP also records the Source IP address in the 391 RREP message in the list of source nodes requesting delay guarantees 392 in the corresponding destination's route table entry. These source 393 nodes are to be notified with an ICMP QOS_LOST message in case there 394 is a signficant change in FORWARDING_DELAY at this node. 396 7. Jitter 398 If the QoS object in the RREQ specifies a jitter parameter, then any 399 node forwarding the request MUST ensure that an Accumulated Jitter 400 extension is present in the RREQ before forwarding the message. 401 Before forwarding the RREQ, an intermediate node MUST compare its 402 recently computed typical jitter value (call it NODE_JITTER) to the 403 current value of the difference between the Maximum Jitter value in 404 the QoS object extension, and the value in the Accumulated Jitter 405 Extension. If the remaining allowable jitter is less, the node MUST 406 discard the RREQ and not process it any further. Otherwise, the 407 node subtracts NODE_JITTER from the value in the Accumulated Jitter 408 extension and continues processing the RREQ as specified in [3]. 410 A node forwarding a RREP with the QoS extension also records the 411 Source IP address in RREP message in the list of source nodes 412 requesting jitter guarantees in the corresponding destination's route 413 table entry. These source nodes are to be notified with an ICMP 414 QOS_LOST message in case there is a change in NODE_JITTER at this 415 node. 417 8. ICMP QOS LOST Message 419 An ICMP QOS_LOST message is generated when an intermediate node 420 experiences a significant change in its ability to live up to the QoS 421 guarantees it has made as part of generating a RREP during the QoS 422 Route Discovery process. The format of this message is as follows. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Value Type | Session-ID | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Destination IP address | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Type TBD 434 Value Type 435 The type of the parameter which can no longer be guaranteed 436 to conform to the value indicated in the original QoS 437 Object data of the RREQ. The subtype values are as 438 specified in section 4.3. 440 Destination IP address 441 IP address of the destination node using the link for 442 which there has been a change in the QoS parameter of the 443 indicated subtype. 445 The QOS_LOST message is forwarded to all sources potentially affected 446 by the change in the QoS parameter. These are those sources to which 447 a RREP with a QoS extension has been forwarded in the past (see 448 section 4.1 for a method of determining these sources). 450 9. ICMPv6 QOS LOST Message 452 The ICMPv6 QOS_LOST message is generated when an intermediate node 453 experiences a significant change in its ability to live up to th QoS 454 guarantees it has made as part of generating a RREP during the QoS 455 Route Discovery process. The format of this message is as follows. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type | Value Type | Session-ID | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 | 128-bit Destination | 464 | IPv6 address | 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Type TBD 470 Value Type 471 The type of the parameter which can no longer be guaranteed 472 to conform to the value indicated in the original QoS 473 Object data of the RREQ. The subtype values are as 474 specified in section 4.3. 476 Destination IP address 477 IP address of the destination node using the link for 478 which there has been a change in the QoS parameter of the 479 indicated subtype. 481 The QOS_LOST message is forwarded to all sources potentially affected 482 by the change in the QoS parameter. These are those sources to which 483 a RREP with a QoS extension has been forwarded before. These sources 484 are able to be conveniently stored in a list as a part of the route 485 table entry. 487 10. IANA Considerations 489 The type number for the ICMP QoS_LOST message is to be taken from 490 the space of available type numbers for the Internet Control Message 491 Protocol, ICMP [4]. The type number for the ICMPv6 QoS_LOST message 492 is to be taken from the space of available type numbers for the 493 Internet Control Message Protocol for IPv6 [2]. 495 The type numbers for the extensions in section 4 are to be taken from 496 the space of extensions to AODV [3]. 498 11. Security Considerations 500 This draft specifies mechanisms for handling quality of service. It 501 does not introduce any special security vulnerabilities which were 502 not already present in the AODV routing protocol [3]. 504 References 506 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 507 Levels. Request for Comments (Best Current Practice) 2119, 508 Internet Engineering Task Force, Mar. 1997. 510 [2] A. Conta and S. Deering. Internet Control Message Protocol 511 (ICMPv6) for the Internet Protocol version 6 (IPv6) 512 specification. Request for Comments (Draft Standard) 2463, 513 Internet Engineering Task Force, Dec. 1998. 515 [3] C. Perkins, E. Royer, and S. Das. Ad hoc on demand distance 516 vector (AODV) routing (work in progress). Internet Draft, 517 Internet Engineering Task Force, Feb. 2003. 519 [4] J. Postel. Internet Control Message Protocol. Request for 520 Comments (Standard) 792, Internet Engineering Task Force, Sept. 521 1981. 523 Author's Addresses 525 Questions about this memo can be directed to: 527 Charles E. Perkins 528 Communications Systems Laboratory 529 Nokia Research Center 530 313 Fairchild Drive 531 Mountain View, CA 94303 532 USA 533 +1 650 625 2986 534 +1 650 625 2502 (fax) 535 charles.perkins@nokia.com 537 Elizabeth M. Belding-Royer 538 Dept. of Computer Science 539 University of California, Santa Barbara 540 Santa Barbara, CA 93106 541 +1 805 893 3411 542 +1 805 893 8553 (fax) 543 ebelding@cs.ucsb.edu