[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

IETF MANET Working Group                                       N. Kettaf
Internet-Draft                                              H. Abouaissa
Expires: April 14, 2008                                             MIPS
                                                             T. Vu Duong
                                                      France Telecom R&D
                                                               P. Lorenz
                                                                    MIPS
                                                        October 12, 2007


           Admission Control enabled On demand Routing (ACOR)
                     draft-kettaf-manet-acor-03.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 April 14, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).










Kettaf, et al.           Expires April 14, 2008                 [Page 1]

Internet-Draft                    ACOR                      October 2007


Abstract

   The Admission Control enabled On-demand Routing (ACOR) protocol is
   intended for use by MANETs.  It is a reactive routing protocol
   designed to support quality of service (QoS) on the end to end route.
   ACOR is based on simple local cost functions at each node, and global
   cost function to represent the end-to-end cost of a route, in
   addition to a simple admission control mechanism for implicit
   resource reservation adapted to frequent changing of network
   topology.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Quality of Service Overview  . . . . . . . . . . . . . . . . .  4
   3.  ACOR's Cost functions  . . . . . . . . . . . . . . . . . . . .  6
   4.  ACOR Terminology . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Conceptual Data Structures and Messages  . . . . . . . . . . . 10
     5.1.  Route table entry  . . . . . . . . . . . . . . . . . . . . 10
     5.2.  ACOR packets formats . . . . . . . . . . . . . . . . . . . 10
       5.2.1.  RouteRequest packet  . . . . . . . . . . . . . . . . . 10
       5.2.2.  RouteReply packet  . . . . . . . . . . . . . . . . . . 11
       5.2.3.  RouteError packet  . . . . . . . . . . . . . . . . . . 13
       5.2.4.  Hello packet . . . . . . . . . . . . . . . . . . . . . 14
   6.  ACOR Operation . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  Generating and forwarding route requests . . . . . . . . . 15
     6.2.  Generating route replies . . . . . . . . . . . . . . . . . 16
     6.3.  Generating route errors  . . . . . . . . . . . . . . . . . 17
     6.4.  Generating Hello messages  . . . . . . . . . . . . . . . . 17
   7.  Protocol parameters values . . . . . . . . . . . . . . . . . . 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 24















Kettaf, et al.           Expires April 14, 2008                 [Page 2]

Internet-Draft                    ACOR                      October 2007


1.  Introduction

   The Admission Control enabled On-demand Routing (ACOR) protocol
   enables quality of service (QoS) support.  Without maintaining up-to-
   date any routing information and exchanging any routing table
   periodically, or introducing out weighting signaling functions, a
   route with QoS requirements is created on-demand.  When a source node
   needs a route, it broadcasts a RouteRequest packet towards the
   destination.  Once, the destination is achieved it responds by
   unicasting a RouteReply packet to the source node.  To provide
   quality of service, ACOR is based on simple and efficient techniques.
   In essence, at each node, a QoS parameter is represented by a local
   cost function.  Hence, each node receives the route request packet
   that transports global cost function and respects to the requested
   QoS; it implicitly reserves the requested resources, and then appends
   its local cost function to the global function before forwarding it.
   The global function will be accumulated along the route from the
   source to the destination to represent the end-to-end route quality.
   Then, the end-to-end value of the global cost function is recorded
   and sent back in the RouteReply packet towards the source node.  When
   the source node receives the route reply packet it chooses the route
   with respect to the best value of the global cost function.





























Kettaf, et al.           Expires April 14, 2008                 [Page 3]

Internet-Draft                    ACOR                      October 2007


