idnits 2.17.1 draft-kang-dymoqos-03.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 758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 734. ** 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. ** 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 4 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-MATION 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 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 (~~), 4 warnings (==), 8 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 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-03.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 April 22, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 additions 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 a 71 route to the destination for MANET nodes. A source node disseminates 72 RREQ message toward the destination node to discover a route to the 73 node. Once the RREQ message arrives at the destination node, it 74 responds RREP message back to the source node over the discovered 75 path by unicasting. During such a route discovery process, 76 intermediate nodes (i.e. nodes that relay the RREQ and RREP message) 77 update its routing table based on the routing information that is 78 present in those two messages for each direction. DYMO also offers 79 adaptation to changes in network topology, which can be occurred by 80 the mobility of nodes as the main cause, by means of the route 81 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 of this document conform to the DYMO routing protocol 96 [1] (i.e. the generalized signaling framework specified in [2]). 98 In this document, the extension to routing table is first described 99 and then two routing message extensions, QoS Route Message (QRM) and 100 QoS Route Error (QRERR), are presented for supporting QoS routing. 102 2. Terminology 104 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [3]. 108 The basic terminology defined in [dymo] is used in this document. In 109 addition, the following terminology is used. 111 Source Identifier (SRC ID) 112 SRC ID consists of IPSourceAddress and Port number. 114 QoS Routing Message (QRM) 115 QRM is an extension to the DYMO Routing Message (RM) to support QoS 116 routing. 118 QoS Route Request (QRREQ) 119 A source node, which is intended to discover a QoS enabled route to a 120 corresponding destination, generates and broadcasts a QRREQ. 122 QoS Route Respond (QRREP) 123 The destination generates QRREP to inform the QRREQ generator about a 124 route available for the QoS requirements specified in QRREQ. 126 QoS Route Error (QRERR) 127 QRERR is used to allow a node to figure out that one or more routes 128 to destinations are not available. 130 QoS Parameter (QP) 131 QoS parameter generally includes bandwidth, end to end delay, jitter 132 and loss probability. Additional parameters may also be defined if 133 required. Each of the parameters for a route is considered as 134 follows. 136 - Bandwidth of a route is the minimum value from all values of 137 intermediate links from source to destination. 139 - End to end delay is the total summation value of delay 140 introduced by each of intermediate nodes between source and 141 destination pairs. 143 - End to end jitter is the total summation value of jitter 144 experienced at each of intermediate nodes between source and 145 destination pairs. 147 - End to end loss probability is the multiplicative value of loss 148 probability expected at each of intermediate nodes between source 149 and destination pairs. 151 3. Routing Table Entries for QoS Routing 153 In QoS routing, routing table entries can be defined differently 154 according to the type of QoS model; per-flow based model (say 155 IntServ model [4]) or per-class based model (say DiffServ model 156 [5]). 158 In case of the per-flow based mechanism, the following entries may 159 be added to the routing table of each DYMO router on the path. A 160 routing table entry SHOULD be defined for each flow to specify QoS 161 requirements requested by the source (requestor) of the particular 162 flow, where a flow can be identified by the pair of IP address and 163 port number (i.e. SRC ID). 165 - Minimum Available Bandwidth 167 - Maximum Tolerable Delay 169 - Maximum Tolerable Jitter 171 - Maximum Tolerable Loss Probability 173 - List of Sources Identifier Requesting Bandwidth Guarantees 175 - List of Sources Identifier Requesting Delay Guarantees 177 - List of Sources Identifier Requesting Jitter Guarantees 179 - List of Sources Identifier Requesting Loss Probability 180 Guarantees 182 In case of the class-based model, on the other hand, the following 183 fields may be added to the routing table of a DYMO router. Each 184 routing table entry SHOULD be defined for each pre-specified class, 185 where a packet belonging to each class can be distinguished by DSCP 186 (DiffServ Code Point) as specified in [6]. 188 - Minimum Available Bandwidth 190 - Maximum Tolerable Delay 192 - Maximum Tolerable Jitter 193 - Maximum Tolerable Loss Probability 195 - List of Classes 197 - List of Sources Identifier belonging to each of the Classes 199 4. Extensions to DYMO Routing Message (RM) 201 In this section, we present two extensions to DYMO routing message to 202 discover a QoS route. The work especially considers the compact 203 representation for use by mobile nodes in using of limited capacity, 204 the future extensions for covering various QoS parameters and the 205 support of the per-flow based mechanism and the per-class based 206 mechanism as well. 208 4.1 QoS Routing Message (QRM) 210 QoS Routing Message (QRM) is an extension to the DYMO Routing Message 211 (RM) in order to enable a source to discover a path that is able to 212 guarantee the QoS requirements. 214 0 1 2 3 215 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 217 Packet Header 219 . . . 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 QoS Route Message Header 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | QoSMsg-type | RSRV |N|0|0| Msg-size | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Originator Address | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Hop Limit | Hop Count | Msg Sequence Number | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 QoS Route Message Body - Message TLV Block 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | msg-tlv-block-size=0 | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 . . . 240 QoS Route Message Body - Address Block 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |Number Addrs=2 |0|HeadLength=3 | Head : 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 : (cont) | Target.Tail | Orig.Tail | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 QoS Route Message Body - Address TLV Block for Sequence Number 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | tlv-block-size=6 |DYMOSeqNum-type|Resv |0|1|0|0|0| 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Index-start=1 | tlv-length=2 | Orig.SeqNum | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 . . . 256 QoS Route Message Body - Address TLV Block for QoS parameter 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | tlv-block-size=25 | QoSpar-type |Resv |0|0|0|1|0| 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Index-start=1 | Index-start=2 | Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | QoS PI | QoSParam1 | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | QoSParam2 (if presented) | QoSParamN (if presented) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | QoSstate-tlv-Len | QoSstate-type | Resv |M|1|0|0| 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | TLV Len | QoS State Value1 |QoS State Val2.: 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 :(if presented) | QoS State ValueN(if presented)| 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 1. Exemplified QoS Routing Message (QRM) 276 The QoS requirements of the source are specified by means of the 277 QoSpar (QoS parameter) tlv. 279 - QRM conforms to the generalized message format defined in [2]. 281 - msg-type = DYMO-QRREQ or DYMO-QRREP 282 The Type field identifies that this element is QRE (i.e. either 283 DYMO-QRREQ or DYMO-QRREP). The field also specifies how the 284 QRE is handled in case where nodes do not implement or under- 285 stand such QoS extensions. The data structure of the Type is 286 as follows. 288 0 0 289 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 290 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 291 | Type | = |M| H | | 292 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 294 Figure 2. Type 296 In QRE, M bit MUST be set to one (1) in order to indicate that QRE 297 requires notification via an UERR when QRE is not understood or 298 handled by a node on the path. Therefore QRE MUST convey Noti- 299 fyAddress field to which UERR is sent. As well as the H bits in 300 the Type field MUST set to (11) in order to force a node which 301 does not support QRE to drop the QRE packet without processing any 302 other QoS DYMO elements. 304 - msg-semantics 305 QRM conforms to the msg-semantics specified in DYMO. 307 - msg-header-info 308 QRM conforms to the msg-header-info specified in DYMO. 310 - add-block entries 311 QRM conforms to the add-block entries specified in DYMO. 313 - add-tlv 314 Most of fields conform to the DYMO routing message specified in 315 [1] except the newly defined QoSpar tlv and QoSstate (QoS State 316 Information) tlv. 318 - QoSpar tlv 319 This TLV field can be used differently according to the type of 320 QRM (i.e. whether a route request or a route reply element with 321 QoS extensions). In QRREQ message, on one hand, the QoSpar tlv 322 indicates the service requirements that must be met at nodes along 323 a route to the destination. On the other hand, in QRREP message, 324 the destination uses this field to inform the route's resources 325 available for the QoS requestor. The route's resources are gath- 326 ered or updated by intermediate nodes and contained within the 327 QoSstate-tlv field during the route discovery process. The data 328 structure of QoS Parameter Indicator (QoS PI) is described in Fig- 329 ure 3. 331 0 1 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |U|QPCnt|QoS PM |Res|Traffic Cls| 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 3. QoS PI 339 U-bit (U) 341 1-bit selector to indicate whether the route discovery process to 342 be continued. If S bit is available at DYMO router, this bit is 343 coupled with the S bit. If S-bit is set to one (1) in the QRE, 344 then a reporting message SHOULD be sent to the previous hop within 345 UNICAST_MESSAGE_SENT_TIMEOUT. At this time the two nodes (i.e. 346 previous hop and QRE receiver) can detect whether the link between 347 two nodes is bidirectional or unidirectional. If U-bit is also 348 set to one (1) and the link is unidirectional, then the QRE 349 receiver is forced to stop the route discovery process. 351 QoS Parameter Count (QPCnt) 353 The most significant 3 bits, QPCnt bits, indicate the number of 354 QoS parameters being presented within the value field of QoSpar- 355 tlv. 357 QoS Parameter Mark (QoS PM) 359 The 4 bits marker of QoS PM field specifies which parameter is 360 present in QoSpar-tlv to specify the service requirements. This 361 field consists of the following bit marker. 363 0 0 364 4 5 6 7 8 4 5 6 7 8 365 +-+-+-+-+ +-+-+-+-+ 366 |QoS PM | = |B|D|J|L| 367 +-+-+-+-+ +-+-+-+-+ 369 Figure 4. QoS Parameter Marker (QoS PM) 371 B-bit (B) 373 1-bit marker to indicate whether the minimum bandwidth is speci- 374 fied as one of the service requirements within QoSpar-tlv. 376 D-bit (D) 378 1-bit marker to indicate whether the maximum delay (end to end 379 delay) is specified as one of the service requirements within 380 QoSpar-tlv. 382 J-bit (J) 384 1-bit marker to indicate whether the maximum jitter (end to end 385 jitter) is specified as one of the service requirements within 386 QoSpar-tlv. 388 L-bit (L) 390 1-bit marker to indicate whether the maximum loss probability (end 391 to end value) is specified as one of the service requirements 392 within QoSpar-tlv. 394 Reserved (Res) 396 Reserved 2 bits for the future extensions (i.e. for other QoS 397 parameters such as power of a node). Typically, these bits are 398 set to zero (0) and ignored in any processing. These three 399 reserved bits are funtionally equivalent to QoS PM field but are 400 conceptually distinguished from QoS PM field in order to support 401 easy to implement, i.e. byte- oriented allocation of variable in 402 conventional programming language such as C. 404 Traffic Class (Traffic Cls) 406 The Traffic Cls field allows mobile nodes to employ the per-class 407 based mechanism (say DiffServ). This field is specified by using 408 6-bits code, called DSCP (Differentiated Services Code Points) 409 that indicate a particular class [5]. 411 QoS parameter value (QoS Param) 413 The number and the type of QoS parameters depend on the QoS PI 414 (Parameter Indicator) value. If B and D bit are set to one (1), 415 for example, there MUST exist two parameter value fields so that 416 the padding field does not needed. QoS Param Value fields are 417 defined as follows. 419 - Minimum Bandwidth Requirement 420 16-bit number, measured in kbits/second (kbps). The maximum 421 value is about 131 Mbps (2^17 - 1 kbps). If the required band- 422 width is less than 1kbps, the value is set to one (1). That 423 is, the least bandwidth requirement the source requires is 1 424 Kbps. 426 - Maximum End to End Delay Requirement 427 16-bit number, measured in milliseconds (ms) 429 - Maximum End to End Jitter Requirement 430 16-bit number, measured in milliseconds (ms) 432 - Maximum End to End Loss Probability Requirement 433 16-bit number, expressed in percentage 435 - QoSstate-tlv 437 QRM conveys QoS State information for each address within 438 QoSstate-tlv. In QoS routing, intermediate nodes along a path to 439 the destination should inform the destination about its current 440 state of resources in order that the destination is able to decide 441 the optimal route among route candidates. 443 The number and the type of QoS State Values depend on the QoSpar- 444 tlv. For example, if a source specifies a delay parameter as a 445 QoS requirement (i.e. D bit in QoS PM field is set to one (1)), 446 there MUST exist a QoS state value for presenting a delay value on 447 candidate paths. In this case, all intermediate nodes MUST accu- 448 mulate its measured delay. 450 4.2 QoS Route Error (QRERR) 452 QoS Route Error (QRERR) is an extension to the DYMO RERR message. 453 QRERR message element is generated when an intermediate node realizes 454 a lack of capability to maintain the QoS guarantees for a specific 455 route. The data structure of this element is as follows. 457 0 1 2 3 458 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 460 Packet Header 462 . . . 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 QoS Route Message Header 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 |qrerr-msg-type | RSRV |N|0|0| Msg-size | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Originator Address | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Hop Limit | Hop Count | Msg Sequence Number | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 QoS Route Message Body - Message TLV Block 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | msg-tlv-block-size=0 | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 QoS Route Message Body - Address Block 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |Number Addrs=2 |0|HeadLength=3 | Head : 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 : (cont) | Target.Tail | Orig.Tail | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 QoS Route Message Body - Address TLV Block for Sequence Number 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | tlv-block-size=6 |DYMOSeqNum-type|Resv |0|1|0|0|0| 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Index-start=1 | tlv-length=2 | Orig.SeqNum | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 . . . 498 QoS Route Message Body - Address TLV Block for unsupported QoS 499 parameters 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | QUN-tlv-Len | QUN-type | Resv |M|1|0|0| 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | TLV Len | UQParam1 | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | UQParamN (if presented) | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 5. QoS Route Error (QRERR) 510 - QRERR conforms to the generalized message format. 512 - msg-type = DYMO-QRERR 514 - msg-semantics 515 QRERR conforms to the msg-semantics of RERR specified in DYMO. 517 - msg-header-info 518 QRERR conforms to the msg-header-info of RERR specified in DYMO. 520 - add-block entries 521 QRERR contains 1 or more addresses as QoS Unsupported Node 522 Addresses that is the IP address of the node that cannot guarantee 523 QoS any more. 525 - add-tlv 526 QRERR contains the sequence number of the node that cannot guaran- 527 tee QoS, if known; otherwise this field set to zero (0) in a DYMO 528 Sequence Number tlv. 530 - QUN-tlv 531 QUN-tlv specify unsupported QoS parameters. 533 Unsupported QoS Parameter (UQParam) 534 The main difference between RERR and QRERR is the UQParam (Unsup- 535 ported QoS Parameter) field which is used to inform the QoS 536 requestor about which QoS parameter is no longer available for the 537 originally specified QoS requirements. Once the QoS requestor 538 receives the QRERR, it re-builds a QoS route process based on the 539 unavailable QoS parameters if it still has packets to deliver. 540 This field is illustrated in figure 6. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 |QPCnt| QoS PM |Res|Traffic Cls| QoS Param Value 1 | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |QoS Param Value N(if presented)| Padding Bits (if needed) | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 6. UQParam field 552 All fields are equivalent to the fields of QoSpar-tlv in the QRM mes- 553 sage element but differently used. QoS PCnt indicates the number of 554 scarce resource and each of their kinds are marked in QoS PM filed to 555 identify the next fields (i.e. which parameter(s) is (are) present in 556 UQParam field). 558 QoS Parameter Value 560 The QoS Parameter Value field(s) reports the measured QoS parame- 561 ter(s) that fails to meet the originally requested QoS. If a par- 562 ticular node is aware of higher delay than the maximum permissible 563 delay, the measured delay is reported to the QoS requestor. 565 The QRERR message MUST be delivered to all QoS requestors potentially 566 affected by the change in the QoS parameter. 568 5. QoS DYMO Operations 570 5.1 QoS Route Discovery 572 Like DYMO routing procedures, a QoS route is also discovered by means 573 of two way handshaking consisting of a route request and route reply 574 cycle. Instead of DYMO RREQ, the source (QoS requestor) disseminates 575 QRREQ (RREQ with a QoS extension) to the destination. QRREQ message 576 elements therefore should contain required QoS parameters as well as 577 the QoS reporting information on the path that the message has been 578 experienced. Thereafter, the destination node decides a correct 579 route that can meet the QoS requirements and then sends QRREP (RREP 580 with a QoS extension) to the source. 582 Ahead of re-broadcasting a QRREQ message by an intermediate node, the 583 node must check its resources whether it is available for the QoS 584 requirements contained within the QRREQ message during the route dis- 585 covery process. Thereafter, if resources are enough to meet service 586 requirements, the intermediate node updates QoS information that is 587 present in the QRREQ message to inform the destination about the cur- 588 rent QoS states related to the path. 590 That is, QRREQ should contain two different fields. One is used to 591 specify the QoS requirements of the source (i.e. QoS requestor) that 592 must be met at nodes through the path. The other field is used to 593 inform both the QoS requestor and the destination that selects a 594 proper QoS route the current network conditions such as delay, jit- 595 ter, and/or bandwidth. 597 In case of delay and jitter, intermediate nodes accumulate each of 598 their measured delay and jitter value to the corresponding value of 599 the received QRREQ message. For this reason, the destination can be 600 aware of the end to end delay and jitter along the path. 602 In case of bandwidth (i.e. capacity to transmit), the node compares 603 its measured value with the value of QoSstate in the received QRREQ 604 message. If the measured value is smaller than the value of the mes- 605 sage, the field is updated to the measured one. This field allows 606 the destination to be aware of the actual minimum bandwidth over a 607 route from the source to the destination since the value of QSIB is 608 always bigger than the minimum value that the QoS requestor requires. 609 If it is not the case, a node MUST drop the QRREQ message since there 610 is not enough bandwidth to guarantee the required one. Such a way 611 allows the QoS requestor to be able to increase the minimum bandwidth 612 requirement according to the network condition dynamically. 614 In QoS enabled DYMO, M-bit MUST be set to one (1) and H-bits MUST be 615 set to (11). Therefore, if the QoS extended element is not supported 616 or handled by the processing node, the node MUST send a UERR to the 617 NotifyAddress (QoS requestor) and drop the message to prevent that 618 unsupported message is not propagated further. 620 In DYMO, I bit of RE message indicates whether the element has been 621 ignored by some intermediate nodes. Therefore, in QoS DYMO, if the I 622 bit is (1), the QRM message MUST be dropped. 624 The recent revision of DYMO specifies S-bit to allow the previous hop 625 to ensure that the link traversed in not unidirectional. It may be 626 useful to detect a unidirectional link(s) along a path in the process 627 of QoS route discovery. The existence of a unidirectional link may 628 not be a problem in some QoS applications such as stock quote stream- 629 ing. However, others require fully directional link on the path from 630 a source to the destination(s). Examples include multimedia confer- 631 encing, IP telephony and most of RTP based QoS applications. There- 632 fore, it is necessary to inform how each of cases is handled at nodes 633 along path. 635 When a node ensures the link is unidirectional then the node performs 636 the route discovery process based on the U-bit coupled with S-bit. 637 If U-bit and S-bit in QRM are both set to one (1), then the QRM 638 receiver is forced to stop the route discovery process. 640 5.2 QoS Route Maintenance 642 In order to react to changes in the network resources, nodes monitor 643 their links under the aspect of QoS. When a node is aware of the 644 fact that resources of its link is no longer available for the QoS 645 requestor, a QoS-Route Error (QRERR) is sent to the QoS requestor to 646 inform the current unavailable QoS parameters of the route. Once the 647 requestor receives the QRERR, it re-builds a QoS route process based 648 on the unavailable QoS parameters if it still has packets to deliver. 650 6. Security Considerations 652 This document does not discuss any special security concerns in 653 detail. The protocol of this document is built on the assumption 654 that all participating nodes are trusted each other as well as there 655 is no adversary who modifies/injects false route elements to corrupt 656 the QoS routes. 658 However, support of secure routing protocol is prerequisite for 659 launching a secure communication in the presence of adversaries. In 660 such an environment, most of all MANET routing protocols including 661 DYMO are vulnerable to many kinds of attacks. It is fairly easy to 662 inject fake routing messages or modify legitimate ones so that net- 663 work operation would be heavily disturbed (e.g., by creating loops or 664 disconnecting the network). Therefore, it is necessary to find a 665 means to authenticate/verify control messages to discover and main- 666 tain a proper route. Especially, QRM message MUST be authenticated 667 to enable nodes participating in QoS DYMO routing protocol to assure 668 the origin of the QRM message. 670 References 672 [1] I. Chakeres and C. Perkins, Dynamic MANET On-demand (DYMO) Routing. 673 IETF Internet Draft, October 2006, Work in Progress. 675 [2] Clausen, T., Dearlove, J. Dean and C. Adjih, Generalized MANET 676 Packet/Message Format, IETF Internet Draft, July 2006, Work in 677 Progress. 679 [3] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev- 680 els, Internet RFC 2119, March 1997. 682 [4] R. Braden, D. Clark and S. Shenker, Integrated Services in the 683 Internet Architecture: an Overview, Internet RFC 1633, June 1994. 685 [5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, 686 An Architecture for Differentiated Services Internet RFC 2475, 687 December 1998. 689 [6] Nichols, K., Blake, S., Baker, F. and D. Black. Definition of the 690 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Head- 691 ers, Internet RFC 2474, December 1998. 693 Author's Addresses 695 Questions about this memo can be directed to: 697 Namhi Kang 699 Ubiquitous Network Research Center 700 4F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, 701 University of Soongsil, Seoul 156-743 Korea 702 +82 2 820 0841 703 nalnal@dcn.ssu.ac.kr 705 Younghan Kim 706 University of Soongsil in Seoul 707 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 708 Dongjak-Gu, Seoul 156-743 Korea 709 +82 2 820 0904 710 yhkim@dcn.ssu.ac.kr 712 Intellectual Property Statement 714 The IETF takes no position regarding the validity or scope of any 715 Intellectual Property Rights or other rights that might be claimed to 716 pertain to the implementation or use of the technology described in 717 this document or the extent to which any license under such rights 718 might or might not be available; nor does it represent that it has 719 made any independent effort to identify any such rights. Information 720 on the procedures with respect to rights in RFC documents can be 721 found in BCP 78 and BCP 79. 723 Copies of IPR disclosures made to the IETF Secretariat and any assur- 724 ances of licenses to be made available, or the result of an attempt 725 made to obtain a general license or permission for the use of such 726 proprietary rights by implementers or users of this specification can 727 be obtained from the IETF on-line IPR repository at 728 http://www.ietf.org/ipr. 730 The IETF invites any interested party to bring to its attention any 731 copyrights, patents or patent applications, or other proprietary 732 rights that may cover technology that may be required to implement 733 this standard. Please address the information to the IETF at ietf- 734 ipr@ietf.org. 736 Disclaimer of Validity 738 This document and the information contained herein are provided on an 739 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 740 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 741 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 742 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 743 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 744 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 746 Copyright Statement 748 Copyright (C) The Internet Society (2006). This document is subject 749 to the rights, licenses and restrictions contained in BCP 78, and 750 except as set forth therein, the authors retain all their rights. 752 This document and the information contained herein are provided on 753 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 754 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 755 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 756 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 757 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 760 Acknowledgment 762 Funding for the RFC Editor function is currently provided by the 763 Internet Society.