Mobile Ad Hoc Networking Working Group Namhi Kang INTERNET DRAFT Younghan Kim 3 March 2007 Ubiquitous Network Research Center University of Soongsil, Korea Quality of Service Extension to Dynamic MANET OnDemand Routing Protocol draft-kang-dymoqos-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Kang, Kim Expires 2 September 2007 [Page 1]
Internet-Draft QoS Extension to DYMO 3 March 2007 Abstract This document describes extensions to the Dynamic MANET On-demand (DYMO) routing protocol in order to enable mobile nodes to discover and maintain QoS routes. DYMO is a reactive (on-demand) routing protocol designed for use by mobile nodes in multi-hop wireless ad hoc networks. Extensions of this document include the necessary entries to the routing table and DYMO routing messages. Table of Contents 1. Introduction 3 2. Terminology 4 3. Routing Table Entries for Qos Routing 6 4. Extensions to DYMO Message Elements 8 4.1. QoS Routing Element (QRE) 8 4.2. QoS Route Error (QERR) 14 5. QoS DYMO Operations 18 5.1. QoS Route Discovery 18 5.2. QoS Route Maintenance 19 6. Security Considerations 20 References 21 Author's Address 22 Intellectual Property Statement 22 Disclaimer of Validity 23 Copyright Statement 23 Acknowledgment 23 Kang, Kim Expires 2 September 2007 [Page 2]
Internet-Draft QoS Extension to DYMO 3 March 2007 1. Introduction The DYMO routing protocol specifies a reactive means to discover and maintain a route to the destination for MANET nodes. A source node disseminates RREQ message toward the destination node to discover a route to the node. Once the RREQ message arrives at the destination node, it responds RREP message back to the source node over the discovered path by unicasting. During such a route discovery process, intermediate nodes (i.e. nodes that relay the RREQ and RREP message) update its routing table based on the routing information that is present in those two messages for each direction. DYMO also offers adaptation to changes in network topology, which can be occurred by the mobility of nodes as the main cause, by means of the route maintenance mechanisms [1]. In order to provide MANET nodes with QoS routes, extensions to DYMO routing messages are required. These extensions specify the service requirements (say maximum tolerable delay, maximum tolerable jitter, and/or minimum bandwidth limitation) that must be guaranteed by nodes along a route from a source to the destination. This document presents which extensions are required for support QoS in routing, how service guarantees are achieved by using the defined extensions without high impacts on the existing DYMO operations and how QoS routes are discovered and maintained are also briefly described. The extensions specified in this document conform to the DYMO routing protocol [1] (i.e. the generalized signaling framework specified in [2]). In this document, the extension to routing table is first described and then two routing message extensions, QoS Route Message (QRM) and QoS Route Error (QRERR), are presented for supporting QoS routing. Kang, Kim Expires 2 September 2007 [Page 3]
Internet-Draft QoS Extension to DYMO 3 March 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. The basic terminology defined in [1] is used in this document. In addition, the following terminology is used. Source Identifier (SRC ID) SRC ID consists of IPSourceAddress and Port number. QoS Routing Message (QRM) QRM is an extension to the DYMO Routing Message (RM) to support QoS routing. QoS Route Request (QRREQ) A source node, which is intended to discover a QoS enabled route to a corresponding destination, generates and broadcasts a QRREQ. QoS Route Respond (QRREP) The destination generates QRREP to inform the QRREQ generator about a route available for the QoS requirements specified in QRREQ. QoS Route Error (QRERR) QRERR is used to allow a node to figure out that one or more routes to destinations are not available. QoS Parameter (QP) QoS parameter generally includes bandwidth, end to end delay, jitter and loss probability. Additional parameters may also be defined if required, for example channel assignment. Each of the parameters for a route is considered as follows. - Bandwidth of a route is the minimum value from all values of intermediate links from source to destination. - End to end delay is the total summation value of delay introduced by each of intermediate nodes between source and destination pairs. - End to end jitter is the total summation value of jitter Kang, Kim Expires 2 September 2007 [Page 4]
Internet-Draft QoS Extension to DYMO 3 March 2007 experienced at each of intermediate nodes between source and destination pairs. - End to end loss probability is the multiplicative value of loss probability expected at each of intermediate nodes between source and destination pairs. - In a single hop based wireless networking technologies such as IEEE 802.11b, multiple channels have already been used to reduce interference between node and access point. Such a property can also be applied to multi-hop ad-hoc networks, thereby enhancing performance in terms of QoS. Kang, Kim Expires 2 September 2007 [Page 5]
Internet-Draft QoS Extension to DYMO 3 March 2007 3. Routing Table Entries for QoS Routing As described in [1], routing table entry is a conceptual data structure so that implementor can use an internal representation. In addition to the entries specified in [1], conceptual entries indicating and managing QoS requirements are required. In QoS routing, routing table entry can be defined differently according to the type of QoS model; per-flow based model (say IntServ model [4]) or per-class based model (say DiffServ model [5]). In case of the per-flow based mechanism, the following entries MAY be added to the routing table of each DYMO router on the path. A routing table entry SHOULD be defined for each flow to specify QoS requirements requested by the source (requestor) of the particular flow, where a flow can be identified by the pair of IP address and port number (i.e. SRC ID). - Minimum Available Bandwidth - Maximum Tolerable Delay - Maximum Tolerable Jitter - Maximum Tolerable Loss Probability - List of Sources Identifier Requesting Bandwidth Guarantees - List of Sources Identifier Requesting Delay Guarantees - List of Sources Identifier Requesting Jitter Guarantees - List of Sources Identifier Requesting Loss Probability Guarantees In case of the class-based model, on the other hand, the following fields may be added to the routing table of a DYMO router. Each routing table entry SHOULD be defined for each pre-specified class, where a packet belonging to each class can be distinguished by DSCP (DiffServ Code Point) as specified in [6]. Kang, Kim Expires 2 September 2007 [Page 6]
Internet-Draft QoS Extension to DYMO 3 March 2007 - Minimum Available Bandwidth - Maximum Tolerable Delay - Maximum Tolerable Jitter - Maximum Tolerable Loss Probability - List of Classes - List of Sources Identifier belonging to each of the Classes Kang, Kim Expires 2 September 2007 [Page 7]
Internet-Draft QoS Extension to DYMO 3 March 2007 4. Extensions to DYMO Routing Message (RM) In DYMO specification, there are two routing messages: RREQ and RREP. This section therefore presents two extensions to the DYMO RM to discover a QoS route: QRREQ and QRREP. The work especially considers the compact representation for use by mobile nodes in using of limited capacity, the future extensions for covering various QoS parameters and the support of the per-flow based mechanism and the per-class based mechanism as well. 4.1 QoS Routing Message (QRM) QoS Routing Message (QRM) is an extension to the DYMO Routing Message (RM) in order to enable a source to discover a path that is able to guarantee the QoS requirements. 0 1 2 3 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 IP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP.DestinationAddress=LL_ALL_MANET_ROUTERS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Port=TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QoS Route Message Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoSMsg-type | RSRV |N|0|0| Msg-size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | Msg Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QoS Route Message Body - Message TLV Block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kang, Kim Expires 2 September 2007 [Page 8]
Internet-Draft QoS Extension to DYMO 3 March 2007 | msg-tlv-block-size=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . QoS Route Message Body - Address Block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Number Addrs=2 |0|HeadLength=3 | Head : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (cont) | Target.Tail | Orig.Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QoS Route Message Body - Address TLV Block for Sequence Number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tlv-block-size=6 |DYMOSeqNum-type|Resv |0|1|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=1 | tlv-length=2 | Orig.SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . QoS Route Message Body - Address TLV Block for QoS parameter +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tlv-block-size=25 | QoSpar-type |Resv |0|0|0|1|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=1 | Index-start=2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS PI | QoSParam1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoSParam2 (if presented) | QoSParamN (if presented) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoSstate-tlv-Len | QoSstate-type | Resv |M|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Len | QoS State Value1 |QoS State Val2.: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :(if presented) | QoS State ValueN(if presented)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Exemplified QoS Routing Message (QRM) Kang, Kim Expires 2 September 2007 [Page 9]
Internet-Draft QoS Extension to DYMO 3 March 2007 The QoS requirements of the source are specified by means of the QoSpar (QoS parameter) tlv. - QRM conforms to the generalized message format defined in [2]. - msg-type = DYMO-QRREQ or DYMO-QRREP The Type field identifies that this element is QRE (i.e. either DYMO-QRREQ or DYMO-QRREP). The field also specifies how the QRE is handled in case where nodes do not implement or under- stand such QoS extensions. The data structure of the Type is as follows. 0 0 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | Type | = |M| H | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Figure 2. Type In QRE, M bit MUST be set to one (1) in order to indicate that QRE requires notification via an UERR when QRE is not understood or handled by a node on the path. Therefore QRE MUST convey Noti- fyAddress field to which UERR is sent. As well as the H bits in the Type field MUST set to (11) in order to force a node which does not support QRE to drop the QRE packet without processing any other QoS DYMO elements. - msg-semantics QRM conforms to the msg-semantics specified in DYMO. - msg-header-info QRM conforms to the msg-header-info specified in DYMO. - add-block entries QRM conforms to the add-block entries specified in DYMO. - add-tlv Most of fields conform to the DYMO routing message specified in [1] except the newly defined QoSpar tlv and QoSstate (QoS State Kang, Kim Expires 2 September 2007 [Page 10]
Internet-Draft QoS Extension to DYMO 3 March 2007 Information) tlv. - QoSpar tlv This TLV field can be used differently according to the type of QRM (i.e. whether a route request or a route reply element with QoS extensions). In QRREQ message, on one hand, the QoSpar tlv indicates the service requirements that must be met at nodes along a route to the destination. On the other hand, in QRREP message, the destination uses this field to inform the route's resources available for the QoS requestor. The route's resources are gath- ered or updated by intermediate nodes and contained within the QoSstate-tlv field during the route discovery process. The data structure of QoS Parameter Indicator (QoS PI) is described in Fig- ure 3. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|QPCnt|QoS PM |Res|Traffic Cls| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. QoS PI U-bit (U) 1-bit selector to indicate whether the route discovery process to be continued. If S bit is available at DYMO router, this bit is coupled with the S bit. If S-bit is set to one (1) in the QRE, then a reporting message SHOULD be sent to the previous hop within UNICAST_MESSAGE_SENT_TIMEOUT. At this time the two nodes (i.e. previous hop and QRE receiver) can detect whether the link between two nodes is bidirectional or unidirectional. If U-bit is also set to one (1) and the link is unidirectional, then the QRE receiver is forced to stop the route discovery process. QoS Parameter Count (QPCnt) The most significant 3 bits, QPCnt bits, indicate the number of QoS parameters being presented within the value field of QoSpar- tlv. Kang, Kim Expires 2 September 2007 [Page 11]
Internet-Draft QoS Extension to DYMO 3 March 2007 QoS Parameter Mark (QoS PM) The 4 bits marker of QoS PM field specifies which parameter is present in QoSpar-tlv to specify the service requirements. This field consists of the following bit marker. 0 0 4 5 6 7 8 4 5 6 7 8 +-+-+-+-+ +-+-+-+-+ |QoS PM | = |B|D|J|L| +-+-+-+-+ +-+-+-+-+ Figure 4. QoS Parameter Marker (QoS PM) B-bit (B) 1-bit marker to indicate whether the minimum bandwidth is speci- fied as one of the service requirements within QoSpar-tlv. D-bit (D) 1-bit marker to indicate whether the maximum delay (end to end delay) is specified as one of the service requirements within QoSpar-tlv. J-bit (J) 1-bit marker to indicate whether the maximum jitter (end to end jitter) is specified as one of the service requirements within QoSpar-tlv. L-bit (L) 1-bit marker to indicate whether the maximum loss probability (end to end value) is specified as one of the service requirements within QoSpar-tlv. Reserved (Res) Reserved 2 bits for the future extensions (i.e. for other QoS parameters such as power of a node or assigned channel). Typically, Kang, Kim Expires 2 September 2007 [Page 12]
Internet-Draft QoS Extension to DYMO 3 March 2007 these bits are set to zero (0) and ignored in any processing. These three reserved bits are funtionally equivalent to QoS PM field but are conceptually distinguished from QoS PM field in order to support easy to implement, i.e. byte- oriented allocation of variable in conventional programming language such as C. Traffic Class (Traffic Cls) The Traffic Cls field allows mobile nodes to employ the per-class based mechanism (say DiffServ). This field is specified by using 6-bits code, called DSCP (Differentiated Services Code Points) that indicate a particular class [5]. QoS parameter value (QoS Param) The number and the type of QoS parameters depend on the QoS PI (Parameter Indicator) value. If B and D bit are set to one (1), for example, there MUST exist two parameter value fields so that the padding field does not needed. QoS Param Value fields are defined as follows. - Minimum Bandwidth Requirement 16-bit number, measured in kbits/second (kbps). The maximum value is about 131 Mbps (2^17 - 1 kbps). If the required band- width is less than 1kbps, the value is set to one (1). That is, the least bandwidth requirement the source requires is 1 Kbps. - Maximum End to End Delay Requirement 16-bit number, measured in milliseconds (ms) - Maximum End to End Jitter Requirement 16-bit number, measured in milliseconds (ms) - Maximum End to End Loss Probability Requirement 16-bit number, expressed in percentage - QoSstate-tlv QRM conveys QoS State information for each address within QoSstate-tlv. In QoS routing, intermediate nodes along a path to Kang, Kim Expires 2 September 2007 [Page 13]
Internet-Draft QoS Extension to DYMO 3 March 2007 the destination should inform the destination about its current state of resources in order that the destination is able to decide the optimal route among route candidates. The number and the type of QoS State Values depend on the QoSpar- tlv. For example, if a source specifies a delay parameter as a QoS requirement (i.e. D bit in QoS PM field is set to one (1)), there MUST exist a QoS state value for presenting a delay value on candidate paths. In this case, all intermediate nodes MUST accu- mulate its measured delay. 4.2 QoS Route Error (QRERR) QoS Route Error (QRERR) is an extension to the DYMO RERR message. QRERR message element is generated when an intermediate node realizes a lack of capability to maintain the QoS guarantees for a specific route. The data structure of this element is as follows. 0 1 2 3 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 Packet Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QoS Route Message Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |qrerr-msg-type | RSRV |N|0|0| Msg-size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | Msg Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QoS Route Message Body - Message TLV Block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kang, Kim Expires 2 September 2007 [Page 14]
Internet-Draft QoS Extension to DYMO 3 March 2007 | msg-tlv-block-size=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QoS Route Message Body - Address Block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Number Addrs=2 |0|HeadLength=3 | Head : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (cont) | Target.Tail | Orig.Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ QoS Route Message Body - Address TLV Block for Sequence Number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tlv-block-size=6 |DYMOSeqNum-type|Resv |0|1|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index-start=1 | tlv-length=2 | Orig.SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . QoS Route Message Body - Address TLV Block for unsupported QoS parameters +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUN-tlv-Len | QUN-type | Resv |M|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Len | UQParam1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UQParamN (if presented) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. QoS Route Error (QRERR) - QRERR conforms to the generalized message format. - msg-type = DYMO-QRERR - msg-semantics QRERR conforms to the msg-semantics of RERR specified in DYMO. - msg-header-info QRERR conforms to the msg-header-info of RERR specified in DYMO. - add-block entries Kang, Kim Expires 2 September 2007 [Page 15]
Internet-Draft QoS Extension to DYMO 3 March 2007 QRERR contains 1 or more addresses as QoS Unsupported Node Addresses that is the IP address of the node that cannot guarantee QoS any more. - add-tlv QRERR contains the sequence number of the node that cannot guaran- tee QoS, if known; otherwise this field set to zero (0) in a DYMO Sequence Number tlv. - QUN-tlv QUN-tlv specify unsupported QoS parameters. Unsupported QoS Parameter (UQParam) The main difference between RERR and QRERR is the UQParam (Unsup- ported QoS Parameter) field which is used to inform the QoS requestor about which QoS parameter is no longer available for the originally specified QoS requirements. Once the QoS requestor receives the QRERR, it re-builds a QoS route process based on the unavailable QoS parameters if it still has packets to deliver. This field is illustrated in figure 6. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QPCnt| QoS PM |Res|Traffic Cls| QoS Param Value 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QoS Param Value N(if presented)| Padding Bits (if needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. UQParam field All fields are equivalent to the fields of QoSpar-tlv in the QRM mes- sage element but differently used. QoS PCnt indicates the number of scarce resource and each of their kinds are marked in QoS PM filed to identify the next fields (i.e. which parameter(s) is (are) present in UQParam field). QoS Parameter Value The QoS Parameter Value field(s) reports the measured QoS Kang, Kim Expires 2 September 2007 [Page 16]
Internet-Draft QoS Extension to DYMO 3 March 2007 parameter(s) that fails to meet the originally requested QoS. If a particular node is aware of higher delay than the maximum per- missible delay, the measured delay is reported to the QoS requestor. The QRERR message MUST be delivered to all QoS requestors potentially affected by the change in the QoS parameter. Kang, Kim Expires 2 September 2007 [Page 17]
Internet-Draft QoS Extension to DYMO 3 March 2007 5. QoS DYMO Operations 5.1 QoS Route Discovery Like DYMO routing procedures, a QoS route is also discovered by means of two way handshaking consisting of a route request and route reply cycle. Instead of DYMO RREQ, the source (QoS requestor) disseminates QRREQ (RREQ with a QoS extension) to the destination. QRREQ message elements therefore should contain required QoS parameters as well as the QoS reporting information on the path that the message has been experienced. Thereafter, the destination node decides a correct route that can meet the QoS requirements and then sends QRREP (RREP with a QoS extension) to the source. Ahead of re-broadcasting a QRREQ message by an intermediate node, the node must check its resources whether it is available for the QoS requirements contained within the QRREQ message during the route dis- covery process. Thereafter, if resources are enough to meet service requirements, the intermediate node updates QoS information that is present in the QRREQ message to inform the destination about the cur- rent QoS states related to the path. That is, QRREQ should contain two different fields. One is used to specify the QoS requirements of the source (i.e. QoS requestor) that must be met at nodes through the path. The other field is used to inform both the QoS requestor and the destination that selects a proper QoS route the current network conditions such as delay, jit- ter, and/or bandwidth. In case of delay and jitter, intermediate nodes accumulate each of their measured delay and jitter value to the corresponding value of the received QRREQ message. For this reason, the destination can be aware of the end to end delay and jitter along the path. In case of bandwidth (i.e. capacity to transmit), the node compares its measured value with the value of QoSstate in the received QRREQ message. If the measured value is smaller than the value of the mes- sage, the field is updated to the measured one. This field allows the destination to be aware of the actual minimum bandwidth over a route from the source to the destination since the value of QSIB is always bigger than the minimum value that the QoS requestor requires. If it is not the case, a node MUST drop the QRREQ message since there Kang, Kim Expires 2 September 2007 [Page 18]
Internet-Draft QoS Extension to DYMO 3 March 2007 is not enough bandwidth to guarantee the required one. Such a way allows the QoS requestor to be able to increase the minimum bandwidth requirement according to the network condition dynamically. In QoS enabled DYMO, M-bit MUST be set to one (1) and H-bits MUST be set to (11). Therefore, if the QoS extended element is not supported or handled by the processing node, the node MUST send a UERR to the NotifyAddress (QoS requestor) and drop the message to prevent that unsupported message is not propagated further. In DYMO, I bit of RE message indicates whether the element has been ignored by some intermediate nodes. Therefore, in QoS DYMO, if the I bit is (1), the QRM message MUST be dropped. The recent revision of DYMO specifies S-bit to allow the previous hop to ensure that the link traversed in not unidirectional. It may be useful to detect a unidirectional link(s) along a path in the process of QoS route discovery. The existence of a unidirectional link may not be a problem in some QoS applications such as stock quote stream- ing. However, others require fully directional link on the path from a source to the destination(s). Examples include multimedia confer- encing, IP telephony and most of RTP based QoS applications. There- fore, it is necessary to inform how each of cases is handled at nodes along path. When a node ensures the link is unidirectional then the node performs the route discovery process based on the U-bit coupled with S-bit. If U-bit and S-bit in QRM are both set to one (1), then the QRM receiver is forced to stop the route discovery process. 5.2 QoS Route Maintenance In order to react to changes in the network resources, nodes monitor their links under the aspect of QoS. When a node is aware of the fact that resources of its link is no longer available for the QoS requestor, a QoS-Route Error (QRERR) is sent to the QoS requestor to inform the current unavailable QoS parameters of the route. Once the requestor receives the QRERR, it re-builds a QoS route process based on the unavailable QoS parameters if it still has packets to deliver. Kang, Kim Expires 2 September 2007 [Page 19]
Internet-Draft QoS Extension to DYMO 3 March 2007 6. Security Considerations This document does not discuss any special security concerns in detail. The protocol of this document is built on the assumption that all participating nodes are trusted each other as well as there is no adversary who modifies/injects false route elements to corrupt the QoS routes. However, support of secure routing protocol is prerequisite for launching a secure communication in the presence of adversaries. In such an environment, most of all MANET routing protocols including DYMO are vulnerable to many kinds of attacks. It is fairly easy to inject fake routing messages or modify legitimate ones so that net- work operation would be heavily disturbed (e.g., by creating loops or disconnecting the network). Therefore, it is necessary to find a means to authenticate/verify control messages to discover and main- tain a proper route. Especially, QRM message MUST be authenticated to enable nodes participating in QoS DYMO routing protocol to assure the origin of the QRM message. Kang, Kim Expires 2 September 2007 [Page 20]
Internet-Draft QoS Extension to DYMO 3 March 2007 References [1] I. Chakeres and C. Perkins, Dynamic MANET On-demand (DYMO) Routing. IETF Internet Draft, February 2007, Work in Progress. [2] Clausen, T., Dearlove, J. Dean and C. Adjih, Generalized MANET Packet/Message Format, IETF Internet Draft, January 2007, Work in Progress. [3] S. Bradner, Key words for use in RFCs to Indicate Requirement Lev- els, Internet RFC 2119, March 1997. [4] R. Braden, D. Clark and S. Shenker, Integrated Services in the Internet Architecture: an Overview, Internet RFC 1633, June 1994. [5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An Architecture for Differentiated Services Internet RFC 2475, December 1998. [6] Nichols, K., Blake, S., Baker, F. and D. Black. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Head- ers, Internet RFC 2474, December 1998. Kang, Kim Expires 2 September 2007 [Page 21]
Internet-Draft QoS Extension to DYMO 3 March 2007 Author's Addresses Questions about this memo can be directed to: Namhi Kang Ubiquitous Network Research Center 4F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, University of Soongsil, Seoul 156-743 Korea +82 2 820 0841 nalnal@dcn.ssu.ac.kr Younghan Kim University of Soongsil in Seoul 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, Seoul 156-743 Korea +82 2 820 0904 yhkim@dcn.ssu.ac.kr Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assur- ances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- Kang, Kim Expires 2 September 2007 [Page 22]
Internet-Draft QoS Extension to DYMO 3 March 2007 ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kang, Kim Expires 2 September 2007 [Page 23]