2.  Quality of Service Overview

   The Admission Control enabled On-demand Routing (ACOR) is a reactive
   protocol designed to discover and maintain end-to-end QoS routes in
   mobile ad hoc networks.  ACOR is distinguished by using new efficient
   and simple mechanisms adapted to limited resources and frequent
   topology changes of MANETs.  These mechanisms are novel cost
   functions to represent QoS routes and admission control to implicitly
   reserve resources for real-time and multimedia applications.

   To satisfy required QoS by an application, the ACOR's source node
   disseminates throughout the network a RouteRequest message to find
   and maintain a QoS route to the destination.  The RouteRequest
   includes the required QoS parameters as B for bandwidth, D for delay
   and E for energy and so on, in addition to a global cost function
   called Fg to represent the route quality, where a high value of Fg
   represents an overloaded (high traffic) route.  However, Fg is
   numerical results from the accumulated values of the addition, at
   every participating node, of elementary local cost functions called
   Fb for bandwidth and Fd for delay or Fe for the need of energy along
   the route (from source to destination).  For more clarity in this
   draft, we only focus on bandwidth and delay as QoS parameters.  The
   elementary cost functions are computed locally at each node to
   represent available estimated resources.  Specifically, Fb is a
   fraction of required bandwidth B by an application to the supported
   bandwidth by a link Bmax and the residual bandwidth Bres.  On the
   other hand, Fd is also a fraction of supported delay D by an
   application to the accumulated hop-by-hop delays from the source node
   and the upper bound of delay Dmax (for details see section 2).  In
   particular, the elementary functions Fb and Fd are hyperbolic moving
   towards the asymptotes that are parallel to the ordinate axis
   represented by Bmax and Dmax.  At each node, achieving the maximum
   values Bmax or Dmax represents an overloaded node (with high
   traffic).

   therefore, each node other than the destination receiving a non-
   duplicate RouteRequest, respecting QoS requirements and desiring to
   participate to build a route, updates the value of Fg by appending
   the local values of the estimated Fb and Fd, applies the admission
   control to implicitly reserve requested resources and forwards the
   RouteRequest message toward other neighbors.  Once, the destination
   node is reached it replies by unicasting a RouteReply message which
   includes the value of the global cost function Fg toward the source
   node.  When the source node receives the RouteReply message, route in
   both directions has been built between the source-destination pair.
   Therefore, the source node chooses the route with respect to the best
   value of received Fg in the RouteReply message.




Kettaf, et al.           Expires April 14, 2008                 [Page 4]

Internet-Draft                    ACOR                      October 2007


   To prevent unnecessary resources reservation, the other nodes which
   applied admission control to reserve resources during the route
   discovery and were not explored for a route, they release their
   resources after a Lifetime.  To respond to link breakage and network
   topology changes, ACOR adopts the most common approach for route
   break detection.  If data is flowing and a neighbor lost is detected,
   a RouteError (RouteError) message is sent to the source of data.
   During the propagation of the RouteError towards the source node,
   each intermediate node invalidates routes to any unreachable
   destinations.  Then the source node initiates the reroute process if
   it still has packets to deliver.  However, to avoid free loops, ACOR
   uses sequence number approach [1].

   Routing with multiple parameters is a NP-complete problem [2];
   however, to solve it, ACOR may adopt the Lagrange relaxation
   technique for multi-constrained route with additive and concave
   metrics.

   ACOR specification uses conventional meanings [3] for capitalized
   words such as SHOULD, MAY, etc., to indicate requirement levels for
   various protocol features.






























Kettaf, et al.           Expires April 14, 2008                 [Page 5]

Internet-Draft                    ACOR                      October 2007


3.  ACOR's Cost functions

   To provide QoS routes, ACOR is distinguished by the introduction of
   simple local and global cost functions.  The local cost functions
   represent, at each node, the QoS metrics as Fb for bandwidth, Fd for
   delay, Fe for the need of energy and so on.  In this draft, we only
   focus on bandwidth and delay as QoS metrics.  Thus, the local cost
   function Fb is the ratio of the requested bandwidth B by an
   application to the supported bandwidth by a link Bmax (i. e., 2Mb/s,
   11Mb/s, etc.) and the residual bandwidth noted Bres.

                      B
              Fb = -------------------
                     Bmax - (Bres + B)

   To admit the requested bandwidth B, the inequality (Bres + B < Bmax)
   must be verified.

   On the other hand, Fd is also the ratio between the requested delay D
   by an application and the maximum tolerable delay Dmax in addition to
   the accumulated hop-by-hop delays represented by sumDi.

                       D
              Fd = ---------------------
                    Dmax - (sumDi + D)

   Also, the inequality ( sumDi + D < Dmax) must be verified to respond
   to a requested delay D.

   Specifically, the local cost functions are hyperbolic limited by Bmax
   and Dmax which are parallel to the ordinate.

   Furthermore, the end-to-end cost of a route is represented by a
   global cost function called Fg that results from the sum of local
   cost functions Fb and Fd evaluated at each node participating in the
   route discovery.

                             B                         D
           Fg = Fb + Fd = ------------------- +  ---------------------
                          Bmax - (Bres + B)        Dmax - (sumDi + D)


   The global cost function Fg MAY result from the summation of other
   QoS metrics like Fe which will be defined in future versions, then
   Fg= Fb+Fd+Fe along the route discovery.

   As Fg will represent the route's quality, its value is accumulated
   hop-by-hop from source where is set to cipher to destination.  In



