idnits 2.17.1 draft-kang-dymoqos-02.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 3979, Section 5, paragraph 1 on line 49. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 62. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 5 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '5') Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad Hoc Networking Working Group Namhi Kang 3 INTERNET DRAFT Younghan Kim 4 25 June 2006 University of Soongsil, Korea 6 Quality of Service Extension to 7 Dynamic MANET OnDemand Routing Protocol 8 draft-kang-dymoqos-02.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 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Distribution of this memo is unlimited. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 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 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 24, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Intellectual Property Statement 42 The IETF takes no position regarding the validity or scope of any 43 Intellectual Property Rights or other rights that might be claimed to 44 pertain to the implementation or use of the technology described in 45 this document or the extent to which any license under such rights 46 might or might not be available; nor does it represent that it has 47 made any independent effort to identify any such rights. Information 48 on the procedures with respect to rights in RFC documents can be 49 found in BCP 78 and BCP 79. 51 Copies of IPR disclosures made to the IETF Secretariat and any assur- 52 ances of licenses to be made available, or the result of an attempt 53 made to obtain a general license or permission for the use of such 54 proprietary rights by implementers or users of this specification can 55 be obtained from the IETF on-line IPR repository at 56 http://www.ietf.org/ipr. 58 The IETF invites any interested party to bring to its attention any 59 copyrights, patents or patent applications, or other proprietary 60 rights that may cover technology that may be required to implement 61 this standard. Please address the information to the IETF at ietf- 62 ipr@ietf.org. 64 Abstract 66 This document describes extensions to the Dynamic MANET On-demand 67 (DYMO) routing protocol in order to enable mobile nodes to discover 68 and maintain QoS routes. DYMO is a reactive (on-demand) routing 69 protocol designed for use by mobile nodes in multi-hop wireless ad 70 hoc networks. Extensions of this document include the necessary 71 additions to the routing table and DYMO routing messages. 73 Table of Contents 75 Intellectual Property Statement 2 76 1. Introduction 4 77 2. Routing Table Entries for Qos Routing 5 78 3. Extensions to DYMO Routing Message (RM) 6 79 3.1. QoS Routing Message (QRM) 6 80 3.2. QoS Route Error (QRERR) 11 81 4. QoS DYMO Operations 14 82 4.1. QoS Route Discovery 14 83 4.2. QoS Route Maintenance 15 84 5. Security Considerations 16 85 References 17 86 Author's Address 18 87 Disclaimer of Validity 18 88 Copyright Statement 18 90 1. Introduction 92 The DYMO routing protocol specifies a reactive means to discover a 93 route to the destination for MANET nodes. A source node disseminates 94 RREQ message toward the destination node to discover a route to the 95 node. Once the RREQ message arrives at the destination node, it 96 responds RREP message back to the source node over the discovered 97 path by unicasting. During such a route discovery process, 98 intermediate nodes (i.e. nodes that relay the RREQ and RREP message) 99 update its routing table based on the routing information that is 100 present in those two messages for each direction. DYMO also offers 101 adaptation to changes in network topology, which can be occurred by 102 the mobility of nodes as the main cause, by means of the route 103 maintenance mechanisms [1]. 105 In order to provide MANET nodes with QoS routes, extensions to DYMO 106 routing messages are required. These extensions specify the service 107 requirements (say maximum tolerable delay, maximum tolerable jitter, 108 and/or minimum bandwidth limitation) that must be guaranteed by nodes 109 along a route from a source to the destination. 111 This document presents which extensions are required for support QoS 112 in routing, how service guarantees are achieved by using the defined 113 extensions without high impacts on the existing DYMO operations and 114 how QoS routes are discovered and maintained are also briefly 115 described. 117 The extensions of this document conform to the DYMO routing protocol 118 [1] (i.e. the generalized signaling framework specified in [2]). 120 In this document, the extension to routing table is first described 121 and then two routing message extensions, QoS Route Message (QRM) and 122 QoS Route Error (QRERR), are presented for supporting QoS routing. 124 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [3]. 128 2. Routing Table Entries for QoS Routing 130 In QoS routing, routing table entries can be defined differently 131 according to the type of QoS model; per-flow based model (say IntServ 132 model [4]) or per-class based model (say DiffServ model [5]). 134 In case of the per-flow based mechanism, the following entries may be 135 added to the routing table of each DYMO router on the path. A 136 routing table entry is defined for each flow to specify QoS 137 requirements requested by the source (requestor) of the particular 138 flow, where a flow can be identified by the pair of IP address and 139 port number. 141 - Maximum Tolerable Delay 143 - Maximum Tolerable Jitter 145 - Minimum Available Bandwidth 147 - List of Sources Identifier Requesting Delay Guarantees 149 - List of Sources Identifier Requesting Jitter Guarantees 151 - List of Sources Identifier Requesting Bandwidth Guarantees, 152 where the Source Identifier consists of IPSourceAddress and Port 153 number. 155 In case of the class-based model, on the other hand, the following 156 fields may be added to the routing table of a DYMO router. Each 157 routing table entry is defined for each pre-specified class, where a 158 packet belonging to each class can be distinguished by DSCP (DiffServ 159 Code Point) as specified in [6]. 161 - Maximum Tolerable Delay 163 - Maximum Tolerable Jitter 165 - Minimum Available Bandwidth 167 - List of Classes 169 - List of Sources Identifier Belonging to Each Class 171 3. Extensions to DYMO Routing Message (RM) 173 In this section, we present two extensions to DYMO routing message to 174 discover a QoS route. The work especially considers the compact 175 representation for use by mobile nodes in using of limited capacity, 176 the future extensions for covering various QoS parameters and the 177 support of the per-flow based mechanism and the per-class based 178 mechanism as well. 180 3.1 QoS Routing Message (QRM) 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | QoSMsg-type | RSRV |U|N|0|1| msg-size | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | msg-ttl | msg-hopcnt | msg-tlv-block-size=0 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Head Length | Head |Number Tails=2 | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | TailQoSReq | TailTarget | SEQ-tlv-Len | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |DYMOSEQNUM-type| TLV Length | Orig.SeqNum.: 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 :.Orig.SeqNum | Target.SeqNum |QoSpar-tlv-Len.: 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 :.QoSpar-tlv-Len| QoSParam-type | Resv |M|1|0|0| TLV Len | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | QoS PI | QoSParam1 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | QoSParam2 (if presented) | QoSParamN (if presented) | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | QoSstate-tlv-Len | QoSstate-type | Resv |M|1|0|0| 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | TLV Len | QoS State Value1 |QoS State Val2.: 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 :(if presented) | QoS State ValueN(if presented)| 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 1. Exemplified QoS Routing Message (QRM) 212 QoS Routing Message (QRM) is an extension to the DYMO Routing Message 213 (RM) in order to enable a source to discover a path that is able to 214 guarantee the QoS requirements. The QoS requirements of the source 215 are specified by means of the QoSpar (QoS parameter) tlv. 217 - QRM conforms to the generalized message format. 219 - msg-type = DYMO-QRREQ or DYMO-QRREP 220 The Type field identifies that this element is QRE (i.e. either 221 DYMO-QRREQ or DYMO-QRREP). The field also specifies how the 222 QRE is handled in case where nodes do not implement or under- 223 stand such QoS extensions. The data structure of the Type is as 224 follows. 226 0 0 227 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 228 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 229 | QoSMsg-type | = |M| H | | 230 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 232 Figure 2. QoSMsg Type 234 In QRE, M bit MUST be set to one (1) in order to indicate that QRE 235 requires notification via an UERR when QRE is not understood or 236 handled by a node on the path. Therefore QRE MUST convey Noti- 237 fyAddress field to which UERR is sent. As well as the H bits in 238 the Type field MUST set to (11) in order to force a node which 239 does not support QRE to drop the QRE packet without processing any 240 other QoS DYMO elements. 242 - msg-semantics 243 QRM conforms to the msg-semantics specified in DYMO. 245 - msg-header-info 246 QRM conforms to the msg-header-info specified in DYMO. 248 - add-block entries 249 QRM conforms to the add-block entries specified in DYMO. 251 - add-tlv 252 Most of fields conform to the DYMO routing message specified in 253 [1] except the newly defined QoSpar tlv and QoSstate (QoS State 254 Information) tlv. 256 - QoSpar-tlv 257 This TLV field can be used differently according to the type of 258 QRM (i.e. whether a route request or a route reply element with 259 QoS extensions). In QRREQ message, on one hand, the QoSpar-tlv 260 indicates the service requirements that must be met at nodes along 261 a route to the destination. On the other hand, in QRREP message, 262 the destination uses this field to inform the route's resources 263 available for the QoS requestor. The route's resources are gath- 264 ered or updated by intermediate nodes and contained within the 265 QoSstate-tlv field during the route discovery process. The data 266 structure of QoS Parameter Indicator (QoS PI) is described in Fig- 267 ure 3. 269 0 1 270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |U|QPCnt|QoS PM |Res|Traffic Cls| 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 3. QoS PI 277 U-bit (U) 279 1-bit selector to indicate whether the route discovery process to 280 be continued. If S bit is available at DYMO routers, this bit is 281 coupled with the S bit. If S-bit is set to one (1) in the QRE, 282 then a reporting message SHOULD be sent to the previous hop within 283 UNICAST_MESSAGE_SENT_TIMEOUT. At this time the two nodes (i.e. 284 previous hop and QRE receiver) can detect whether the link between 285 two nodes is bidirectional or unidirectional. If U-bit is also 286 set to one (1) and the link is unidirectional, then the QRE 287 receiver is forced to stop the route discovery process. 289 QoS Parameter Count (QPCnt) 291 The most significant 3 bits, QPCnt bits, indicate the number of 292 QoS parameters being presented within the value field of QoSpar- 293 tlv. 295 QoS Parameter Mark (QoS PM) 297 The 4 bits marker of QoS PM field specifies which parameter is 298 present in QoSpar-tlv to specify the service requirements. This 299 field consists of the following bit marker. 301 0 0 302 4 5 6 7 8 4 5 6 7 8 303 +-+-+-+-+ +-+-+-+-+ 304 |QoS PM | = |B|D|J|R| 305 +-+-+-+-+ +-+-+-+-+ 307 Figure 4. QoS Parameter Marker (QoS PM) 309 B-bit (B) 311 1-bit marker to indicate whether the minimum bandwidth is speci- 312 fied as one of the service requirements within QoSpar-tlv. 314 D-bit (D) 316 1-bit marker to indicate whether the maximum delay (end to end 317 delay) is specified as one of the service requirements within 318 QoSpar-tlv. 320 J-bit (J) 322 1-bit marker to indicate whether the maximum jitter (end to end 323 jitter) is specified as one of the service requirements within 324 QoSpar-tlv. 326 R-bit (R) 328 Reserved 1 bit for the future extensions (i.e. for other QoS 329 parameters such as power of a node). Typically, this bit is set 330 to zero (0) and ignored in any processing. 332 Reserved (Res) 333 Reserved 2 bits for the future extensions. Typically, these bits 334 are set to zero (0) and ignored in any processing. In addition to 335 these 2 bits, there exists one more reserved bit described above 336 (in QoS PM field). These three reserved bits are conceptually 337 distinguished in order to support easy to implement, i.e. byte- 338 oriented allocation of variable in conventional programming lan- 339 guage such as C. 341 Traffic Class (Traffic Cls) 343 The Traffic Cls field allows mobile nodes to employ the per-class 344 based mechanism (say DiffServ). This field is specified by using 345 6-bits code, called DSCP (Differentiated Services Code Points) 346 that indicate a particular class [5]. 348 QoS parameter value (QoS Param) 350 The number and the type of QoS parameters depend on the QoS PI 351 (Parameter Indicator) value. If B and D bit are set to one (1), 352 for example, there MUST exist two parameter value fields so that 353 the padding field does not needed. QoS Param Value fields are 354 defined as follows. 356 - Minimum Bandwidth Requirement 357 16-bit number, measured in kbits/second (kbps). The maximum 358 value is about 131 Mbps (2^17 - 1 kbps). If the required band- 359 width is less than 1kbps, the value is set to one (1). That 360 is, the least bandwidth requirement the source requires is 1 361 Kbps. 363 - Maximum End to End Delay Requirement 364 16-bit number, measured in milliseconds (ms) 366 - Maximum End to End Jitter Requirement 367 16-bit number, measured in milliseconds (ms) 369 - QoSstate-tlv 371 QRM conveys QoS State information for each address within 372 QoSstate-tlv. In QoS routing, intermediate nodes along a path to 373 the destination should inform the destination about its current 374 state of resources in order that the destination is able to decide 375 the optimal route among route candidates. 377 The number and the type of QoS State Values depend on the QoSpar- 378 tlv. For example, if a source specifies a delay parameter as a 379 QoS requirement (i.e. D bit in QoS PM field is set to one (1)), 380 there MUST exist a QoS state value for presenting a delay value on 381 candidate paths. In this case, all intermediate nodes MUST accu- 382 mulate its measured delay. 384 3.2 QoS Route Error (QRERR) 386 QoS Route Error (QRERR) is an extension to the DYMO RERR message. 387 QRERR message element is generated when an intermediate node realizes 388 a lack of capability to maintain the QoS guarantees for a specific 389 route. The data structure of this element is as follows. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |qrerr-msg-type | RSRV |U|N|0|1| msg-size | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | msg-ttl | msg-hopcnt | msg-tlv-block-size=0 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Head Length | Head |Number Tails=1 | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Tail1 | tlv-block-size |dymo-seqnum-typ| 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | TLV Length | Tail1.SeqNum | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | QUN-tlv-Len | QUN-type | Resv |M|1|0|0| 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | TLV Len | UQParam1 | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | UQParamN (if presented) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 5. QoS Route Error (QRERR) 413 - QRERR conforms to the generalized message format. 415 - msg-type = DYMO-QRERR 417 - msg-semantics 418 QRERR conforms to the msg-semantics of RERR specified in DYMO. 420 - msg-header-info 421 QRERR conforms to the msg-header-info of RERR specified in DYMO. 423 - add-block entries 424 QRERR contains 1 or more addresses as QoS Unsupported Node 425 Addresses that is the IP address of the node that cannot guarantee 426 QoS any more. 428 - add-tlv 429 QRERR contains the sequence number of the node that cannot guaran- 430 tee QoS, if known; otherwise this field set to zero (0) in a DYMO 431 Sequence Number tlv. 433 - QUN-tlv 434 QUN-tlv specify unsupported QoS parameters. 436 Unsupported QoS Parameter (UQParam) 437 The main difference between RERR and QRERR is the UQParam (Unsup- 438 ported QoS Parameter) field which is used to inform the QoS 439 requestor about which QoS parameter is no longer available for the 440 originally specified QoS requirements. Once the QoS requestor 441 receives the QRERR, it re-builds a QoS route process based on the 442 unavailable QoS parameters if it still has packets to deliver. 443 This field is illustrated in figure 6. 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |QPCnt| QoS PM |Res|Traffic Cls| QoS Param Value 1 | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |QoS Param Value N(if presented)| Padding Bits (if needed) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 6. UQParam field 455 All fields are equivalent to the fields of QoSpar-tlv in the QRM mes- 456 sage element but differently used. QoS PCnt indicates the number of 457 scarce resource and each of their kinds are marked in QoS PM filed to 458 identify the next fields (i.e. which parameter(s) is (are) present in 459 UQParam field). 461 QoS Parameter Value 463 The QoS Parameter Value field(s) reports the measured QoS parame- 464 ter(s) that fails to meet the originally requested QoS. If a par- 465 ticular node is aware of higher delay than the maximum permissible 466 delay, the measured delay is reported to the QoS requestor. 468 The QRERR message MUST be delivered to all QoS requestors potentially 469 affected by the change in the QoS parameter. 471 4. QoS DYMO Operations 473 4.1 QoS Route Discovery 475 Like DYMO routing procedures, a QoS route is also discovered by means 476 of two way handshaking consisting of a route request and route reply 477 cycle. Instead of DYMO RREQ, the source (QoS requestor) disseminates 478 QRREQ (RREQ with a QoS extension) to the destination. QRREQ message 479 elements therefore should contain required QoS parameters as well as 480 the QoS reporting information on the path that the message has been 481 experienced. Thereafter, the destination node decides a correct 482 route that can meet the QoS requirements and then sends QRREP (RREP 483 with a QoS extension) to the source. 485 Ahead of re-broadcasting a QRREQ message by an intermediate node, the 486 node must check its resources whether it is available for the QoS 487 requirements contained within the QRREQ message during the route dis- 488 covery process. Thereafter, if resources are enough to meet service 489 requirements, the intermediate node updates QoS information that is 490 present in the QRREQ message to inform the destination about the cur- 491 rent QoS states related to the path. 493 That is, QRREQ should contain two different fields. One is used to 494 specify the QoS requirements of the source (i.e. QoS requestor) that 495 must be met at nodes through the path. The other field is used to 496 inform both the QoS requestor and the destination that selects a 497 proper QoS route the current network conditions such as delay, jit- 498 ter, and/or bandwidth. 500 In case of delay and jitter, intermediate nodes accumulate each of 501 their measured delay and jitter value to the corresponding value of 502 the received QRREQ message. For this reason, the destination can be 503 aware of the end to end delay and jitter along the path. 505 In case of bandwidth (i.e. capacity to transmit), the node compares 506 its measured value with the value of QoSstate in the received QRREQ 507 message. If the measured value is smaller than the value of the mes- 508 sage, the field is updated to the measured one. This field allows 509 the destination to be aware of the actual minimum bandwidth over a 510 route from the source to the destination since the value of QoSstate 511 is always bigger than the minimum value that the QoS requestor requi- 512 res. If it is not the case, a node MUST drop the QRREQ message since 513 there is not enough bandwidth to guarantee the required one. Such a 514 way allows the QoS requestor to be able to increase the minimum band- 515 width requirement according to the network condition dynamically. 517 In QoS enabled DYMO, M-bit MUST be set to one (1) and H-bits MUST be 518 set to (11). Therefore, if the QoS extended element is not supported 519 or handled by the processing node, the node MUST send a UERR to the 520 NotifyAddress (QoS requestor) and drop the message to prevent that 521 unsupported message is not propagated further. 523 In DYMO, I bit of RE message indicates whether the element has been 524 ignored by some intermediate nodes. Therefore, in QoS DYMO, if the I 525 bit is (1), the QRM message MUST be dropped. 527 The recent revision of DYMO specifies S-bit to allow the previous hop 528 to ensure that the link traversed in not unidirectional. It may be 529 useful to detect a unidirectional link(s) along a path in the process 530 of QoS route discovery. The existence of a unidirectional link may 531 not be a problem in some QoS applications such as stock quote stream- 532 ing. However, others require fully directional link on the path from 533 a source to the destination(s). Examples include multimedia confer- 534 encing, IP telephony and most of RTP based QoS applications. There- 535 fore, it is necessary to inform how each of cases is handled at nodes 536 along path. 538 When a node ensures the link is unidirectional then the node performs 539 the route discovery process based on the U-bit coupled with S-bit. 540 If U-bit and S-bit in QRM are both set to one (1), then the QRM 541 receiver is forced to stop the route discovery process. 543 4.2 QoS Route Maintenance 545 In order to react to changes in the network resources, nodes monitor 546 their links under the aspect of QoS. When a node is aware of the 547 fact that resources of its link is no longer available for the QoS 548 requestor, a QoS-Route Error (QRERR) is sent to the QoS requestor to 549 inform the current unavailable QoS parameters of the route. Once the 550 requestor receives the QRERR, it re-builds a QoS route process based 551 on the unavailable QoS parameters if it still has packets to deliver. 553 5. Security Considerations 555 This document does not discuss any special security concerns in 556 detail. The protocol of this document is built on the assumption 557 that all participating nodes are trusted each other as well as there 558 is no adversary who modifies/injects false route elements to corrupt 559 the QoS routes. 561 However, support of secure routing protocol is prerequisite for 562 launching a secure communication in the presence of adversaries. In 563 such an environment, most of all MANET routing protocols including 564 DYMO are vulnerable to many kinds of attacks. It is fairly easy to 565 inject fake routing messages or modify legitimate ones so that net- 566 work operation would be heavily disturbed (e.g., by creating loops or 567 disconnecting the network). Therefore, it is necessary to find a 568 means to authenticate/verify control messages to discover and main- 569 tain a proper route. Especially, QRM message MUST be authenticated 570 to enable nodes participating in QoS DYMO routing protocol to assure 571 the origin of the QRM message. 573 References 575 [1] I. Chakeres, E. Belding-Royer and C. Perkins, Dynamic MANET On- 576 demand (DYMO) Routing. IETF Internet Draft, June 2005, Work in 577 Progress. 579 [2] Clausen, T., Dearlove, C. and J. Dean, Generalized MANET 580 Packet/Message Format, IETF Internet Draft, June 2005, Work in 581 Progress. 583 [3] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev- 584 els, Internet RFC 2119, March 1997. 586 [4] R. Braden, D. Clark and S. Shenker, Integrated Services in the 587 Internet Architecture: an Overview, Internet RFC 1633, June 1994. 589 [5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, 590 An Architecture for Differentiated Services Internet RFC 2475, 591 December 1998. 593 [6] Nichols, K., Blake, S., Baker, F. and D. Black. Definition of the 594 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Head- 595 ers, Internet RFC 2474, December 1998. 597 Author's Addresses 599 Questions about this memo can be directed to: 601 Namhi Kang 602 UNRC, Soongsil University in Seoul 603 424 Hyungnam Engineering Bldg. 317, Sangdo-Dong, 604 Dongjak-Gu, Seoul 156-743 605 Korea 606 +82 2 820 0841 607 nalnal@dcn.ssu.ac.kr 609 Younghan Kim 610 DCN, Soongsil University in Seoul 611 1104 Hyungnam Engineering Bldg. 317, Sangdo-Dong, 612 Dongjak-Gu, Seoul 156-743 613 Korea 614 +82 2 820 0904 615 yhkim@dcn.ssu.ac.kr 617 Disclaimer of Validity 619 This document and the information contained herein are provided on an 620 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 621 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 622 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 623 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 624 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 625 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 627 Copyright Statement 629 Copyright (C) The Internet Society (2006). This document is subject 630 to the rights, licenses and restrictions contained in BCP 78, and 631 except as set forth therein, the authors retain all their rights.