idnits 2.17.1 draft-kang-dymoqos-05.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 711. 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 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 642 has weird spacing: '... Padhye and B...' == 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') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad Hoc Networking Working Group Minsu Kang 3 INTERNET DRAFT Namhi Kang 4 5 January 2008 Younghan Kim 5 Ubiquitous Network Research Center 6 University of Soongsil, Korea 8 Quality of Service Extension to 9 Dynamic MANET OnDemand Routing Protocol 10 draft-kang-dymoqos-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 5, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes extensions to the Dynamic MANET On-demand 44 (DYMO) routing protocol in order to enable mobile nodes to discover 45 and maintain QoS routes. DYMO is a reactive (on-demand) routing 46 protocol designed for use by mobile nodes in multi-hop wireless ad 47 hoc networks. Extensions of this document include necessary entries 48 to the routing table and DYMO routing messages. 50 Table of Contents 52 1. Introduction 3 53 2. Terminology 4 54 3. Routing Table Entries for Qos Routing 6 55 4. Extensions to DYMO Message Elements 8 56 4.1. QoS Routing Element (QRE) 8 57 4.2. QoS Route Error (QERR) 14 58 5. QoS DYMO Operations 17 59 5.1. QoS Route Discovery 17 60 5.2. QoS Route Maintenance 18 61 6. Security Considerations 19 62 References 20 63 Author's Address 21 64 Full Copyright Statement 22 65 Intellectual Property 22 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 a Route Request (RREQ) message toward the destination 73 node to discover a route to the node. Once the RREQ message arrives 74 at the destination node, it responds a Route Reply (RREP) message 75 back to the source node via the discovered path by unicasting. 76 During such a route discovery process, intermediate nodes (i.e. nodes 77 that relay the RREQ and RREP message) update its routing table based 78 on the routing information that is present in those two messages for 79 each direction. DYMO also offers adaptation to changes in network 80 topology, which can be mainly occurred by the mobility of nodes, by 81 means of the 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 (e.g. 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 describes 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. The extensions 93 specified in this document conform to the DYMO routing protocol [1] 94 (i.e. the generalized signaling framework specified in [2]). 96 In the following, the extension to routing table is first described 97 and then two routing message extensions, QoS Route Message (QRM) and 98 QoS Route Error (QRERR), are presented for supporting QoS routing. 100 2. Terminology 102 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [3]. 106 The basic terminology defined in [1] is also used in this document. 107 In addition, the following terminology is used. 109 Source Identifier (SRC ID) 110 SRC ID consists of IPSourceAddress and Port number. 112 QoS Routing Message (QRM) 113 QRM is an extension to the DYMO Routing Message (RM) to support QoS 114 routing. 116 QoS Route Request (QRREQ) 117 A source node, which is intended to discover a QoS enabled route to a 118 corresponding destination, generates and broadcasts a QRREQ message. 120 QoS Route Respond (QRREP) 121 The destination generates QRREP to inform the QRREQ generator about a 122 route available for the QoS requirements specified in the QRREQ 123 message. 125 QoS Route Error (QRERR) 126 QRERR message is used to allow a node to figure out that one or more 127 routes to destinations are not available. 129 QoS Parameter (QP) 130 QoS parameter generally includes bandwidth, end to end delay, jitter 131 loss probability and routing metric. Additional parameters MAY also 132 be defined if required, for example channel assignment. Each of the 133 parameters for a route is considered as follows. 135 - Bandwidth of a route is the minimum value from all values of 136 intermediate links from source to destination. 138 - End to end delay is the total summation value of delay 139 introduced by each of intermediate nodes between source and 140 destination pairs. 142 - End to end jitter is the total summation value of jitter 143 experienced at each of intermediate nodes between source and 144 destination pairs. 146 - End to end loss probability is the multiplicative value of loss 147 probability expected at each of intermediate nodes between source 148 and destination pairs. 150 - Routing metric can be any type of metric that nodes can support. 152 - In a single hop based wireless networking technologies such as 153 WLAN based on IEEE 802.11b, multiple channels have already been 154 used to reduce interference between node and access point. Such a 155 property can also be applied to multi-hop ad-hoc networks, thereby 156 enhancing performance in terms of QoS. 158 3. Routing Table Entry for QoS Routing 160 As described in [1], routing table entry is a conceptual data 161 structure so that implementer 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 215 RREP. This section therefore presents two extensions to the DYMO 216 RM to discover a QoS route: QRREQ and QRREP. The work especially 217 considers the compact representation for use by mobile nodes in 218 using of limited capacity, the future extensions for covering 219 various QoS parameters and the support of the per-flow based 220 mechanism and the 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 225 Message (RM) in order to enable a source to discover a path that 226 is able to 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 | Rsv |N|0|0|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 for QoS Request Type 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | msg-tlv-block-size | QoSTC-type |Resv |0|0|1|0|0| 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Length | Traffic class | QosMinBw-type |Resv |0|0|1|0|0| 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Length | QoSParam | QosMaxDel-type| 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |Resv |0|0|1|0|0| Length | QoSParam | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | QosMaxJit-type|Resv |0|0|1|0|0| Length | QoSParam : 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 : (cont) |QosMaxLosP-type|Resv |0|0|1|0|0| Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | QoSParam | QosRMet-type |Resv |0|0|1|0|0| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Length | MetricValue | QosRMet-type |Resv |0|0|1|0|0| 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Length | MetricValue | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 . . . 272 QoS Route Message Body - Address Block 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |Number Addrs=2 | Resv |0|1|0| HeadLength=3 | Head : 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 : (cont) | Target.Mid | Orig.Mid | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 QoS Route Message Body - Address TLV Block for Sequence Number 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | tlv-block-size=6 |DYMOSeqNum-type|Resv |0|1|0|0|0| 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Index-start=1 | tlv-length=2 | Orig.SeqNum | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 . . . 287 QoS Route Message Body - Address Block for QoS parameter 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Number Addrs | Resv |0|1|0| HeadLength=3 | Head : 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 : (cont) | Mid1 | ... | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | MidN | 294 +-+-+-+-+-+-+-+-+ 296 QoS Route Message Body - Address TLV Block for QoS parameter 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | tlv-block-size | QoSstate-type |Resv |M|0|1|0|1| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Length | QoS State Value1 | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | ..... | QoS State ValueN(if presented)| 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 1. Exemplified QoS Routing Message (QRM) 307 The QoS requirements of the source are specified by means of the 308 QoSpar (QoS parameter) tlv. 310 - QRM conforms to the generalized message format defined in [2]. 312 - msg-type = DYMO-QRREQ or DYMO-QRREP 313 The Type field identifies that this element is QRE (i.e. either 314 DYMO-QRREQ or DYMO-QRREP). The field also specifies how the 315 QRE is handled in case where nodes do not implement or 316 understand such QoS extensions. The data structure of the Type 317 is as follows. 319 0 0 320 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 321 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 322 | Type | = |M| H | | 323 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 325 Figure 2. Type 327 In QRE, M bit MUST be set to one (1) in order to indicate that QRE 328 requires notification via an UERR when QRE is not understood or 329 handled by a node on the path. Therefore QRE MUST convey Noti- 330 fyAddress field to which UERR is sent. The H bits in the Type 331 field MUST set to (11) in order to force a node which does not 332 support QRE to drop the QRE packet without processing any other 333 QoS DYMO elements. 335 - msg-semantics 336 QRM conforms to the msg-semantics specified in DYMO. 338 - msg-header-info 339 QRM conforms to the msg-header-info specified in DYMO. 341 - msg-tlv (QoSpar tlv) 342 This TLV field can be used differently according to the type of 343 QRM (i.e. whether it is a route request or a route reply element 344 with QoS extensions). In QRREQ message, on one hand, the QoSpar 345 tlv indicates the service requirements that must be met at nodes 346 along a route to the destination. On the other hand, in QRREP 347 message, the destination uses this field to inform the route's 348 resources available for the QoS requestor. The route's resources 349 are gathered or updated by intermediate nodes and contained within 350 the QoSstate-tlv field during the route discovery process. 352 Traffic Class Type (QoSTC-type) 354 The Traffic Cls field allows mobile nodes to employ the per-class 355 based mechanism (say DiffServ). This field is specified by using 356 6-bits code, called DSCP (Differentiated Services Code Points) 357 that indicate a particular class [5]. 359 0 360 0 1 2 3 4 5 6 7 8 361 +-+-+-+-+-+-+-+-+ 362 |0 0| DSCP | 363 +-+-+-+-+-+-+-+-+ 364 Figure 3. Traffic Class 366 Minimum Bandwidth Type (QosMinBw-type) This type indicates whether 367 the minimum bandwidth is specified as one of the service requirements 368 within tlv-value. 370 Maximum Delay Type (QosMaxDel-type) This type indicates whether the 371 maximum delay (end to end delay) is specified as one of the service 372 requirements within tlv-value. 374 Maximum Jitter (QosMaxJit-type) This type indicates whether the maxi- 375 mum jitter (end to end jitter) is specified as one of the service 376 requirements within tlv-value. 378 Maximum Loss Probability Type (QosMaxLosP-type) This type indicates 379 whether the maximum loss probability (end to end value) is specified 380 as one of the service requirements within tlv-value. 382 Routing Metric Type (QosRMet-type) This tlv-type is used to specify 383 the type and value of routing metrics of a node (i.e. ETX, ETT, 384 WCETT) [7]. If an intermediate node along a path to the destination 385 can support the metric in the tlv-type, he can update the MetricValue 386 field and his routing table. If it is not the case, he simply removes 387 the tlv type from msg-tlv. When target node receives the QRREQ con- 388 taining the QosRMet-type field, then the type of routing metric can 389 be used since entire intermediate nodes of the path can support the 390 routing metric. 392 QoS parameter value (QoS Param) QoS Param Value fields are defined as 393 follows. 395 - Minimum Bandwidth Requirement 396 16-bit number, measured in kbits/second (kbps). The maximum value 397 is about 131 Mbps (2^17 - 1 kbps). If the required band-width is 398 less than 1kbps, the value is set to one (1). That is, the least 399 bandwidth requirement the source requires is 1 Kbps. 401 - Maximum End to End Delay Requirement 402 16-bit number, measured in milliseconds (ms) 404 - Maximum End to End Jitter Requirement 405 16-bit number, measured in milliseconds (ms) 407 - Maximum End to End Loss Probability Requirement 408 16-bit number, expressed in percentage 410 - add-block entries 411 QRM conforms to the add-block entries specified in DYMO. 413 - add-tlv 414 Most of fields conform to the DYMO routing message specified in 415 [1] except the newly defined QoSpar tlv and QoSstate (QoS State 416 Information) tlv. 418 - add-block for Qos 419 Intermediate nodes along a path to the destination MAY add its 420 address or MAY add dummy address block for QoSstate-tlv. This 421 information may be useful for routing [1]. 423 - add-tlv (QoSstate-tlv) 424 QRM conveys QoS State information for each address within 425 QoSstate-tlv. In QoS routing, intermediate nodes along a path to 426 the destination should inform the destination about its current 427 state of resources in order that the destination is able to decide 428 the optimal route among route candidates. 430 The number and the type of QoS State Values depend on the QoSpar- 431 tlv. For example, if a source specifies a delay parameter as a 432 QoS requirement (i.e. The QosMDel-type is included in QoSpar-tlv), 433 there MUST exist a QoS state value for presenting a delay value on 434 candidate paths. In this case, all intermediate nodes MUST accu- 435 mulate its measured delay. 437 4.2 QoS Route Error (QRERR) 439 QoS Route Error (QRERR) is an extension to the DYMO RERR message. 440 QRERR message element is generated when an intermediate node realizes 441 a lack of capability to maintain the QoS guarantees for a specific 442 route. The data structure of this element is as follows. 444 0 1 2 3 445 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 Packet Header 449 . . . 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 QoS Route Message Header 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | msg-type | Rsv |N|0|0|0|0| Msg-size | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Originator Address | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Hop Limit | Hop Count | Msg Sequence Number | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 QoS Route Message Body - Message TLV Block 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | msg-tlv-block-size=0 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 QoS Route Message Body - Address Block 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 |Number Addrs=2 | Resv |0|1|0| HeadLength=3 | Head : 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 : (cont) | Target.Mid | Orig.Mid | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 . . . 477 QoS Route Message Body - Address TLV Block for unsupported QoS 478 parameters 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | QUN-tlv-Len | QUN-type |Resv |0|1|0|0|0| 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Index Start | Length | UQParam vaule | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | QUN-type |Resv |0|1|0|0|0| Index Start | Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | UQParam value | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 . . . 490 Figure 5. QoS Route Error (QRERR) 492 - QRERR conforms to the generalized message format. 494 - msg-type = DYMO-QRERR 496 - msg-semantics QRERR conforms to the msg-semantics of RERR specified 497 in DYMO. 499 - msg-header-info QRERR conforms to the msg-header-info of RERR spec- 500 ified in DYMO. 502 - add-block entries QRERR contains 1 or more addresses as QoS Unsup- 503 ported Node Addresses that is the IP address of the node that cannot 504 guarantee QoS any more. 506 - add-tlv-block (QUN-tlv) specify unsupported QoS parameters. 508 Unsupported QoS Parameter tlv type (QUN-type) The main difference 509 between RERR and QRERR is the UQParam (Unsupported QoS Parameter) 510 field which is used to inform the QoS requestor about which QoS 511 parameter is no longer available for the originally specified QoS 512 requirements. Once the QoS requestor receives the QRERR, it re- 513 builds a QoS route process based on the unavailable QoS parameters if 514 it still has packets to deliver. 516 QoS Parameter Value The QoS Parameter Value field(s) reports the mea- 517 sured QoS parameter(s) that fails to meet the originally requested 518 QoS. If a particular node is aware of higher delay than the maximum 519 permissible delay, the measured delay is reported to the QoS 520 requestor. 522 The QRERR message MUST be delivered to all QoS requestors potentially 523 affected by the change in the QoS parameter. 525 5. QoS DYMO Operations 527 5.1 QoS Route Discovery 529 Like DYMO routing procedures, a QoS route is also discovered by means 530 of two way handshaking consisting of a route request and route reply 531 cycle. Instead of DYMO RREQ, the source (QoS requestor) disseminates 532 QRREQ (RREQ with a QoS extension) to the destination. QRREQ message 533 elements therefore should contain required QoS parameters as well as 534 the QoS reporting information on the path that the message has been 535 experienced. Thereafter, the destination node decides a correct 536 route that can meet the QoS requirements and then sends QRREP (RREP 537 with a QoS extension) back to the source. 539 Ahead of re-broadcasting a QRREQ message by an intermediate node, the 540 node must check its resources whether it is available for the QoS 541 requirements contained within the QRREQ message during the route dis- 542 covery process. If resources are enough to support service require- 543 ments, the intermediate node updates QoS information that is present 544 in the QRREQ message to inform the destination about the current QoS 545 states related to the path. 547 The QRREQ message should contain two different fields. One is used 548 to specify the QoS requirements of the source (i.e. QoS requestor) 549 that must be met at nodes through the path. The other field is used 550 to inform both the QoS requestor and the destination about the cur- 551 rent network conditions such as delay, jitter, and/or bandwidth to 552 discover a proper QoS route. 554 In case of delay and jitter, intermediate nodes accumulate each of 555 their measured delay and jitter value to the corresponding value of 556 the received QRREQ message. For this reason, the destination can be 557 aware of the end to end delay and jitter along the path. 559 In case of bandwidth (i.e. capacity to transmit), the node compares 560 its measured value with the value of QoSstate in the received QRREQ 561 message. If the measured value is smaller than the value of the mes- 562 sage, the field is updated to the measured one. This field allows 563 the destination to be aware of the actual minimum bandwidth over a 564 route from the source to the destination since the value of QSIB is 565 always bigger than the minimum value that the QoS requestor requires. 566 If it is not the case, a node MUST drop the QRREQ message since there 567 is not enough bandwidth to guarantee the required one. Such a way 568 allows the QoS requestor to be able to increase the minimum bandwidth 569 requirement according to the network condition dynamically. 571 In QoS enabled DYMO, M-bit MUST be set to one (1) and H-bits MUST be 572 set to (11). Therefore, if the QoS extended element is not supported 573 or handled by the processing node, the node discards the message to 574 prevent that unsupported message is not propagated further. 576 The MANET-NHDP allows the previous hop to ensure that the link tra- 577 versed is not unidirectional [8]. It may be useful to detect a uni- 578 directional link(s) along a path in the process of QoS route discov- 579 ery. The existence of a unidirectional link may not be a problem in 580 some QoS applications such as one-way streaming services. However, 581 others require fully directional link on the path from a source to 582 the destination(s). Examples include multimedia conferencing, IP 583 telephony and most of RTP based QoS applications. Therefore, it is 584 necessary to inform how each of cases is handled at nodes along path. 586 When a node ensures the link is unidirectional then the QRM receiver 587 is forced to stop the route discovery process. 589 5.2 QoS Route Maintenance 591 In order to react to changes in the network resources, nodes monitor 592 their links under the aspect of QoS. When a node is aware of the 593 fact that resources of its link is no longer available for the QoS 594 requestor, a QoS-Route Error (QRERR) is sent to the QoS requestor to 595 inform the current unavailable QoS parameters of the route. Once the 596 requestor receives the QRERR, it re-builds a QoS route process based 597 on the unavailable QoS parameters if it still has packets to deliver. 599 6. Security Considerations 601 This document does not discuss any special security concerns in 602 detail. The protocol of this document is built on the assumption 603 that all participating nodes are trusted each other as well as there 604 is no adversary who modifies/injects false route elements to corrupt 605 the QoS routes. 607 However, support of secure routing protocol is prerequisite for 608 launching a secure communication in the presence of adversaries. In 609 such an environment, most of all MANET routing protocols including 610 DYMO are vulnerable to many kinds of attacks. It is fairly easy to 611 inject fake routing messages or modify legitimate ones so that net- 612 work operation would be heavily disturbed (e.g., by creating loops or 613 disconnecting the network). Therefore, it is necessary to find a 614 means to authenticate/verify control messages to discover and main- 615 tain a proper route. Especially, QRM message MUST be authenticated 616 to enable nodes participating in QoS DYMO routing protocol to assure 617 the origin of the QRM message. 619 References 621 [1] I. Chakeres and C. Perkins, Dynamic MANET On-demand (DYMO) Routing. 622 IETF Internet Draft, May 2007, Work in Progress. 624 [2] Clausen, T., Dearlove, J. Dean and C. Adjih, Generalized MANET 625 Packet/Message Format, IETF Internet Draft, June 2007, Work in 626 Progress. 628 [3] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev- 629 els, Internet RFC 2119, March 1997. 631 [4] R. Braden, D. Clark and S. Shenker, Integrated Services in the 632 Internet Architecture: an Overview, Internet RFC 1633, June 1994. 634 [5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, 635 An Architecture for Differentiated Services Internet RFC 2475, 636 December 1998. 638 [6] Nichols, K., Blake, S., Baker, F. and D. Black. Definition of the 639 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Head- 640 ers, Internet RFC 2474, December 1998. 642 [7] R. Draves, J. Padhye and B. Zill, "Routing in Multi-Radio, Multi- 643 Hop Wireless Mesh Networks", In ACM MobiCom, 2004. 645 [8] T. Clausen, C. Dearlove and J. Dean, MANET Neighborhood Discovery 646 Protocol (NHDP), IETF Internet Draft, May 2007, Work in Progress. 648 Author's Addresses 650 Questions about this memo can be directed to: 652 Minsu Kang 653 Ubiquitous Network Research Center 654 4F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, 655 University of Soongsil, Seoul 156-743 Korea 656 +82 2 820 0841 657 mdkms@dcn.ssu.ac.kr 659 Namhi Kang 660 Ubiquitous Network Research Center 661 4F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, 662 University of Soongsil, Seoul 156-743 Korea 663 +82 2 820 0841 664 nalnal@dcn.ssu.ac.kr 666 Younghan Kim 667 University of Soongsil in Seoul 668 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 669 Dongjak-Gu, Seoul 156-743 Korea 670 +82 2 820 0904 671 yhkim@dcn.ssu.ac.kr 673 Full Copyright Statement 675 Copyright (C) The IETF Trust (2007). 677 This document is subject to the rights, licenses and restrictions 678 contained in BCP 78, and except as set forth therein, the authors 679 retain all their rights. 681 This document and the information contained herein are provided on an 682 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 683 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 684 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 685 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 686 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 687 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 689 Intellectual Property 691 The IETF takes no position regarding the validity or scope of any 692 Intellectual Property Rights or other rights that might be claimed to 693 pertain to the implementation or use of the technology described in 694 this document or the extent to which any license under such rights 695 might or might not be available; nor does it represent that it has 696 made any independent effort to identify any such rights. Information 697 on the procedures with respect to rights in RFC documents can be 698 found in BCP 78 and BCP 79. 700 Copies of IPR disclosures made to the IETF Secretariat and any 701 assurances of licenses to be made available, or the result of an 702 attempt made to obtain a general license or permission for the use of 703 such proprietary rights by implementers or users of this 704 specification can be obtained from the IETF on-line IPR repository at 705 http://www.ietf.org/ipr. 707 The IETF invites any interested party to bring to its attention any 708 copyrights, patents or patent applications, or other proprietary 709 rights that may cover technology that may be required to implement 710 this standard. Please address the information to the IETF at 711 ietf-ipr@ietf.org. 713 Acknowledgment 715 Funding for the RFC Editor function is provided by the IETF 716 Administrative Support Activity (IASA).