Kettaf, et al.           Expires April 14, 2008                 [Page 6]

Internet-Draft                    ACOR                      October 2007


   particular, a high value of Fg represents an overloaded route.


















































Kettaf, et al.           Expires April 14, 2008                 [Page 7]

Internet-Draft                    ACOR                      October 2007


4.  ACOR Terminology

   -node

   A router that implements ACOR

   -source node

   The source of a packet, identified by the IP address.

   -destination node

   The destination of a packet, identified by the IP address.

   -elementary cost function

   An elementary cost function is the local representation of a QoS
   parameter; for example bandwidth is represented by Fb and delay by
   Fd.

   -global cost function Fg

   A global cost function is affected by the sum of the elementary cost
   functions accumulated at each intermediate node along the route.  At
   the source node Fg is null, however, its value could be increased
   during the route discovery to represent the end-to-end cost of a
   route.

   Note that a high value of Fg represents an overloaded (with dense
   traffic) route.

   -Route Request (RouteRequest)

   To discover a route from source to destination, the source node
   disseminates to all neighbors a RouteRequest which carries the global
   cost function Fg.

   -Route Reply (RouteReply)

   Once the destination node receives the RouteRequest message, it
   responds by unicasting the RouteReply towards the destination.  The
   RouteReply transports the accumulated value of Fg from source to
   destination node.

   -Route Error (RouteError)

   When a link break causes one or a set of destinations becomes
   unreachable, a RouteError message is generated and sent back to the



Kettaf, et al.           Expires April 14, 2008                 [Page 8]

Internet-Draft                    ACOR                      October 2007


   source node.

   -ACOR Sequence Number

   To ensure loop freedom, the Sequence Number is maintained by ACOR's
   nodes.

   -admission control

   At each node, the admission control is responsible for admitting or
   refusing requests aiming to allocate available resources to data
   flows or classes.  If requested resources are available, a node
   implicitly reserves them and updates the values of local cost
   functions, e.g.: resedual bandwidth Bres decreases.

   -QoS requirements

   Requested QoS parameters by an application like bandwidth, delay,
   energy, jitter, etc.
































Kettaf, et al.           Expires April 14, 2008                 [Page 9]

Internet-Draft                    ACOR                      October 2007


5.  Conceptual Data Structures and Messages

5.1.  Route table entry

   -destination node IP address

   -destination node IP address

   -destination node Sequence number

   -the global cost function Fg

   -Hop Count

   -Next Hop

5.2.  ACOR packets formats

5.2.1.  RouteRequest packet

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |          Reserved             |  Hop Count    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   QoS requirements        |               Fg                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RouteRequest_ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Destination address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Destination Sequence Number                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Source IP address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Source Sequence Number                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1. RouteRequest message format


   The format of the RouteRequest message is illustrated above, and
   contains the following fields:

   -Type

   Indicates which control packet is sent




Kettaf, et al.           Expires April 14, 2008                [Page 10]

Internet-Draft                    ACOR                      October 2007


   -Reserved

   Sent as 0, ignored on reception.

   -Hop Count

   The number of hops from the Source node to node handling the request.

   -QoS requirements

   Specifies the QoS requirements of the source node.

   -Fg

   The global cost function of a route (incremented from the source node
   to node handling the request).

   -RouteRequest_ID

   A sequence number uniquely identifying the particular RouteRequest
   when taken in conjunction with the source and destination node's IP
   address.

   -Destination address

   The address of the destination for which a route is intended.

   -Destination sequence number

   The last sequence number received previously by the source for any
   route toward the destination.

   -Source IP address

   The IP address of the node which originated the RouteRequest.

   -Source Sequence Number

   The current sequence number to be used for route entries pointing to
   (any generated by) the source of the RouteRequest.

5.2.2.  RouteReply packet

   This packet is used during the route discovery phase and is sent by
   the destination node of a RouteRequest.  The RouteReply packet
   contains the various fields below:





Kettaf, et al.           Expires April 14, 2008                [Page 11]

