[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
Mobile Ad Hoc Networking Working Group                         Namhi Kang
INTERNET DRAFT                                               Younghan Kim
25 June 2006                                University of Soongsil, Korea



                    Quality of Service Extension to
                Dynamic MANET OnDemand Routing Protocol
                       draft-kang-dymoqos-02.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.

   Distribution of this memo is unlimited.

   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 December 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).





Kang, Kim               Expires December 24, 2006               [Page 1]


Internet-Draft            QoS Extension to DYMO            25 June 2006


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-
   ipr@ietf.org.




















Kang, Kim               Expires December 24, 2006               [Page 2]


Internet-Draft            QoS Extension to DYMO            25 June 2006


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
   additions to the routing table and DYMO routing messages.


Table of Contents

   Intellectual Property Statement                                     2
   1. Introduction                                                     4
   2. Routing Table Entries for Qos Routing                            5
   3. Extensions to DYMO Routing Message (RM)                          6
      3.1. QoS Routing Message (QRM)                                   6
      3.2. QoS Route Error (QRERR)                                    11
   4. QoS DYMO Operations                                             14
      4.1. QoS Route Discovery                                        14
      4.2. QoS Route Maintenance                                      15
   5. Security Considerations                                         16
   References                                                         17
   Author's Address                                                   18
   Disclaimer of Validity                                             18
   Copyright Statement                                                18

















Kang, Kim               Expires December 24, 2006               [Page 3]


Internet-Draft            QoS Extension to DYMO            25 June 2006


1. Introduction


   The DYMO routing protocol specifies a reactive means to discover 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 of 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.

   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].







Kang, Kim               Expires December 24, 2006               [Page 4]


Internet-Draft            QoS Extension to DYMO            25 June 2006


2. Routing Table Entries for QoS Routing

   In QoS routing, routing table entries 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 is 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.

      - Maximum Tolerable Delay

      - Maximum Tolerable Jitter

      - Minimum Available Bandwidth

      - List of Sources Identifier Requesting Delay Guarantees

      - List of Sources Identifier Requesting Jitter Guarantees

      - List of Sources Identifier Requesting Bandwidth Guarantees,
      where the Source Identifier consists of IPSourceAddress and Port
      number.

   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 is 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].

      - Maximum Tolerable Delay

      - Maximum Tolerable Jitter

      - Minimum Available Bandwidth

      - List of Classes

      - List of Sources Identifier Belonging to Each Class



Kang, Kim               Expires December 24, 2006               [Page 5]


Internet-Draft            QoS Extension to DYMO            25 June 2006


 3. Extensions to DYMO Routing Message (RM)

   In this section, we present two extensions to DYMO routing message to
   discover a QoS route.  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.

3.1 QoS Routing Message (QRM)



    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  QoSMsg-type  |  RSRV |U|N|0|1|           msg-size            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    msg-ttl    |  msg-hopcnt   |      msg-tlv-block-size=0     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Head Length  |             Head              |Number Tails=2 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TailQoSReq  |  TailTarget   |           SEQ-tlv-Len         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |DYMOSEQNUM-type|          TLV Length           |   Orig.SeqNum.:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :.Orig.SeqNum   |         Target.SeqNum         |QoSpar-tlv-Len.:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :.QoSpar-tlv-Len| QoSParam-type | Resv  |M|1|0|0|    TLV Len    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            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 December 24, 2006               [Page 6]


Internet-Draft            QoS Extension to DYMO            25 June 2006


   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.  The QoS requirements of the source
   are specified by means of the QoSpar (QoS parameter) tlv.

      - QRM conforms to the generalized message format.

      - 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
              +-+-+-+-+-+-+-+-+          +-+-+-+-+-+-+-+-+
              |   QoSMsg-type |     =    |M| H |         |
              +-+-+-+-+-+-+-+-+          +-+-+-+-+-+-+-+-+

                           Figure 2. QoSMsg 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.





Kang, Kim               Expires December 24, 2006               [Page 7]


