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

Versions: 00 01 02 03 04 05                                             
Mobile Ad Hoc Networking Working Group                         Minsu Kang
INTERNET DRAFT                                                 Namhi Kang
5 January 2008                                                 Younghan Kim
                                         Ubiquitous Network Research Center
                                             University of Soongsil, Korea


                    Quality of Service Extension to
                Dynamic MANET OnDemand Routing Protocol
                       draft-kang-dymoqos-05.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 January 5, 2008.


Copyright Notice

   Copyright (C) The IETF Trust (2007).



Kang, Kang, Kim          Expires 5 January 2008                 [Page 1]


Internet-Draft            QoS Extension to DYMO           5 January 2008


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 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                                          17
         5.1. QoS Route Discovery                                     17
         5.2. QoS Route Maintenance                                   18
      6. Security Considerations                                      19
      References                                                      20
      Author's Address                                                21
      Full Copyright Statement                                        22
      Intellectual Property                                           22
      Acknowledgment                                                  23

















Kang, Kang, Kim          Expires 5 January 2008                 [Page 2]


Internet-Draft            QoS Extension to DYMO           5 January 2008


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 a Route Request (RREQ) message toward the destination
   node to discover a route to the node.  Once the RREQ message arrives
   at the destination node, it responds a Route Reply (RREP) message
   back to the source node via 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 mainly occurred by the mobility of nodes, 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 (e.g. 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 describes 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.  The extensions
   specified in this document conform to the DYMO routing protocol [1]
   (i.e. the generalized signaling framework specified in [2]).

   In the following, 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, Kang, Kim          Expires 5 January 2008                 [Page 3]


Internet-Draft            QoS Extension to DYMO           5 January 2008


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 also 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 message.

   QoS Route Respond (QRREP)
   The destination generates QRREP to inform the QRREQ generator about a
   route available for the QoS requirements specified in the QRREQ
   message.

   QoS Route Error (QRERR)
   QRERR message 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
   loss probability and routing metric. 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.




Kang, Kang, Kim          Expires 5 January 2008                 [Page 4]


Internet-Draft            QoS Extension to DYMO           5 January 2008


      - End to end jitter is the total summation value of jitter
      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.

      - Routing metric can be any type of metric that nodes can support.

      - In a single hop based wireless networking technologies such as
      WLAN based on 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, Kang, Kim          Expires 5 January 2008                 [Page 5]


Internet-Draft            QoS Extension to DYMO           5 January 2008


3. Routing Table Entry for QoS Routing

      As described in [1], routing table entry is a conceptual data
      structure so that implementer 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, Kang, Kim          Expires 5 January 2008                 [Page 6]


Internet-Draft            QoS Extension to DYMO           5 January 2008


      - 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, Kang, Kim          Expires 5 January 2008                 [Page 7]


Internet-Draft            QoS Extension to DYMO           5 January 2008


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  | Rsv |N|0|0|0|0|           Msg-size            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Hop Limit  |  Hop Count    |     Msg Sequence Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      QoS Route Message Body - Message TLV Block for QoS Request Type
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     msg-tlv-block-size        |  QoSTC-type   |Resv |0|0|1|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Kang, Kang, Kim          Expires 5 January 2008                 [Page 8]


Internet-Draft            QoS Extension to DYMO           5 January 2008


      |     Length    | Traffic class | QosMinBw-type |Resv |0|0|1|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Length     |           QoSParam            | QosMaxDel-type|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Resv |0|0|1|0|0|    Length     |            QoSParam           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | QosMaxJit-type|Resv |0|0|1|0|0|    Length     |   QoSParam    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :     (cont)    |QosMaxLosP-type|Resv |0|0|1|0|0|    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           QoSParam            | QosRMet-type  |Resv |0|0|1|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Length     |  MetricValue  | QosRMet-type  |Resv |0|0|1|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Length     |  MetricValue  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        . . .

      QoS Route Message Body - Address Block
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Number Addrs=2 |  Resv   |0|1|0| HeadLength=3  |     Head      :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :            (cont)             |  Target.Mid   |   Orig.Mid    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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 Block for QoS parameter
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Number Addrs  |  Resv   |0|1|0| HeadLength=3  |     Head      :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :            (cont)             |      Mid1     |      ...      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      MidN     |
      +-+-+-+-+-+-+-+-+

      QoS Route Message Body - Address TLV Block for QoS parameter


Kang, Kang, Kim          Expires 5 January 2008                 [Page 9]


Internet-Draft            QoS Extension to DYMO           5 January 2008


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         tlv-block-size        | QoSstate-type |Resv |M|0|1|0|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       QoS State Value1        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             .....             | QoS State ValueN(if presented)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1. Exemplified QoS Routing Message (QRM)


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



Kang, Kang, Kim          Expires 5 January 2008                [Page 10]


Internet-Draft            QoS Extension to DYMO           5 January 2008


   - msg-header-info
      QRM conforms to the msg-header-info specified in DYMO.

   - msg-tlv (QoSpar tlv)
      This TLV field can be used differently according to the type of
      QRM (i.e. whether it is 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 gathered or updated by intermediate nodes and contained within
      the QoSstate-tlv field during the route discovery process.

      Traffic Class Type (QoSTC-type)

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

                               0
                               0 1 2 3 4 5 6 7 8
                               +-+-+-+-+-+-+-+-+
                               |0 0|   DSCP    |
                               +-+-+-+-+-+-+-+-+
                           Figure 3. Traffic Class


   Minimum Bandwidth Type (QosMinBw-type) This type indicates whether
   the minimum bandwidth is specified as one of the service requirements
   within tlv-value.

   Maximum Delay Type (QosMaxDel-type) This type indicates whether the
   maximum delay (end to end delay) is specified as one of the service
   requirements within tlv-value.

   Maximum Jitter (QosMaxJit-type) This type indicates whether the maxi-
   mum jitter (end to end jitter) is specified as one of the service
   requirements within tlv-value.

   Maximum Loss Probability Type (QosMaxLosP-type) This type indicates
   whether the maximum loss probability (end to end value) is specified


Kang, Kang, Kim          Expires 5 January 2008                [Page 11]


Internet-Draft            QoS Extension to DYMO           5 January 2008


   as one of the service requirements within tlv-value.

   Routing Metric Type (QosRMet-type) This tlv-type is used to specify
   the type and value of routing metrics of a node (i.e. ETX, ETT,
   WCETT) [7].  If an intermediate node along a path to the destination
   can support the metric in the tlv-type, he can update the MetricValue
   field and his routing table. If it is not the case, he simply removes
   the tlv type from msg-tlv.  When target node receives the QRREQ con-
   taining the QosRMet-type field, then the type of routing metric can
   be used since entire intermediate nodes of the path can support the
   routing metric.

   QoS parameter value (QoS Param) 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

   - 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
      Information) tlv.

   - add-block for Qos
      Intermediate nodes along a path to the destination MAY add its
      address or MAY add dummy address block for QoSstate-tlv.  This
      information may be useful for routing [1].



Kang, Kang, Kim          Expires 5 January 2008                [Page 12]


Internet-Draft            QoS Extension to DYMO           5 January 2008


   - add-tlv (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
      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. The QosMDel-type is included in QoSpar-tlv),
      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.
































Kang, Kang, Kim          Expires 5 January 2008                [Page 13]


Internet-Draft            QoS Extension to DYMO           5 January 2008


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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    msg-type   | Rsv |N|0|0|0|0|           Msg-size            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Hop Limit  |  Hop Count    |     Msg Sequence Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      QoS Route Message Body - Message TLV Block
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     msg-tlv-block-size=0      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      QoS Route Message Body - Address Block
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Number Addrs=2 |  Resv   |0|1|0| HeadLength=3  |     Head      :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :            (cont)             |  Target.Mid   |   Orig.Mid    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       . . .

      QoS Route Message Body - Address TLV Block for unsupported QoS



Kang, Kang, Kim          Expires 5 January 2008                [Page 14]


Internet-Draft            QoS Extension to DYMO           5 January 2008


      parameters
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         QUN-tlv-Len           |   QUN-type    |Resv |0|1|0|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Index Start  |     Length    |         UQParam vaule         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   QUN-type    |Resv |0|1|0|0|0|  Index Start  |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         UQParam value         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       . . .

                     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 spec-
   ified in DYMO.

   - add-block entries QRERR contains 1 or more addresses as QoS Unsup-
   ported Node Addresses that is the IP address of the node that cannot
   guarantee QoS any more.

   - add-tlv-block (QUN-tlv) specify unsupported QoS parameters.

   Unsupported QoS Parameter tlv type (QUN-type) The main difference
   between RERR and QRERR is the UQParam (Unsupported 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.

   QoS Parameter Value The QoS Parameter Value field(s) reports the mea-
   sured QoS parameter(s) that fails to meet the originally requested
   QoS.  If a particular node is aware of higher delay than the maximum
   permissible delay, the measured delay is reported to the QoS



Kang, Kang, Kim          Expires 5 January 2008                [Page 15]


Internet-Draft            QoS Extension to DYMO           5 January 2008


   requestor.

   The QRERR message MUST be delivered to all QoS requestors potentially
   affected by the change in the QoS parameter.









































Kang, Kang, Kim          Expires 5 January 2008                [Page 16]


Internet-Draft            QoS Extension to DYMO           5 January 2008


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) back 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.  If resources are enough to support service require-
   ments, the intermediate node updates QoS information that is present
   in the QRREQ message to inform the destination about the current QoS
   states related to the path.

   The QRREQ message 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 about the cur-
   rent network conditions such as delay, jitter, and/or bandwidth to
   discover a proper QoS route.

   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, Kang, Kim          Expires 5 January 2008                [Page 17]


Internet-Draft            QoS Extension to DYMO           5 January 2008


   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 discards the message to
   prevent that unsupported message is not propagated further.

   The MANET-NHDP allows the previous hop to ensure that the link tra-
   versed is not unidirectional [8].  It may be useful to detect a uni-
   directional link(s) along a path in the process of QoS route discov-
   ery.  The existence of a unidirectional link may not be a problem in
   some QoS applications such as one-way streaming services.  However,
   others require fully directional link on the path from a source to
   the destination(s).  Examples include multimedia conferencing, IP
   telephony and most of RTP based QoS applications.  Therefore, 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 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, Kang, Kim          Expires 5 January 2008                [Page 18]


Internet-Draft            QoS Extension to DYMO           5 January 2008


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, Kang, Kim          Expires 5 January 2008                [Page 19]


Internet-Draft            QoS Extension to DYMO           5 January 2008


References


[1]  I. Chakeres and C. Perkins, Dynamic MANET On-demand (DYMO) Routing.
     IETF Internet Draft, May 2007, Work in Progress.


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


[7]  R. Draves, J. Padhye  and B. Zill, "Routing in Multi-Radio, Multi-
     Hop Wireless Mesh Networks", In ACM MobiCom, 2004.


[8]  T. Clausen, C. Dearlove and J. Dean, MANET Neighborhood Discovery
     Protocol (NHDP), IETF Internet Draft, May 2007, Work in Progress.









Kang, Kang, Kim          Expires 5 January 2008                [Page 20]


Internet-Draft            QoS Extension to DYMO           5 January 2008


Author's Addresses

   Questions about this memo can be directed to:

   Minsu 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
   mdkms@dcn.ssu.ac.kr

   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





















Kang, Kang, Kim          Expires 5 January 2008                [Page 21]


Internet-Draft            QoS Extension to DYMO           5 January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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


Intellectual Property

   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
   assurances 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, Kang, Kim          Expires 5 January 2008                [Page 22]


Internet-Draft            QoS Extension to DYMO           5 January 2008


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).









































Kang, Kang, Kim          Expires 5 January 2008                [Page 23]