idnits 2.17.1 draft-kang-dymoqos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 538. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-02 ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad Hoc Networking Working Group Namhi Kang 2 INTERNET DRAFT DASAN Networks Inc. 3 17 October 2005 Younghan Kim 4 University of Soongsil, Korea 6 Quality of Service Extension to 7 Dynamic MANET OnDemand Routing Protocol 8 draft-kang-dymoqos-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware have 14 been or will be disclosed, and any of which he or she becomes aware 15 will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 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 This Internet-Draft will expire on April 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes extensions to the Dynamic MANET On-demand 42 (DYMO) routing protocol in order to enable mobile nodes to discover 43 and maintain QoS routes. DYMO is a reactive (on-demand) routing 44 protocol designed for use by mobile nodes in multi-hop wireless ad 45 hoc networks. Extensions of this document include the necessary 46 addition to the routing table and the DYMO message element. 48 1. Introduction 50 The DYMO routing protocol specifies a reactive means to discover a 51 route to the destination for MANET nodes. A source node disseminates 52 RREQ message toward the destination node to discover a route to the 53 node. Once the RREQ message arrives at the destination node, it 54 responds RREP message back to the source node over the discovered 55 path by unicasting. During such a route discovery process, 56 intermediate nodes (i.e. nodes that relay the RREQ and RREP message) 57 update its routing table based on the routing information that is 58 present in those two messages for each direction. DYMO also offers 59 adaptation to changing network topology, which can be occurred by the 60 mobility of nodes as the main cause, by means of the route 61 maintenance mechanisms [1]. 63 In order to provide MANET nodes with QoS routes, extensions to DYMO 64 message elements are required. These extensions specify the service 65 requirements (say maximum tolerable delay, maximum tolerable jitter, 66 and/or minimum bandwidth limitation) that must be guaranteed by nodes 67 along a route from a source to the destination. 69 This document presents which extensions are required for support QoS 70 in routing, how service guarantees are achieved by using the defined 71 extensions without high impacts on the existing DYMO operations and 72 how QoS routes are discovered and maintained are also briefly 73 described. 75 The extensions of this document conform to the DYMO routing protocol 76 (i.e. the the extentions to DYMO data structure specified in [1]). 78 In this document, the extension to routing table is first described 79 and then two message element extensions, QoS Route Element (QRE) and 80 QoS Route Error (QRERR), are presented for supporting QoS routing. 82 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [2]. 86 2. Routing Table Entries for QoS Routing 88 In QoS routing, routing table entries can be defined differently 89 according to the type of QoS model; per-flow based model such as 90 IntServ model [3] or per-class based model such as DiffServ model 91 [4]. 93 In case of the per-flow based mechanism, the following entries may be 94 added to the routing table of each DYMO router on the path. A 95 routing table entry is defined for a flow to specify QoS requirements 96 requested by the source (requestor) of the particular flow, where a 97 flow can be identified by the pair of IP address and port number. 99 - Maximum Tolerable Delay 101 - Maximum Tolerable Jitter 103 - Minimum Available Bandwidth 105 - List of Sources Identifier Requesting Delay Guarantees 107 - List of Sources Identifier Requesting Jitter Guarantees 109 - List of Sources Identifier Requesting Bandwidth Guarantees, 111 where the Source Identifier consists of IPSourceAddress and Port 112 number. 114 In case of the class-based model , on the other hand, the following 115 fields may be added to the routing table of a DYMO router. Each 116 routing table entry is defined for each pre-specified class, where a 117 packet belonging to each class can be distinguished by DSCP (DiffServ 118 Code Point) as specified in [5]. 120 - Maximum Tolerable Delay 122 - Maximum Tolerable Jitter 124 - Minimum Available Bandwidth 126 - List of Classes 128 - List of Sources Identifier Belonging to Each Class 130 3. Extensions to DYMO Message Elements 132 In this section, we present two extensions to DYMO message element 133 for support QoS route. The work especially considers the compact 134 representation for use by mobile nodes in using of limited capacity, 135 the future extensions for covering various QoS parameters and the 136 support of the per-flow based mechanism and the per-class based 137 mechanism as well. 139 3.1 QoS Routing Element (QRE) 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Type | Len | TTL |I|A| Res | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 : NotifyAddress (QoS Requestor) : 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 : TargetAddress : 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | TargetSeqNum | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 : : 153 : QoS Information Block (QIB) : 154 : : 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 : : 157 : QoS State Information Block (QSIB) : 158 : : 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | THopCnt |Res| : 161 +-+-+-+-+-+-+-+-+ : 162 : : 163 : Routing Blocks (RBlocks) : 164 : : 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1. QoS Routing Element (QRE) 169 QoS Routing Element (QRE) is an extension to the DYMO Routing Element 170 (RE) in order to enable a source to discover a path that is able to 171 guarantee the QoS requirements. The QoS requirements of the source 172 are specified in the QIB (QoS Information Block) field. 174 Element Type (Type) 175 The Type field identifies that this element is QRE and the han- 176 dling by nodes that do not implement or understand QoS exten- 177 sions. The data structure of the Type is as follows. 179 0 0 180 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 181 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 182 | Type | = |M| H | | 183 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 185 Figure 2. Type 187 In QRE, M bit MUST be set to one (1) in order to indicate that 188 QRE requires notification via an UERR when QRE is not under- 189 stood or handled by a node on the path. Therefore QRE MUST 190 convey NotifyAddress field to which UERR is sent. As well as 191 the H bits in the Type field MUST set to (11) in order to force 192 a node which does not support QRE to drop the QRE packet with- 193 out processing any other QoS DYMO elements. 195 NotifyAddress (QoS Requestor) 196 IP address of the source that have originally generated this 197 QRE to request a particular service. 199 Most of fields conform to the DYMO message element specified in [2] 200 except the newly defined two information block fields (i.e. QoS 201 Information Block (QIB) and QoS State Information Block (QSIB)). 202 Those two blocks are defined as follows. 204 QoS Information Block (QIB) 205 This field can be used differently according to the type of 206 element message (i.e. in a route request and a route reply ele- 207 ment with QoS extensions). In QRREQ message, on one hand, the 208 QIB field indicates the service requirements that must be met 209 at nodes along a route to the destination. On the other hand, 210 in QRREP message, the destination uses this field to inform the 211 route's resources available for the QoS requestor. The route's 212 resources are gathered or updated by intermediate nodes and 213 contained within the QSIB field during the route discovery 214 process. The data structure of QIB field is described in Fig- 215 ure 3. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 |QPCnt| QoS PM |Res|Traffic Cls| QoS Param Value 1 | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |QoS Param Value N(if presented)| Padding Bits (if needed) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 3. QoS Information Block (QIB) 227 QoS Parameter Count (QPCnt) 228 The most significant 3 bits, QPCnt bits, indicate the number of 229 QoS parameters being presented within the QIB field. 231 QoS Parameter Mark (QoS PM) 232 The 5 bits marker of QoS PM field specifies which parameter is 233 present in QIB to specify the service requirements. This field 234 consists of the following bit marker. 236 0 0 237 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 238 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 239 | QoS PM | = |B|D|J| Res | 240 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 242 Figure 4. QoS Parameter Marker (QoS PM) 244 B-bit (B) 245 1-bit marker to indicate whether the minimum bandwidth is spec- 246 ified as one of the service requirements within QIB. 248 D-bit (D) 249 1-bit marker to indicate whether the maximum delay (end to end 250 delay) is specified as one of the service requirements within 251 QIB. 253 J-bit (J) 254 1-bit marker to indicate whether the maximum jitter (end to end 255 jitter) is specified as one of the service requirements within 256 QIB. 258 Reserved (Res) 259 Reserved 2 bits for the future extensions (i.e. for other QoS 260 parameters such as power of a node). Typically, these bits are 261 set to zero (0) and ignored in any processing. In addition to 262 these 2 bits, there exist two more bits at the next field 263 (between QoS PM and Traffic Class fields). These Res bits also 264 can be used for the future extensions. (At the time of writing 265 this document, these two Res fields are conceptually distin- 266 guished in order to support easy to implement, i.e. byte based 267 variable allocation in conventional programming language such 268 as C.) 270 Traffic Class (Traffic Cls) 271 The Traffic Cls field allows mobile nodes to employ the per- 272 class based mechanism (say DiffServ). This field is specified 273 by using 6-bits code, called DSCP (Differentiated Services Code 274 Points) that indicate a particular class. 276 QoS parameter value (QoS Param Value) 277 The number and the type of QoS parameters depend on the first 278 16 bytes of QIB as above addressed. If B and D bit are set to 279 one (1), for example, there MUST exist two parameter value 280 fields so that the padding field does not needed. QoS Param 281 Value fields are defined as follows. 283 - Minimum Bandwidth Requirement 284 16-bit number, measured in kbits/second (kbps). The maximum 285 value is about 131 Mbps (2^17 - 1 kbps). If the required band- 286 width is less than 1kbps, the value is set to one (1) That is, 287 the least bandwidth requirement the source requires is 1 Kbps. 289 - Maximum End to End Delay Requirement 290 16-bit number, measured in milliseconds (ms) 292 - Maximum End to End Jitter Requirement 293 16-bit number, measured in milliseconds (ms) 295 Padding Bits 296 The Padding field of QIB is used to confirm to DYMO message 297 element. If QoS PCnt is even number then these bits are set to 298 zero (0). 300 QoS State Information Block (QSIB) 301 In QoS routing, intermediate nodes along a path to the destina- 302 tion should inform the destination about its current state of 303 resources in order that the destination is able to decide the 304 optimal route among route candidates. The number and the kinds 305 of QoS State Value depend on the QIB field. As an example, if 306 a source specifies a delay parameter as a QoS requirement (i.e. 307 D bit in QoS PM field is set), there MUST exist a QoS state 308 value in SIB for presenting a delay value on candidate paths. 309 In this case, all intermediate nodes MUST accumulate its mea- 310 sured delay. The data structure of the QSIB is illustrated in 311 figure 5. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | QoS State Value 1 |QoS State Value N(if presented)| 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |QoS State Value N(if presented)| Padding Bits (if needed) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 5. QoS State Information Block (QoS SIB) 323 3.2 QoS Route Error (QRERR) 325 QoS Route Error (QRERR) is an extension to the DYMO RERR message ele- 326 ment. QRERR message element is generated when an intermediate node 327 realizes a lack of ability to maintain the QoS guarantees for a spe- 328 cific route. The data structure of this element is as follows. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Len | TTL |I|Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 : QUNodeAddress1 : 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | QUNodeSeqNum1 | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | UQParam1 | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 : Additional QUNodeAddressN (if needed) : 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Additional QUNodeSeqNumN (if needed) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 6. QoS Route Error (QRERR) 348 QoS Unsupported Node Address (QUNodeAddress) 349 The IP address of the node that cannot guarantee QoS any more. 351 QoS Unsupported Node Sequence Number (QUNodeSeqNum) 352 The sequence number of the node that cannot guarantee QoS, if 353 known; otherwise this field set to zero (0). 355 Unsupported QoS Parameter (UQParam) 356 The main difference between RERR and QRERR is the UQParam 357 (Unsupported QoS Parameter) field which is used to inform the 358 QoS requestor about which QoS parameter is no longer available 359 for the originally specified QoS requirements. Once the QoS 360 requestor receives the QRERR, it re-builds a QoS route process 361 based on the unavailable QoS parameters if it still has packets 362 to deliver. This field is illustrated in figure 7. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |QPCnt| QoS PM |Res|Traffic Cls| QoS Param Value 1 | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |QoS Param Value N(if presented)| Padding Bits (if needed) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 7. UQParam field 373 All fields are equivalent to the fields of QIB in the QRE message 374 element but differently used. QoS PCnt indicates the number of scarce 375 resource and each of their kinds are marked in QoS PM filed to iden- 376 tify the next fields (i.e. which parameter(s) is (are) present in 377 UQParam field). 379 QoS Parameter Value 380 The QoS Parameter Value field reports the measured QoS parame- 381 ter(s) that fails to meet the originally requested QoS. If a 382 particular node is aware of higher delay than the maximum per- 383 missible delay, the measured delay is reported to the QoS 384 requestor. 386 The QRERR message MUST be delivered to all QoS requestor potentially 387 affected by the change in the QoS parameter. 389 4. QoS DYMO Operations 391 4.1 QoS Route Discovery 393 Like DYMO routing procedures, a QoS route is also discovered by means 394 of two way handshaking consisting of a route request and route reply 395 cycle. Instead of DYMO RREQ, the source (QoS requestor) disseminates 396 QRREQ (RREQ with a QoS extension) to the destination. QRREQ message 397 elements therefore should contain required QoS parameters as well as 398 the QoS reporting information on the path that the message has been 399 experienced. Thereafter, the destination node decides a correct 400 route that can meet the QoS requirements and then sends QRREP (RREP 401 with a QoS extension) to the source. 403 Ahead of re-broadcasting a QRREQ message by an intermediate node, the 404 node must check its resources whether it is available for the QoS 405 requirements contained within the QRREQ message during the route dis- 406 covery process. Thereafter, if resources are enough to meet service 407 requirements, the intermediate node updates QoS information that is 408 present in the QRREQ message to inform the destination about the cur- 409 rent QoS states related to the path. 411 That is, QRREQ should contain two different fields. One is used to 412 specify the QoS requirements of the source (i.e. QoS requestor) that 413 must be met at nodes through the path. The other field is used to 414 inform both the QoS requestor and the destination that selects a 415 proper QoS route the current network conditions such as delay, jit- 416 ter, and/or bandwidth. 418 In case of delay and jitter, intermediate nodes accumulate each of 419 their measured delay and jitter value to the corresponding value of 420 the received QRREQ message. For this reason, the destination can be 421 aware of the end to end delay and jitter along the path. 423 In case of bandwidth (i.e. capacity to transmit), the node compares 424 its measured value with the value of QSIB field in the received QRREQ 425 message. If the measured value is smaller than the value of the mes- 426 sage, the field is updated to the measured one. This field allows 427 the destination to be aware of the actual minimum bandwidth over a 428 route from the source to the destination since the value of QSIB is 429 always bigger than the minimum value that the QoS requestor requires. 430 If it is not the case, a node MUST drop the QRREQ message since there 431 is not enough bandwidth to guarantee the required one. Such a way 432 allows the QoS requestor to be able to increase the minimum bandwidth 433 requirement according to the network condition dynamically. 435 In QoS enabled DYMO, M-bit MUST be set to one (1) and H-bits MUST be 436 set to (11). Therefore, if the QoS extended element is not supported 437 or handled by the processing node, the node MUST send a UERR to the 438 NotifyAddress (QoS requestor) and drop the message to prevent that 439 unsupported message is not propagated further. 441 In DYMO, I bit of RE message indicates whether the element has been 442 ignored by some intermediate nodes. Therefore, in QoS DYMO, if the I 443 bit is (1), the QRE message MUST be dropped. 445 4.2 QoS Route Maintenance 447 In order to react to changes in the network resources, nodes monitor 448 their links under the aspect of QoS. When a node is aware of the 449 fact that resources of its link is no longer available for the QoS 450 requestor, a QoS-Route Error (QRERR) is sent to the QoS requestor to 451 inform the current unavailable QoS parameters of the route. Once the 452 requestor receives the QRERR, it re-builds a QoS route process based 453 on the unavailable QoS parameters if it still has packets to deliver. 455 5. Security Considerations 457 This document does not discuss any special security concerns in 458 detail. The protocol of this document is built on the assumption 459 that all participating nodes are trusted each other as well as there 460 is no adversary who modifies/injects false route elements to corrupt 461 the QoS routes. 463 However, support of secure routing protocol is prerequisite for 464 launching a secure communication in the presence of adversaries. In 465 such an environment, most of all MANET routing protocols including 466 DYMO are vulnerable to many kinds of attacks. It is fairly easy to 467 inject fake routing messages or modify legitimate ones so that net- 468 work operation would be heavily disturbed (e.g., by creating loops or 469 disconnecting the network). Therefore, it is necessary to find a 470 means to authenticate/verify control messages to discover and main- 471 tain a proper route. Especially, QRE message MUST be authenticated 472 to enable nodes participating in QoS DYMO routing protocol to assure 473 the origin of the QRE message. 475 References 477 [1] I. Chakeres, E. M. Belding-Royer and C. E. Perkins. Dynamic MANET 478 On-demand (DYMO) Routing. IETF Internet Draft draft-ietf-manet- 479 dymo-02 June 2005. Work in Progress. 481 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 482 Levels. Internet RFC 2119, March 1997. 484 [3] R. Braden, D. Clark, and S. Shenker, Integrated Services in the 485 Internet Architecture: an Overview, Internet RFC 1633, June 1994. 487 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, 488 An Architecture for Differentiated Services Internet RFC 2475, Decem- 489 ber 1998. 491 [5] Nichols, K., Blake, S., Baker, F. and D. Black. Definition of the 492 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Head- 493 ers, Internet RFC 2474, December 1998. 495 Author's Addresses 497 Questions about this memo can be directed to: 499 Namhi Kang 500 Ubiquitous Network Research Center 501 DASAN Networks Inc. 502 3F FineVenture Bldg. 345-1, YaTap-Dong, 503 BunDang-Gu, SeongNam-Si, KyongGi-Do, 463-070 504 Korea 505 +82 2 814 0151 506 nalnal@dcn.ssu.ac.kr 508 Younghan Kim 509 University of Soongsil in Seoul 510 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 511 Dongjak-Gu, Seoul 156-743 512 Korea 513 +82 2 820 0904 514 yhkim@dcn.ssu.ac.kr 516 Intellectual Property Statement 518 The IETF takes no position regarding the validity or scope of any 519 Intellectual Property Rights or other rights that might be claimed to 520 pertain to the implementation or use of the technology described in 521 this document or the extent to which any license under such rights 522 might or might not be available; nor does it represent that it has 523 made any independent effort to identify any such rights. Information 524 on the procedures with respect to rights in RFC documents can be 525 found in BCP 78 and BCP 79. 527 Copies of IPR disclosures made to the IETF Secretariat and any 528 assurances of licenses to be made available, or the result of an 529 attempt made to obtain a general license or permission for the 530 use of such proprietary rights by implementers or users of this 531 specification can be obtained from the IETF on-line IPR repository at 532 http://www.ietf.org/ipr. 534 The IETF invites any interested party to bring to its attention any 535 copyrights, patents or patent applications, or other proprietary 536 rights that may cover technology that may be required to implement 537 this standard. Please address the information to the IETF at 538 ietf-ipr@ietf.org. 540 Disclaimer of Validity 542 This document and the information contained herein are provided on 543 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 544 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 545 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 546 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 547 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 548 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 550 Copyright Statement 552 Copyright (C) The Internet Society (2005). This document is subject 553 to the rights, licenses and restrictions contained in BCP 78, and 554 except as set forth therein, the authors retain all their rights.