idnits 2.17.1 draft-kang-dymoqos-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 776. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 752. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 38), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 768. ** Found boilerplate matching RFC 3978, Section 5.5, updated by RFC 4748 (on line 762), which is fine, but *also* found old RFC 3978, Section 5.5 text on line 776. ** 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 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == In addition to RFC 3978, Section 5.5, updated by RFC 4748 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The copyright year in the IETF Trust 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 (~~), 6 warnings (==), 9 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 3 March 2007 Ubiquitous Network Research Center 5 University of Soongsil, Korea 7 Quality of Service Extension to 8 Dynamic MANET OnDemand Routing Protocol 9 draft-kang-dymoqos-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 September 2, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes extensions to the Dynamic MANET On-demand 43 (DYMO) routing protocol in order to enable mobile nodes to discover 44 and maintain QoS routes. DYMO is a reactive (on-demand) routing 45 protocol designed for use by mobile nodes in multi-hop wireless ad 46 hoc networks. Extensions of this document include the necessary 47 entries to the routing table and DYMO routing messages. 49 Table of Contents 51 1. Introduction 3 52 2. Terminology 4 53 3. Routing Table Entries for Qos Routing 6 54 4. Extensions to DYMO Message Elements 8 55 4.1. QoS Routing Element (QRE) 8 56 4.2. QoS Route Error (QERR) 14 57 5. QoS DYMO Operations 18 58 5.1. QoS Route Discovery 18 59 5.2. QoS Route Maintenance 19 60 6. Security Considerations 20 61 References 21 62 Author's Address 22 63 Intellectual Property Statement 22 64 Disclaimer of Validity 23 65 Copyright Statement 23 66 Acknowledgment 23 68 1. Introduction 70 The DYMO routing protocol specifies a reactive means to discover and 71 maintain a route to the destination for MANET nodes. A source node 72 disseminates RREQ message toward the destination node to discover a 73 route to the node. Once the RREQ message arrives at the destination 74 node, it responds RREP message back to the source node over the 75 discovered path by unicasting. During such a route discovery 76 process, intermediate nodes (i.e. nodes that relay the RREQ and RREP 77 message) update its routing table based on the routing information 78 that is present in those two messages for each direction. DYMO also 79 offers adaptation to changes in network topology, which can be 80 occurred by the mobility of nodes as the main cause, by means of the 81 route maintenance mechanisms [1]. 83 In order to provide MANET nodes with QoS routes, extensions to DYMO 84 routing messages are required. These extensions specify the service 85 requirements (say maximum tolerable delay, maximum tolerable jitter, 86 and/or minimum bandwidth limitation) that must be guaranteed by nodes 87 along a route from a source to the destination. 89 This document presents which extensions are required for support QoS 90 in routing, how service guarantees are achieved by using the defined 91 extensions without high impacts on the existing DYMO operations and 92 how QoS routes are discovered and maintained are also briefly 93 described. 95 The extensions specified in this document conform to the DYMO routing 96 protocol [1] (i.e. the generalized signaling framework specified in 97 [2]). 99 In this document, the extension to routing table is first described 100 and then two routing message extensions, QoS Route Message (QRM) and 101 QoS Route Error (QRERR), are presented for supporting QoS routing. 103 2. Terminology 105 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [3]. 109 The basic terminology defined in [1] is used in this document. In 110 addition, the following terminology is used. 112 Source Identifier (SRC ID) 113 SRC ID consists of IPSourceAddress and Port number. 115 QoS Routing Message (QRM) 116 QRM is an extension to the DYMO Routing Message (RM) to support QoS 117 routing. 119 QoS Route Request (QRREQ) 120 A source node, which is intended to discover a QoS enabled route to a 121 corresponding destination, generates and broadcasts a QRREQ. 123 QoS Route Respond (QRREP) 124 The destination generates QRREP to inform the QRREQ generator about a 125 route available for the QoS requirements specified in QRREQ. 127 QoS Route Error (QRERR) 128 QRERR is used to allow a node to figure out that one or more routes 129 to destinations are not available. 131 QoS Parameter (QP) 132 QoS parameter generally includes bandwidth, end to end delay, jitter 133 and loss probability. Additional parameters may also be defined if 134 required, for example channel assignment. Each of the parameters for 135 a route is considered as follows. 137 - Bandwidth of a route is the minimum value from all values of 138 intermediate links from source to destination. 140 - End to end delay is the total summation value of delay 141 introduced by each of intermediate nodes between source and 142 destination pairs. 144 - End to end jitter is the total summation value of jitter 145 experienced at each of intermediate nodes between source and 146 destination pairs. 148 - End to end loss probability is the multiplicative value of loss 149 probability expected at each of intermediate nodes between source 150 and destination pairs. 152 - In a single hop based wireless networking technologies such as 153 IEEE 802.11b, multiple channels have already been used to reduce 154 interference between node and access point. Such a property can 155 also be applied to multi-hop ad-hoc networks, thereby enhancing 156 performance in terms of QoS. 158 3. Routing Table Entries for QoS Routing 160 As described in [1], routing table entry is a conceptual data 161 structure so that implementor can use an internal representation. 162 In addition to the entries specified in [1], conceptual entries 163 indicating and managing QoS requirements are required. 165 In QoS routing, routing table entry can be defined differently 166 according to the type of QoS model; per-flow based model (say 167 IntServ model [4]) or per-class based model (say DiffServ model 168 [5]). 170 In case of the per-flow based mechanism, the following entries MAY 171 be added to the routing table of each DYMO router on the path. A 172 routing table entry SHOULD be defined for each flow to specify QoS 173 requirements requested by the source (requestor) of the particular 174 flow, where a flow can be identified by the pair of IP address and 175 port number (i.e. SRC ID). 177 - Minimum Available Bandwidth 179 - Maximum Tolerable Delay 181 - Maximum Tolerable Jitter 183 - Maximum Tolerable Loss Probability 185 - List of Sources Identifier Requesting Bandwidth Guarantees 187 - List of Sources Identifier Requesting Delay Guarantees 189 - List of Sources Identifier Requesting Jitter Guarantees 191 - List of Sources Identifier Requesting Loss Probability 192 Guarantees 194 In case of the class-based model, on the other hand, the following 195 fields may be added to the routing table of a DYMO router. Each 196 routing table entry SHOULD be defined for each pre-specified class, 197 where a packet belonging to each class can be distinguished by DSCP 198 (DiffServ Code Point) as specified in [6]. 200 - Minimum Available Bandwidth 202 - Maximum Tolerable Delay 204 - Maximum Tolerable Jitter 206 - Maximum Tolerable Loss Probability 208 - List of Classes 210 - List of Sources Identifier belonging to each of the Classes 212 4. Extensions to DYMO Routing Message (RM) 214 In DYMO specification, there are two routing messages: RREQ and RREP. 215 This section therefore presents two extensions to the DYMO RM to 216 discover a QoS route: QRREQ and QRREP. The work especially considers 217 the compact representation for use by mobile nodes in using of 218 limited capacity, the future extensions for covering various QoS 219 parameters and the support of the per-flow based mechanism and the 220 per-class based mechanism as well. 222 4.1 QoS Routing Message (QRM) 224 QoS Routing Message (QRM) is an extension to the DYMO Routing Message 225 (RM) in order to enable a source to discover a path that is able to 226 guarantee the QoS requirements. 228 0 1 2 3 229 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 231 IP Header 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | IP.DestinationAddress=LL_ALL_MANET_ROUTERS | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 UDP Header 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Destination Port=TBD | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 QoS Route Message Header 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | QoSMsg-type | RSRV |N|0|0| Msg-size | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Originator Address | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Hop Limit | Hop Count | Msg Sequence Number | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 QoS Route Message Body - Message TLV Block 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | msg-tlv-block-size=0 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 . . . 257 QoS Route Message Body - Address Block 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |Number Addrs=2 |0|HeadLength=3 | Head : 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 : (cont) | Target.Tail | Orig.Tail | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 QoS Route Message Body - Address TLV Block for Sequence Number 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | tlv-block-size=6 |DYMOSeqNum-type|Resv |0|1|0|0|0| 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Index-start=1 | tlv-length=2 | Orig.SeqNum | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 . . . 273 QoS Route Message Body - Address TLV Block for QoS parameter 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | tlv-block-size=25 | QoSpar-type |Resv |0|0|0|1|0| 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Index-start=1 | Index-start=2 | Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | QoS PI | QoSParam1 | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | QoSParam2 (if presented) | QoSParamN (if presented) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | QoSstate-tlv-Len | QoSstate-type | Resv |M|1|0|0| 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | TLV Len | QoS State Value1 |QoS State Val2.: 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 :(if presented) | QoS State ValueN(if presented)| 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 1. Exemplified QoS Routing Message (QRM) 293 The QoS requirements of the source are specified by means of the 294 QoSpar (QoS parameter) tlv. 296 - QRM conforms to the generalized message format defined in [2]. 298 - msg-type = DYMO-QRREQ or DYMO-QRREP 299 The Type field identifies that this element is QRE (i.e. either 300 DYMO-QRREQ or DYMO-QRREP). The field also specifies how the 301 QRE is handled in case where nodes do not implement or under- 302 stand such QoS extensions. The data structure of the Type is 303 as follows. 305 0 0 306 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 307 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 308 | Type | = |M| H | | 309 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 311 Figure 2. Type 313 In QRE, M bit MUST be set to one (1) in order to indicate that QRE 314 requires notification via an UERR when QRE is not understood or 315 handled by a node on the path. Therefore QRE MUST convey Noti- 316 fyAddress field to which UERR is sent. As well as the H bits in 317 the Type field MUST set to (11) in order to force a node which 318 does not support QRE to drop the QRE packet without processing any 319 other QoS DYMO elements. 321 - msg-semantics 322 QRM conforms to the msg-semantics specified in DYMO. 324 - msg-header-info 325 QRM conforms to the msg-header-info specified in DYMO. 327 - add-block entries 328 QRM conforms to the add-block entries specified in DYMO. 330 - add-tlv 331 Most of fields conform to the DYMO routing message specified in 332 [1] except the newly defined QoSpar tlv and QoSstate (QoS State 333 Information) tlv. 335 - QoSpar tlv 336 This TLV field can be used differently according to the type of 337 QRM (i.e. whether a route request or a route reply element with 338 QoS extensions). In QRREQ message, on one hand, the QoSpar tlv 339 indicates the service requirements that must be met at nodes along 340 a route to the destination. On the other hand, in QRREP message, 341 the destination uses this field to inform the route's resources 342 available for the QoS requestor. The route's resources are gath- 343 ered or updated by intermediate nodes and contained within the 344 QoSstate-tlv field during the route discovery process. The data 345 structure of QoS Parameter Indicator (QoS PI) is described in Fig- 346 ure 3. 348 0 1 349 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |U|QPCnt|QoS PM |Res|Traffic Cls| 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Figure 3. QoS PI 356 U-bit (U) 358 1-bit selector to indicate whether the route discovery process to 359 be continued. If S bit is available at DYMO router, this bit is 360 coupled with the S bit. If S-bit is set to one (1) in the QRE, 361 then a reporting message SHOULD be sent to the previous hop within 362 UNICAST_MESSAGE_SENT_TIMEOUT. At this time the two nodes (i.e. 363 previous hop and QRE receiver) can detect whether the link between 364 two nodes is bidirectional or unidirectional. If U-bit is also 365 set to one (1) and the link is unidirectional, then the QRE 366 receiver is forced to stop the route discovery process. 368 QoS Parameter Count (QPCnt) 370 The most significant 3 bits, QPCnt bits, indicate the number of 371 QoS parameters being presented within the value field of QoSpar- 372 tlv. 374 QoS Parameter Mark (QoS PM) 376 The 4 bits marker of QoS PM field specifies which parameter is 377 present in QoSpar-tlv to specify the service requirements. This 378 field consists of the following bit marker. 380 0 0 381 4 5 6 7 8 4 5 6 7 8 382 +-+-+-+-+ +-+-+-+-+ 383 |QoS PM | = |B|D|J|L| 384 +-+-+-+-+ +-+-+-+-+ 386 Figure 4. QoS Parameter Marker (QoS PM) 388 B-bit (B) 390 1-bit marker to indicate whether the minimum bandwidth is speci- 391 fied as one of the service requirements within QoSpar-tlv. 393 D-bit (D) 395 1-bit marker to indicate whether the maximum delay (end to end 396 delay) is specified as one of the service requirements within 397 QoSpar-tlv. 399 J-bit (J) 401 1-bit marker to indicate whether the maximum jitter (end to end 402 jitter) is specified as one of the service requirements within 403 QoSpar-tlv. 405 L-bit (L) 407 1-bit marker to indicate whether the maximum loss probability (end 408 to end value) is specified as one of the service requirements 409 within QoSpar-tlv. 411 Reserved (Res) 413 Reserved 2 bits for the future extensions (i.e. for other QoS 414 parameters such as power of a node or assigned channel). Typically, 415 these bits are set to zero (0) and ignored in any processing. 416 These three reserved bits are funtionally equivalent to QoS PM 417 field but are conceptually distinguished from QoS PM field in order 418 to support easy to implement, i.e. byte- oriented allocation of 419 variable in conventional programming language such as C. 421 Traffic Class (Traffic Cls) 423 The Traffic Cls field allows mobile nodes to employ the per-class 424 based mechanism (say DiffServ). This field is specified by using 425 6-bits code, called DSCP (Differentiated Services Code Points) 426 that indicate a particular class [5]. 428 QoS parameter value (QoS Param) 430 The number and the type of QoS parameters depend on the QoS PI 431 (Parameter Indicator) value. If B and D bit are set to one (1), 432 for example, there MUST exist two parameter value fields so that 433 the padding field does not needed. QoS Param Value fields are 434 defined as follows. 436 - Minimum Bandwidth Requirement 437 16-bit number, measured in kbits/second (kbps). The maximum 438 value is about 131 Mbps (2^17 - 1 kbps). If the required band- 439 width is less than 1kbps, the value is set to one (1). That 440 is, the least bandwidth requirement the source requires is 1 441 Kbps. 443 - Maximum End to End Delay Requirement 444 16-bit number, measured in milliseconds (ms) 446 - Maximum End to End Jitter Requirement 447 16-bit number, measured in milliseconds (ms) 449 - Maximum End to End Loss Probability Requirement 450 16-bit number, expressed in percentage 452 - QoSstate-tlv 454 QRM conveys QoS State information for each address within 455 QoSstate-tlv. In QoS routing, intermediate nodes along a path to 456 the destination should inform the destination about its current 457 state of resources in order that the destination is able to decide 458 the optimal route among route candidates. 460 The number and the type of QoS State Values depend on the QoSpar- 461 tlv. For example, if a source specifies a delay parameter as a 462 QoS requirement (i.e. D bit in QoS PM field is set to one (1)), 463 there MUST exist a QoS state value for presenting a delay value on 464 candidate paths. In this case, all intermediate nodes MUST accu- 465 mulate its measured delay. 467 4.2 QoS Route Error (QRERR) 469 QoS Route Error (QRERR) is an extension to the DYMO RERR message. 470 QRERR message element is generated when an intermediate node realizes 471 a lack of capability to maintain the QoS guarantees for a specific 472 route. The data structure of this element is as follows. 474 0 1 2 3 475 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 477 Packet Header 479 . . . 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 QoS Route Message Header 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |qrerr-msg-type | RSRV |N|0|0| Msg-size | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Originator Address | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Hop Limit | Hop Count | Msg Sequence Number | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 QoS Route Message Body - Message TLV Block 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | msg-tlv-block-size=0 | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 QoS Route Message Body - Address Block 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 |Number Addrs=2 |0|HeadLength=3 | Head : 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 : (cont) | Target.Tail | Orig.Tail | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 QoS Route Message Body - Address TLV Block for Sequence Number 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | tlv-block-size=6 |DYMOSeqNum-type|Resv |0|1|0|0|0| 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Index-start=1 | tlv-length=2 | Orig.SeqNum | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 . . . 515 QoS Route Message Body - Address TLV Block for unsupported QoS parameters 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | QUN-tlv-Len | QUN-type | Resv |M|1|0|0| 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | TLV Len | UQParam1 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | UQParamN (if presented) | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Figure 5. QoS Route Error (QRERR) 527 - QRERR conforms to the generalized message format. 529 - msg-type = DYMO-QRERR 531 - msg-semantics 532 QRERR conforms to the msg-semantics of RERR specified in DYMO. 534 - msg-header-info 535 QRERR conforms to the msg-header-info of RERR specified in DYMO. 537 - add-block entries 538 QRERR contains 1 or more addresses as QoS Unsupported Node 539 Addresses that is the IP address of the node that cannot guarantee 540 QoS any more. 542 - add-tlv 543 QRERR contains the sequence number of the node that cannot guaran- 544 tee QoS, if known; otherwise this field set to zero (0) in a DYMO 545 Sequence Number tlv. 547 - QUN-tlv 548 QUN-tlv specify unsupported QoS parameters. 550 Unsupported QoS Parameter (UQParam) 551 The main difference between RERR and QRERR is the UQParam (Unsup- 552 ported QoS Parameter) field which is used to inform the QoS 553 requestor about which QoS parameter is no longer available for the 554 originally specified QoS requirements. Once the QoS requestor 555 receives the QRERR, it re-builds a QoS route process based on the 556 unavailable QoS parameters if it still has packets to deliver. 557 This field is illustrated in figure 6. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |QPCnt| QoS PM |Res|Traffic Cls| QoS Param Value 1 | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 |QoS Param Value N(if presented)| Padding Bits (if needed) | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 6. UQParam field 569 All fields are equivalent to the fields of QoSpar-tlv in the QRM mes- 570 sage element but differently used. QoS PCnt indicates the number of 571 scarce resource and each of their kinds are marked in QoS PM filed to 572 identify the next fields (i.e. which parameter(s) is (are) present in 573 UQParam field). 575 QoS Parameter Value 577 The QoS Parameter Value field(s) reports the measured QoS 578 parameter(s) that fails to meet the originally requested QoS. If 579 a particular node is aware of higher delay than the maximum per- 580 missible delay, the measured delay is reported to the QoS 581 requestor. 583 The QRERR message MUST be delivered to all QoS requestors potentially 584 affected by the change in the QoS parameter. 586 5. QoS DYMO Operations 588 5.1 QoS Route Discovery 590 Like DYMO routing procedures, a QoS route is also discovered by means 591 of two way handshaking consisting of a route request and route reply 592 cycle. Instead of DYMO RREQ, the source (QoS requestor) disseminates 593 QRREQ (RREQ with a QoS extension) to the destination. QRREQ message 594 elements therefore should contain required QoS parameters as well as 595 the QoS reporting information on the path that the message has been 596 experienced. Thereafter, the destination node decides a correct 597 route that can meet the QoS requirements and then sends QRREP (RREP 598 with a QoS extension) to the source. 600 Ahead of re-broadcasting a QRREQ message by an intermediate node, the 601 node must check its resources whether it is available for the QoS 602 requirements contained within the QRREQ message during the route dis- 603 covery process. Thereafter, if resources are enough to meet service 604 requirements, the intermediate node updates QoS information that is 605 present in the QRREQ message to inform the destination about the cur- 606 rent QoS states related to the path. 608 That is, QRREQ should contain two different fields. One is used to 609 specify the QoS requirements of the source (i.e. QoS requestor) that 610 must be met at nodes through the path. The other field is used to 611 inform both the QoS requestor and the destination that selects a 612 proper QoS route the current network conditions such as delay, jit- 613 ter, and/or bandwidth. 615 In case of delay and jitter, intermediate nodes accumulate each of 616 their measured delay and jitter value to the corresponding value of 617 the received QRREQ message. For this reason, the destination can be 618 aware of the end to end delay and jitter along the path. 620 In case of bandwidth (i.e. capacity to transmit), the node compares 621 its measured value with the value of QoSstate in the received QRREQ 622 message. If the measured value is smaller than the value of the mes- 623 sage, the field is updated to the measured one. This field allows 624 the destination to be aware of the actual minimum bandwidth over a 625 route from the source to the destination since the value of QSIB is 626 always bigger than the minimum value that the QoS requestor requires. 627 If it is not the case, a node MUST drop the QRREQ message since there 628 is not enough bandwidth to guarantee the required one. Such a way 629 allows the QoS requestor to be able to increase the minimum bandwidth 630 requirement according to the network condition dynamically. 632 In QoS enabled DYMO, M-bit MUST be set to one (1) and H-bits MUST be 633 set to (11). Therefore, if the QoS extended element is not supported 634 or handled by the processing node, the node MUST send a UERR to the 635 NotifyAddress (QoS requestor) and drop the message to prevent that 636 unsupported message is not propagated further. 638 In DYMO, I bit of RE message indicates whether the element has been 639 ignored by some intermediate nodes. Therefore, in QoS DYMO, if the I 640 bit is (1), the QRM message MUST be dropped. 642 The recent revision of DYMO specifies S-bit to allow the previous hop 643 to ensure that the link traversed in not unidirectional. It may be 644 useful to detect a unidirectional link(s) along a path in the process 645 of QoS route discovery. The existence of a unidirectional link may 646 not be a problem in some QoS applications such as stock quote stream- 647 ing. However, others require fully directional link on the path from 648 a source to the destination(s). Examples include multimedia confer- 649 encing, IP telephony and most of RTP based QoS applications. There- 650 fore, it is necessary to inform how each of cases is handled at nodes 651 along path. 653 When a node ensures the link is unidirectional then the node performs 654 the route discovery process based on the U-bit coupled with S-bit. 655 If U-bit and S-bit in QRM are both set to one (1), then the QRM 656 receiver is forced to stop the route discovery process. 658 5.2 QoS Route Maintenance 660 In order to react to changes in the network resources, nodes monitor 661 their links under the aspect of QoS. When a node is aware of the 662 fact that resources of its link is no longer available for the QoS 663 requestor, a QoS-Route Error (QRERR) is sent to the QoS requestor to 664 inform the current unavailable QoS parameters of the route. Once the 665 requestor receives the QRERR, it re-builds a QoS route process based 666 on the unavailable QoS parameters if it still has packets to deliver. 668 6. Security Considerations 670 This document does not discuss any special security concerns in 671 detail. The protocol of this document is built on the assumption 672 that all participating nodes are trusted each other as well as there 673 is no adversary who modifies/injects false route elements to corrupt 674 the QoS routes. 676 However, support of secure routing protocol is prerequisite for 677 launching a secure communication in the presence of adversaries. In 678 such an environment, most of all MANET routing protocols including 679 DYMO are vulnerable to many kinds of attacks. It is fairly easy to 680 inject fake routing messages or modify legitimate ones so that net- 681 work operation would be heavily disturbed (e.g., by creating loops or 682 disconnecting the network). Therefore, it is necessary to find a 683 means to authenticate/verify control messages to discover and main- 684 tain a proper route. Especially, QRM message MUST be authenticated 685 to enable nodes participating in QoS DYMO routing protocol to assure 686 the origin of the QRM message. 688 References 690 [1] I. Chakeres and C. Perkins, Dynamic MANET On-demand (DYMO) Routing. 691 IETF Internet Draft, February 2007, Work in Progress. 693 [2] Clausen, T., Dearlove, J. Dean and C. Adjih, Generalized MANET 694 Packet/Message Format, IETF Internet Draft, January 2007, Work in 695 Progress. 697 [3] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev- 698 els, Internet RFC 2119, March 1997. 700 [4] R. Braden, D. Clark and S. Shenker, Integrated Services in the 701 Internet Architecture: an Overview, Internet RFC 1633, June 1994. 703 [5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, 704 An Architecture for Differentiated Services Internet RFC 2475, 705 December 1998. 707 [6] Nichols, K., Blake, S., Baker, F. and D. Black. Definition of the 708 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Head- 709 ers, Internet RFC 2474, December 1998. 711 Author's Addresses 713 Questions about this memo can be directed to: 715 Namhi Kang 717 Ubiquitous Network Research Center 718 4F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, 719 University of Soongsil, Seoul 156-743 Korea 720 +82 2 820 0841 721 nalnal@dcn.ssu.ac.kr 723 Younghan Kim 724 University of Soongsil in Seoul 725 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 726 Dongjak-Gu, Seoul 156-743 Korea 727 +82 2 820 0904 728 yhkim@dcn.ssu.ac.kr 730 Intellectual Property Statement 732 The IETF takes no position regarding the validity or scope of any 733 Intellectual Property Rights or other rights that might be claimed to 734 pertain to the implementation or use of the technology described in 735 this document or the extent to which any license under such rights 736 might or might not be available; nor does it represent that it has 737 made any independent effort to identify any such rights. Information 738 on the procedures with respect to rights in RFC documents can be 739 found in BCP 78 and BCP 79. 741 Copies of IPR disclosures made to the IETF Secretariat and any assur- 742 ances of licenses to be made available, or the result of an attempt 743 made to obtain a general license or permission for the use of such 744 proprietary rights by implementers or users of this specification can 745 be obtained from the IETF on-line IPR repository at 746 http://www.ietf.org/ipr. 748 The IETF invites any interested party to bring to its attention any 749 copyrights, patents or patent applications, or other proprietary 750 rights that may cover technology that may be required to implement 751 this standard. Please address the information to the IETF at ietf- 752 ipr@ietf.org. 754 Disclaimer of Validity 756 This document and the information contained herein are provided on an 757 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 758 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 759 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 760 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 761 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 762 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 764 Copyright Statement 766 Copyright (C) The Internet Society (2006). This document is subject 767 to the rights, licenses and restrictions contained in BCP 78, and 768 except as set forth therein, the authors retain all their rights. 770 This document and the information contained herein are provided on 771 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 772 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 773 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 774 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 775 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 776 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 778 Acknowledgment 780 Funding for the RFC Editor function is currently provided by the 781 Internet Society.