Internet-Draft                    ACOR                      October 2007


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type        |             Reserved        |   Hop Count   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   QoS requirements        |               Fg                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RouteReply_ID                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Destination address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source IP address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Lifetime                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 2. RouteReply message format


   The format of the RouteReply message is illustrated above and
   contains the following fields:

   -Type

   Indicates which control packet is sent.

   -Reserved

   Sent as 0; ignored on reception.

   -Hop Count

   The number of hops from the receiver of the packet to the source
   node.

   -QoS requirements

   Specifies the QoS requirements of the source node.

   -Fg

   The global cost function of a route (incremented from the source node
   to destination).

   -RouteReply_ID

   A sequence number uniquely identifying the particular RouteReply when
   taken in conjunction with the source and destination.




Kettaf, et al.           Expires April 14, 2008                [Page 12]

Internet-Draft                    ACOR                      October 2007


   -Destination address

   The IP address of the destination for which a route is supplied.

   -Source IP address

   The IP address of the node that requested a route.

   -Lifetime

   The time in milliseconds for which nodes receiving the RouteReply
   consider the route and the reserved resources to be valid.

5.2.3.  RouteError packet

   The RouteError packet is invoked whenever a route failure is detected
   by an intermediate neighboring node.


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type      |    Reserved              | UnDest            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Fg                                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Destination Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Destination Sequence Number                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Additional Unreachable destination             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Additional Unreachable Destination Sequence number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3. RouteError message format



   The format of the RouteError message is illustrated above, and
   contains the following fields:

   -Type

   Indicates which control packet is sent.

   -Reserved




Kettaf, et al.           Expires April 14, 2008                [Page 13]

Internet-Draft                    ACOR                      October 2007


   Sent as 0; ignored on reception.

   -UnDest

   The number of unreachable destinations included in the message; MUST
   be at least 1.

   -Fg

   The global cost function of a route.

   -Destination address

   The IP address of the node that has become unreachable.

   -Destination Sequence Number

   The sequence number in the route table entry for the destination
   listed in the previous Destination address field.

5.2.4.  Hello packet

   Every ACOR's node generates a Hello message once every HLO_INTERVAL
   milliseconds.  The message fields set as follows:

   -Destination Address

   The node's IP address,

   -Destination Sequence Number

   A sequence number uniquely identifying the hello packet.

   - Lifetime = (1+ALLOWED_HLO_LOSS) * HLO_INTERVAL

















Kettaf, et al.           Expires April 14, 2008                [Page 14]

Internet-Draft                    ACOR                      October 2007


6.  ACOR Operation

6.1.  Generating and forwarding route requests

   ACORs route discovery is on-demand using limited broadcast.  A node
   disseminates a RouteRequest packet throughout the network when it
   determines that it needs to establish a route to a destination and
   does not have one available.  This can happen if the destination is
   previously unknown to the node, or if a previously used route to the
   destination becomes invalid due to expiration of its Lifetime (time
   out associated with the route expires), or else if a link breakage
   results in a infinite metric being associated with the route.  When a
   route table entry is marked with an infinite metric, its expiration
   time is also updated to be the current time plus FLD_LINK_LIFETIME
   milliseconds.  After the expiration time, the route MAY be expunged
   from the node's route table.

   If, on the other hand, the node does have a route for the
   destination, it compares the destination sequence number for that
   route with the destination sequence number field of the incoming
   RouteRequest.  If the node's existing destination sequence number is
   smaller than the Destination Sequence Number field of the
   RouteRequest, the node again rebroadcasts the RouteRequest as if it
   did not have a route to the destination at all.

   If the node has a route to the destination, and the node's existing
   destination sequence number is greater than or equal to the
   destination sequence number of the RouteRequest, then the node
   generates a RouteReply with the updated Fg back to the source as
   discussed further in section 4.2.

   Upon receiving the route request, a node first, verifies whether it
   has received a RouteRequest with the same Source IP Address field
   within the last RQ_ID_SAVE milliseconds.  Then, the node checks for
   available resources to make the admission decision and increments the
   value of the global cost function Fg received in the RouteRequest
   packet by adding the local elementary cost functions Fb and Fd.
   Afterwards the RouteRequest is broadcast to next neighbors with the
   same field values, but with the new updated Fg and using its own IP
   address in the IP header of the outgoing RouteRequest.  The TTL
   (TimeToLive) or hop limit in the field is decreased by one.  In order
   to account to the new hop through the intermediate node, the Hop
   Count in the broadcast message is incremented by one.  In this case,
   the node creates also in its routing table a reverse route to the
   source node with next hop equal to the IP address of the neighboring
   node that sent the broadcast RouteRequest.  Eventually, this reverse
   route which is put into route table with lifetime REV_ROUTE_LIFE
   milliseconds might be used for RouteReply back to the original node