Internet-Draft            QoS Extension to DYMO            25 June 2006


   - add-tlv
      Most of fields conform to the DYMO routing message specified in
      [1] except the newly defined QoSpar tlv and QoSstate (QoS State
      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 routers, 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-



Kang, Kim               Expires December 24, 2006               [Page 8]


Internet-Draft            QoS Extension to DYMO            25 June 2006


      tlv.

      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|R|
                      +-+-+-+-+          +-+-+-+-+

                  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.

      R-bit (R)

      Reserved 1 bit for the future extensions (i.e. for other QoS
      parameters such as power of a node).  Typically, this bit is set
      to zero (0) and ignored in any processing.

      Reserved (Res)




Kang, Kim               Expires December 24, 2006               [Page 9]


Internet-Draft            QoS Extension to DYMO            25 June 2006


      Reserved 2 bits for the future extensions.  Typically, these bits
      are set to zero (0) and ignored in any processing.  In addition to
      these 2 bits, there exists one more reserved bit described above
      (in QoS PM field).  These three reserved bits are conceptually
      distinguished in order to support easy to implement, i.e. byte-
      oriented allocation of variable in conventional programming lan-
      guage 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)

   - QoSstate-tlv

      QRM conveys QoS State information for each address within
      QoSstate-tlv. In QoS routing, intermediate nodes along a path to
      the destination should inform the destination about its current
      state of resources in order that the destination is able to decide



Kang, Kim               Expires December 24, 2006              [Page 10]


Internet-Draft            QoS Extension to DYMO            25 June 2006


      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.


3.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |qrerr-msg-type |  RSRV |U|N|0|1|           msg-size            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    msg-ttl    |  msg-hopcnt   |      msg-tlv-block-size=0     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Head Length  |             Head              |Number Tails=1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Tail1     |       tlv-block-size          |dymo-seqnum-typ|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          TLV Length           |          Tail1.SeqNum         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         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.



Kang, Kim               Expires December 24, 2006              [Page 11]


Internet-Draft            QoS Extension to DYMO            25 June 2006


   - 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
      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




Kang, Kim               Expires December 24, 2006              [Page 12]


Internet-Draft            QoS Extension to DYMO            25 June 2006


   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 parame-
      ter(s) that fails to meet the originally requested QoS.  If a par-
      ticular node is aware of higher delay than the maximum permissible
      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 December 24, 2006              [Page 13]


Internet-Draft            QoS Extension to DYMO            25 June 2006


4. QoS DYMO Operations

4.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 QoSstate
   is always bigger than the minimum value that the QoS requestor requi-
   res.  If it is not the case, a node MUST drop the QRREQ message since



Kang, Kim               Expires December 24, 2006              [Page 14]


Internet-Draft            QoS Extension to DYMO            25 June 2006


   there is not enough bandwidth to guarantee the required one.  Such a
   way allows the QoS requestor to be able to increase the minimum band-
   width 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.

4.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 December 24, 2006              [Page 15]


Internet-Draft            QoS Extension to DYMO            25 June 2006


5. 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 December 24, 2006              [Page 16]


Internet-Draft            QoS Extension to DYMO            25 June 2006


References


[1]  I. Chakeres, E. Belding-Royer and C. Perkins, Dynamic MANET On-
     demand (DYMO) Routing. IETF Internet Draft, June 2005, Work in
     Progress.


[2]  Clausen, T., Dearlove, C. and J. Dean, Generalized MANET
     Packet/Message Format, IETF Internet Draft, June 2005, 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 December 24, 2006              [Page 17]


Internet-Draft            QoS Extension to DYMO            25 June 2006


Author's Addresses

   Questions about this memo can be directed to:

   Namhi Kang
   UNRC, Soongsil University in Seoul
   424 Hyungnam Engineering Bldg. 317, Sangdo-Dong,
   Dongjak-Gu, Seoul 156-743
   Korea
   +82 2 820 0841
   nalnal@dcn.ssu.ac.kr

   Younghan Kim
   DCN, Soongsil University in Seoul
   1104 Hyungnam Engineering Bldg. 317, Sangdo-Dong,
   Dongjak-Gu, Seoul 156-743
   Korea
   +82 2 820 0904
   yhkim@dcn.ssu.ac.kr



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 AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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.





Kang, Kim               Expires December 24, 2006              [Page 18]