idnits 2.17.1 draft-kang-dymoqos-01.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 3979, Section 5, paragraph 1 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 623. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-03 ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 DASAN Networks Inc. 4 2 March 2006 Younghan Kim 5 University of Soongsil, Korea 7 Quality of Service Extension to 8 Dynamic MANET OnDemand Routing Protocol 9 draft-kang-dymoqos-01.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 1, 2006. 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 the DYMO message element. 49 Table of Contents 51 1. Introduction 3 52 2. Routing Table Entries for Qos Routing 4 53 3. Extensions to DYMO Message Elements 5 54 3.1. QoS Routing Element (QRE) 5 55 3.2. QoS Route Error (QERR) 10 56 4. QoS DYMO Operations 12 57 4.1. QoS Route Discovery 12 58 4.2. QoS Route Maintenance 13 59 5. Security Considerations 14 60 6. Revision of the Draft 15 61 References 16 62 Author's Address 16 63 Intellectual Property Statement 17 64 Disclaimer of Validity 17 65 Copyright Statement 17 67 1. Introduction 69 The DYMO routing protocol specifies a reactive means to discover a 70 route to the destination for MANET nodes. A source node disseminates 71 RREQ message toward the destination node to discover a route to the 72 node. Once the RREQ message arrives at the destination node, it 73 responds RREP message back to the source node over the discovered 74 path by unicasting. During such a route discovery process, 75 intermediate nodes (i.e. nodes that relay the RREQ and RREP message) 76 update its routing table based on the routing information that is 77 present in those two messages for each direction. DYMO also offers 78 adaptation to changing network topology, which can be occurred by the 79 mobility of nodes as the main cause, by means of the route 80 maintenance mechanisms [1]. 82 In order to provide MANET nodes with QoS routes, extensions to DYMO 83 message elements are required. These extensions specify the service 84 requirements (say maximum tolerable delay, maximum tolerable jitter, 85 and/or minimum bandwidth limitation) that must be guaranteed by nodes 86 along a route from a source to the destination. 88 This document presents which extensions are required for support QoS 89 in routing, how service guarantees are achieved by using the defined 90 extensions without high impacts on the existing DYMO operations and 91 how QoS routes are discovered and maintained are also briefly 92 described. 94 The extensions of this document conform to the DYMO routing protocol 95 (i.e. the extentions to DYMO data structure specified in [1]). 97 In this document, the extension to routing table is first described 98 and then two message element extensions, QoS Route Element (QRE) and 99 QoS Route Error (QRERR), are presented for supporting QoS routing. 101 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [2]. 105 2. Routing Table Entries for QoS Routing 107 In QoS routing, routing table entries can be defined differently 108 according to the type of QoS model; per-flow based model (say IntServ 109 model [3]) or per-class based model (say DiffServ model [4]). 111 In case of the per-flow based mechanism, the following entries may be 112 added to the routing table of each DYMO router on the path. A 113 routing table entry is defined for each flow to specify QoS 114 requirements requested by the source (requestor) of the particular 115 flow, where a flow can be identified by the pair of IP address and 116 port number. 118 - Maximum Tolerable Delay 120 - Maximum Tolerable Jitter 122 - Minimum Available Bandwidth 124 - List of Sources Identifier Requesting Delay Guarantees 126 - List of Sources Identifier Requesting Jitter Guarantees 128 - List of Sources Identifier Requesting Bandwidth Guarantees, 129 where the Source Identifier consists of IPSourceAddress and Port 130 number. 132 In case of the class-based model, on the other hand, the following 133 fields may be added to the routing table of a DYMO router. Each 134 routing table entry is defined for each pre-specified class, where a 135 packet belonging to each class can be distinguished by DSCP (DiffServ 136 Code Point) as specified in [5]. 138 - Maximum Tolerable Delay 140 - Maximum Tolerable Jitter 142 - Minimum Available Bandwidth 144 - List of Classes 146 - List of Sources Identifier Belonging to Each Class 148 3. Extensions to DYMO Message Elements 150 In this section, we present two extensions to DYMO message element 151 for support QoS route. The work especially considers the compact 152 representation for use by mobile nodes in using of limited capacity, 153 the future extensions for covering various QoS parameters and the 154 support of the per-flow based mechanism and the per-class based 155 mechanism as well. 157 3.1 QoS Routing Element (QRE) 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Len | TTL |I|A|S| Res | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 : NotifyAddress (QoS Requestor) : 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 : TargetAddress : 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | TargetSeqNum | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 : : 171 : QoS Information Block (QIB) : 172 : : 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 : : 175 : QoS State Information Block (QSIB) : 176 : : 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | THopCnt |Res| : 179 +-+-+-+-+-+-+-+-+ : 180 : : 181 : Routing Blocks (RBlocks) : 182 : : 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1. QoS Routing Element (QRE) 187 QoS Routing Element (QRE) is an extension to the DYMO Routing Element 188 (RE) in order to enable a source to discover a path that is able to 189 guarantee the QoS requirements. The QoS requirements of the source 190 are specified in the QIB (QoS Information Block) field. 192 Element Type (Type) 194 The Type field identifies that this element is QRE. The field 195 also specifies how the QRE is handled in case where nodes do not 196 implement or understand such QoS extensions. The data structure 197 of the Type is as follows. 199 0 0 200 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 201 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 202 | Type | = |M| H | | 203 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 205 Figure 2. Type 207 In QRE, M bit MUST be set to one (1) in order to indicate that QRE 208 requires notification via an UERR when QRE is not understood or 209 handled by a node on the path. Therefore QRE MUST convey Noti- 210 fyAddress field to which UERR is sent. As well as the H bits in 211 the Type field MUST set to (11) in order to force a node which 212 does not support QRE to drop the QRE packet without processing any 213 other QoS DYMO elements. 215 NotifyAddress (QoS Requestor) 217 IP address of the source that have originally generated this QRE 218 to request a particular service. 220 Most of fields conform to the DYMO message element specified in [1] 221 except the newly defined two information block fields (i.e. QoS 222 Information Block (QIB) and QoS State Information Block (QSIB)). 223 Those two blocks are defined as follows. 225 QoS Information Block (QIB) 227 This field can be used differently according to the type of ele- 228 ment message (i.e. whether a route request or a route reply ele- 229 ment with QoS extensions). In QRREQ message, on one hand, the QIB 230 field indicates the service requirements that must be met at nodes 231 along a route to the destination. On the other hand, in QRREP 232 message, the destination uses this field to inform the route's 233 resources available for the QoS requestor. The route's resources 234 are gathered or updated by intermediate nodes and contained within 235 the QSIB field during the route discovery process. The data 236 structure of QIB field is described in Figure 3. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |U|QPCnt|QoS PM |Res|Traffic Cls| QoS Param Value 1 | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |QoS Param Value N(if presented)| Padding Bits (if needed) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 3. QoS Information Block (QIB) 248 U-bit (U) 250 1-bit selector to indicate whether the route discovery process to 251 be continued. This bit is coupled with S bit of QRE. If S-bit is 252 set to one (1) in the QRE, then a reporting message SHOULD be sent 253 to the previous hop within UNICAST_MESSAGE_SENT_TIMEOUT as speci- 254 fied in [1]. At this time the two nodes (i.e. previous hop and 255 QRE receiver) can detect whether the link between two nodes is 256 bidirectional or unidirectional. If U-bit is also set to one (1) 257 and the link is unidirectional, then the QRE receiver is forced to 258 stop the route discovery process. 260 QoS Parameter Count (QPCnt) 262 The most significant 3 bits, QPCnt bits, indicate the number of 263 QoS parameters being presented within the QIB field. 265 QoS Parameter Mark (QoS PM) 267 The 5 bits marker of QoS PM field specifies which parameter is 268 present in QIB to specify the service requirements. This field 269 consists of the following bit marker. 271 0 0 272 4 5 6 7 8 4 5 6 7 8 273 +-+-+-+-+ +-+-+-+-+ 274 |QoS PM | = |B|D|J|R| 275 +-+-+-+-+ +-+-+-+-+ 277 Figure 4. QoS Parameter Marker (QoS PM) 279 B-bit (B) 281 1-bit marker to indicate whether the minimum bandwidth is speci- 282 fied as one of the service requirements within QIB. 284 D-bit (D) 286 1-bit marker to indicate whether the maximum delay (end to end 287 delay) is specified as one of the service requirements within QIB. 289 J-bit (J) 291 1-bit marker to indicate whether the maximum jitter (end to end 292 jitter) is specified as one of the service requirements within 293 QIB. 295 R-bit (R) 297 Reserved 1 bit for the future extensions (i.e. for other QoS 298 parameters such as power of a node). Typically, this bit is set 299 to zero (0) and ignored in any processing. 301 Reserved (Res) 303 Reserved 2 bits for the future extensions. Typically, these bits 304 are set to zero (0) and ignored in any processing. In addition to 305 these 2 bits, there exists one more reserved bit described above 306 (in QoS PM field). These three reserved bits are conceptually 307 distinguished in order to support easy to implement, i.e. byte- 308 oriented allocation of variable in conventional programming lan- 309 guage such as C. 311 Traffic Class (Traffic Cls) 313 The Traffic Cls field allows mobile nodes to employ the per-class 314 based mechanism (say DiffServ). This field is specified by using 315 6-bits code, called DSCP (Differentiated Services Code Points) 316 that indicate a particular class [5]. 318 QoS parameter value (QoS Param Value) 320 The number and the type of QoS parameters depend on the first 16 321 bytes of QIB as addressed above. If B and D bit are set to one 322 (1), for example, there MUST exist two parameter value fields so 323 that the padding field does not needed. QoS Param Value fields 324 are defined as follows. 326 - Minimum Bandwidth Requirement 327 16-bit number, measured in kbits/second (kbps). The maximum 328 value is about 131 Mbps (2^17 - 1 kbps). If the required band- 329 width is less than 1kbps, the value is set to one (1). That 330 is, the least bandwidth requirement the source requires is 1 331 Kbps. 333 - Maximum End to End Delay Requirement 334 16-bit number, measured in milliseconds (ms) 336 - Maximum End to End Jitter Requirement 337 16-bit number, measured in milliseconds (ms) 339 Padding Bits 341 The Padding field of QIB is used to confirm to DYMO message ele- 342 ment. If QoS PCnt is even number then these bits are set to zero 343 (0). 345 QoS State Information Block (QSIB) 347 In QoS routing, intermediate nodes along a path to the destination 348 should inform the destination about its current state of resources 349 in order that the destination is able to decide the optimal route 350 among route candidates. The number and the type of QoS State Val- 351 ues depend on the QIB field. For example, if a source specifies a 352 delay parameter as a QoS requirement (i.e. D bit in QoS PM field 353 is set to one (1)), there MUST exist a QoS state value in QSIB for 354 presenting a delay value on candidate paths. In this case, all 355 intermediate nodes MUST accumulate its measured delay. The data 356 structure of the QSIB is illustrated in figure 5. 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | QoS State Value 1 |QoS State Value N(if presented)| 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |QoS State Value N(if presented)| Padding Bits (if needed) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 5. QoS State Information Block (QoS SIB) 368 3.2 QoS Route Error (QRERR) 370 QoS Route Error (QRERR) is an extension to the DYMO RERR message ele- 371 ment. QRERR message element is generated when an intermediate node 372 realizes a lack of capability to maintain the QoS guarantees for a 373 specific route. The data structure of this element is as follows. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Len | TTL |I|Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 : QUNodeAddress1 : 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | QUNodeSeqNum1 | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | UQParam1 | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 : Additional QUNodeAddressN (if needed) : 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Additional QUNodeSeqNumN (if needed) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 6. QoS Route Error (QRERR) 393 QoS Unsupported Node Address (QUNodeAddress) 395 The IP address of the node that cannot guarantee QoS any more. 397 QoS Unsupported Node Sequence Number (QUNodeSeqNum) 399 The sequence number of the node that cannot guarantee QoS, if 400 known; otherwise this field set to zero (0). 402 Unsupported QoS Parameter (UQParam) 404 The main difference between RERR and QRERR is the UQParam (Unsup- 405 ported QoS Parameter) field which is used to inform the QoS 406 requestor about which QoS parameter is no longer available for the 407 originally specified QoS requirements. Once the QoS requestor 408 receives the QRERR, it re-builds a QoS route process based on the 409 unavailable QoS parameters if it still has packets to deliver. 410 This field is illustrated in figure 7. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |QPCnt| QoS PM |Res|Traffic Cls| QoS Param Value 1 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |QoS Param Value N(if presented)| Padding Bits (if needed) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 7. UQParam field 422 All fields are equivalent to the fields of QIB in the QRE message 423 element but differently used. QoS PCnt indicates the number of 424 scarce resource and each of their kinds are marked in QoS PM filed to 425 identify the next fields (i.e. which parameter(s) is (are) present in 426 UQParam field). 428 QoS Parameter Value 430 The QoS Parameter Value field reports the measured QoS parame- 431 ter(s) that fails to meet the originally requested QoS. If a par- 432 ticular node is aware of higher delay than the maximum permissible 433 delay, the measured delay is reported to the QoS requestor. 435 The QRERR message MUST be delivered to all QoS requestors potentially 436 affected by the change in the QoS parameter. 438 4. QoS DYMO Operations 440 4.1 QoS Route Discovery 442 Like DYMO routing procedures, a QoS route is also discovered by means 443 of two way handshaking consisting of a route request and route reply 444 cycle. Instead of DYMO RREQ, the source (QoS requestor) disseminates 445 QRREQ (RREQ with a QoS extension) to the destination. QRREQ message 446 elements therefore should contain required QoS parameters as well as 447 the QoS reporting information on the path that the message has been 448 experienced. Thereafter, the destination node decides a correct 449 route that can meet the QoS requirements and then sends QRREP (RREP 450 with a QoS extension) to the source. 452 Ahead of re-broadcasting a QRREQ message by an intermediate node, the 453 node must check its resources whether it is available for the QoS 454 requirements contained within the QRREQ message during the route dis- 455 covery process. Thereafter, if resources are enough to meet service 456 requirements, the intermediate node updates QoS information that is 457 present in the QRREQ message to inform the destination about the cur- 458 rent QoS states related to the path. 460 That is, QRREQ should contain two different fields. One is used to 461 specify the QoS requirements of the source (i.e. QoS requestor) that 462 must be met at nodes through the path. The other field is used to 463 inform both the QoS requestor and the destination that selects a 464 proper QoS route the current network conditions such as delay, jit- 465 ter, and/or bandwidth. 467 In case of delay and jitter, intermediate nodes accumulate each of 468 their measured delay and jitter value to the corresponding value of 469 the received QRREQ message. For this reason, the destination can be 470 aware of the end to end delay and jitter along the path. 472 In case of bandwidth (i.e. capacity to transmit), the node compares 473 its measured value with the value of QSIB field in the received QRREQ 474 message. If the measured value is smaller than the value of the mes- 475 sage, the field is updated to the measured one. This field allows 476 the destination to be aware of the actual minimum bandwidth over a 477 route from the source to the destination since the value of QSIB is 478 always bigger than the minimum value that the QoS requestor requires. 479 If it is not the case, a node MUST drop the QRREQ message since there 480 is not enough bandwidth to guarantee the required one. Such a way 481 allows the QoS requestor to be able to increase the minimum bandwidth 482 requirement according to the network condition dynamically. 484 In QoS enabled DYMO, M-bit MUST be set to one (1) and H-bits MUST be 485 set to (11). Therefore, if the QoS extended element is not supported 486 or handled by the processing node, the node MUST send a UERR to the 487 NotifyAddress (QoS requestor) and drop the message to prevent that 488 unsupported message is not propagated further. 490 In DYMO, I bit of RE message indicates whether the element has been 491 ignored by some intermediate nodes. Therefore, in QoS DYMO, if the I 492 bit is (1), the QRE message MUST be dropped. 494 The recent revision of DYMO specifies S-bit to allow the previous hop 495 to ensure that the link traversed in not unidirectional. It may be 496 useful to detect a unidirectional link(s) along a path in the process 497 of QoS route discovery. The existence of a unidirectional link may 498 not be a problem in some QoS applications such as stock quote stream- 499 ing. However, others require fully directional link on the path from 500 a source to the destination(s). Examples include multimedia confer- 501 encing, IP telephony and most of RTP based QoS applications. There- 502 fore, it is necessary to inform how each of cases is handled at nodes 503 along path. 505 When a node ensures the link is unidirectional then the node performs 506 the route discovery process based on the U-bit coupled with S-bit. 507 If U-bit and S-bit in QRE are both set to one (1), then the QRE 508 receiver is forced to stop the route discovery process. 510 4.2 QoS Route Maintenance 512 In order to react to changes in the network resources, nodes monitor 513 their links under the aspect of QoS. When a node is aware of the 514 fact that resources of its link is no longer available for the QoS 515 requestor, a QoS-Route Error (QRERR) is sent to the QoS requestor to 516 inform the current unavailable QoS parameters of the route. Once the 517 requestor receives the QRERR, it re-builds a QoS route process based 518 on the unavailable QoS parameters if it still has packets to deliver. 520 5. Security Considerations 522 This document does not discuss any special security concerns in 523 detail. The protocol of this document is built on the assumption 524 that all participating nodes are trusted each other as well as there 525 is no adversary who modifies/injects false route elements to corrupt 526 the QoS routes. 528 However, support of secure routing protocol is prerequisite for 529 launching a secure communication in the presence of adversaries. In 530 such an environment, most of all MANET routing protocols including 531 DYMO are vulnerable to many kinds of attacks. It is fairly easy to 532 inject fake routing messages or modify legitimate ones so that net- 533 work operation would be heavily disturbed (e.g., by creating loops or 534 disconnecting the network). Therefore, it is necessary to find a 535 means to authenticate/verify control messages to discover and main- 536 tain a proper route. Especially, QRE message MUST be authenticated 537 to enable nodes participating in QoS DYMO routing protocol to assure 538 the origin of the QRE message. 540 6. Revision of the Draft 542 Version 1 of the draft has been revised as follows. 544 - This section was been appended. 546 - Several TYPOs was been corrected. 548 - Some work was done to allow the draft to be compatible to the 549 last revision of DYMO draft such that 551 o Inserting S-bit into QoS Routing Element (QRE) 553 o Inserting U-bit into QoS Information Block (QIB) 555 o Modifying QoS Parameter Marker field 557 o Adding the description how the U-Bit is handled in section 558 3.1 and section 4.1 560 References 562 [1] I. Chakeres, E. Belding-Royer and C. Perkins. Dynamic MANET On- 563 demand (DYMO) Routing. IETF Internet Draft draft-ietf-manet- 564 dymo-03 June 2005. Work in Progress. 566 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Lev- 567 els. Internet RFC 2119, March 1997. 569 [3] R. Braden, D. Clark, and S. Shenker, Integrated Services in the 570 Internet Architecture: an Overview, Internet RFC 1633, June 1994. 572 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, 573 An Architecture for Differentiated Services Internet RFC 2475, 574 Decem- ber 1998. 576 [5] Nichols, K., Blake, S., Baker, F. and D. Black. Definition of the 577 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Head- 578 ers, Internet RFC 2474, December 1998. 580 Author's Addresses 582 Questions about this memo can be directed to: 584 Namhi Kang 585 Ubiquitous Network Research Center 586 DASAN Networks Inc. 587 3F FineVenture Bldg. 345-1, YaTap-Dong, 588 BunDang-Gu, SeongNam-Si, KyongGi-Do, 463-070 589 Korea 590 +82 2 814 0151 591 nalnal@dcn.ssu.ac.kr 593 Younghan Kim 594 University of Soongsil in Seoul 595 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 596 Dongjak-Gu, Seoul 156-743 597 Korea 598 +82 2 820 0904 599 yhkim@dcn.ssu.ac.kr 601 Intellectual Property Statement 603 The IETF takes no position regarding the validity or scope of any 604 Intellectual Property Rights or other rights that might be claimed to 605 pertain to the implementation or use of the technology described in 606 this document or the extent to which any license under such rights 607 might or might not be available; nor does it represent that it has 608 made any independent effort to identify any such rights. Information 609 on the procedures with respect to rights in RFC documents can be 610 found in BCP 78 and BCP 79. 612 Copies of IPR disclosures made to the IETF Secretariat and any assur- 613 ances of licenses to be made available, or the result of an attempt 614 made to obtain a general license or permission for the use of such 615 proprietary rights by implementers or users of this specification can 616 be obtained from the IETF on-line IPR repository at 617 http://www.ietf.org/ipr. 619 The IETF invites any interested party to bring to its attention any 620 copyrights, patents or patent applications, or other proprietary 621 rights that may cover technology that may be required to implement 622 this standard. Please address the information to the IETF at ietf- 623 ipr@ietf.org. 625 Disclaimer of Validity 627 This document and the information contained herein are provided on an 628 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 629 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 630 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 631 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 632 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 633 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 Copyright Statement 637 Copyright (C) The Internet Society (2006). This document is subject 638 to the rights, licenses and restrictions contained in BCP 78, and 639 except as set forth therein, the authors retain all their rights.