Kettaf, et al.           Expires April 14, 2008                [Page 15]

Internet-Draft                    ACOR                      October 2007


   making the RouteRequest identified by the source IP address.

   After broadcasting a RouteRequest a node waits for a RouteReply, and
   if the reply is not received within REP_WAIT_TIME seconds, the node
   may rebroadcast the RouteRequest up to a maximum of RQ_RETRIES times.
   Each broadcast has to increment the RouteRequest_ID field.

   To avoid congestion, a node SHOULD NOT transmit more than RATE_LIMIT
   route request packets per seconds.  RouteRequest packets SHOULD be
   discarded before RouteReply or RouteError.

   Data packets waiting for a route SHOULD be buffered at the source
   node.  The buffering SHOULD be FIFO.  If a RouteRequest has been
   rebroadcast RQ_RETRIES times without receiving any RouteReply, all
   data packets destined for the corresponding destination SHOULD be
   dropped from the buffer.

6.2.  Generating route replies

   When the destination node receives a RouteRequest, it MUST generate a
   RouteReply packet and unicast it back to the source node indicated by
   the Source Address field in the route request packet.  The route
   reply SHOULD include the incremented Fg from source to destination
   during the propagation of the route request.  First, the node copies
   over its destination sequence number from the entry in its route
   table, or if the generating node is the node itself, it uses a
   destination sequence number at least equal to a sequence number
   generated after the last detected change in its neighbor set.  If the
   node has not detected any change in its set of neighbors since it
   last incremented its destination sequence number, it may use the same
   destination sequence number.

   An intermediate node that receives a RouteReply to forward, it
   validates the resources reservation, then it SHOULD send replies not
   only to the destination node listed in this route reply packet, but
   also to all nodes that have previously sent RouteRequest to the
   source of the RouteReply and no reply has been forwarded to them yet.
   Here, the intermediate node deducts the value of the sent Fg in the
   route request packet from the value of the received Fg in the route
   reply packet (Fg received - Fg sent).  The diffrence represents the
   value that will be added to the value of the recorded Fg during the
   route request dissemination.  Hence, the forwarded RouteReply will
   include a new Fg value since the intermediate node incremented it by
   adding the accumulated cost from the intermediate node to the
   destination node.

   If a new route for the requested destination is offered, then the
   source node compares the values of Fg received in the route reply



Kettaf, et al.           Expires April 14, 2008                [Page 16]

Internet-Draft                    ACOR                      October 2007


   packet.  If the new route carries a smaller Fg than the Fg of the
   operational route, then the new route MAY be selected.  If, however,
   the node does not have a route that satisfies QoS requirements to the
   destination, it may append the newly incoming route to send data on
   best effort.

6.3.  Generating route errors

   If a node is unable to forward control or data packets because there
   is no route available or a forwarding error occurs along the data
   route as a result of a node or link failure detected by listening for
   "Hello" messages from its neighbors set.  A node should assume that a
   hello message has been missed if it is not received within 1.5 times
   the duration of the HLO_INTERVAL.  Hence, the node MAY attempt a
   number of additional retransmissions of the unforwarded data packet
   up to number of MAX_DATA_RETRIES.  ACOR's nodes adopt the
   retransmission technique to quickly recover the route that could have
   been failed by temporary factors such as moving node, noise bursts,
   etc.  If, however, the failure persists, the node carries out the
   route maintenance by generating a RouteError packet.

   A route error packet MAY be unicast to all precursors with the
   corresponding Fg to each neighbor.  Even when the RouteError is
   unicast to several precursors, for the purposes of description, it is
   considered to be a single control packet.  However, a node SHOULD NOT
   generate more than RE_RATELIMIT route error packets per second.

   During the propagation of the RouteError packet towards the source
   node, every intermediate node SHOULD invalidate the reserved
   resources and update the route table that may affect the destination
   sequence number of the unreachable destinations and expunging it from
   the routing table.

   Note that ACOR's nodes, eventually, can implement any physical or
   link layer techniques to detect link breakages with nodes it has
   considered as neighbors.

6.4.  Generating Hello messages

   In order to obtain connectivity information, a node MAY disseminate
   hello packets.  Connectivity MAY be determined by listening for
   packets from a node's set of neighbors.  Hello packets SHOULD be
   broadcast every HLO_INTERVAL milliseconds to immediate neighbors.
   Adopting this technique, a node can easily estimate the delay of next
   hop by examining the timestamp field in the received hello packet
   from its neighbor.  The numerical value of the estimated delay MAY be
   represented within the elementary local cost function Fb.  If the
   node does not receive a hello packet from a neighbor within a



Kettaf, et al.           Expires April 14, 2008                [Page 17]

Internet-Draft                    ACOR                      October 2007


   HLO_WAIT, and then for ALLOWED_HLO_LOSS * HLO_INTERVAL milliseconds,
   the node SHOULD assume that the link to this neighbor is currently
   lost.
















































Kettaf, et al.           Expires April 14, 2008                [Page 18]

Internet-Draft                    ACOR                      October 2007


7.  Protocol parameters values

     ALLOWED_HLO_LOSS      2
     FLD_LINK_LIFETIME     3000 milliseconds
     HLO_INTERVAL          2000 milliseconds
     REV_ROUTE_LIFE        3000 milliseconds
     RQ_ID_SAVE            3000 milliseconds
     RQ_RETRIES            3 times











































Kettaf, et al.           Expires April 14, 2008                [Page 19]

Internet-Draft                    ACOR                      October 2007


8.  Security Considerations

   This draft specifies mechanisms for handling routing with quality of
   service.  Currently, it does not address any special security issues.
   However, it is assumed that security measures are adequately address
   by IPSec authentication headers and digital signatures or
   cryptography with the necessary key management to distribute keys to
   the members of the ad hoc network implementing ACOR.











































Kettaf, et al.           Expires April 14, 2008                [Page 20]

Internet-Draft                    ACOR                      October 2007


9.  Acknowledgements

   The authors wish to thank all colleagues for their helpful comments
   and suggestions.















































Kettaf, et al.           Expires April 14, 2008                [Page 21]

Internet-Draft                    ACOR                      October 2007


10.  References

   [1]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand
        Distance Vector (AODV) Routing", RFC 3561, July 2003.

   [2]  Jaffe, J., "Algorithms for finding paths with multiple
        constraints", Journal Networks, vol. 14, pp. 95-116, 1984.

   [3]  Bradner., S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, October 2003.

   [4]  Perkins, C. and E. Belding-Royer, "Quality of Service for Ad hoc
        On-Demand Distance Vector Routing",
        I-D draft-perkins-manet-aodvqos-02.txt(Work in Progress),
        February 2003.

   [5]  Chakeres, I. and C. Perkins, "Dynamic MANET On-demand Routing
        Protocol", I-D draft-ietf-manet-dymo-08.txt, March 2007 (Work in
        Progress), March 2007.
































Kettaf, et al.           Expires April 14, 2008                [Page 22]

Internet-Draft                    ACOR                      October 2007


Authors' Addresses

   Kettaf Noureddine
   Haute Alsace university
   34, rue de Grillenbreit
   Colmar  68000
   FRANCE

   Phone: +33 (0)3 89 20 23 68
   Email: nour-eddine.kettaf@uha.fr or kettaf@gmail.com


   Abouaissa Hafid
   Haute Alsace university
   34, rue de Grillenbreit
   Colmar  68000
   FRANCE

   Phone: +33 (0)3 89 20 23 71
   Email: a.abouaissa@uha.fr


   Vu Duong Thang
   France Telecom R&D
   Technopole Anticipa
   2, Avenue Pierre Marzin
   LANNION Cedex  22307
   FRANCE

   Phone: +33 (0)2 96 05 17 06
   Email: thang.vuduong@orange-ft.com


   Lorenz Pascal
   Haute Alsace university
   34, rue de Grillenbreit
   Colmar  68000
   FRANCE

   Phone: +33 (0)3 89 20 23 66
   Email: p.lorenz@uha.fr










Kettaf, et al.           Expires April 14, 2008                [Page 23]

Internet-Draft                    ACOR                      October 2007


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.


Acknowledgment

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





Kettaf, et al.           Expires April 14, 2008                [Page 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/