IETF MANET Working Group N. Kettaf Internet-Draft H. Abouaissa Intended status: Informational MIPS Expires: April 4, 2007 T. Vu Duong France Telecom R&D P. Lorenz MIPS October 2006 Admission Control enabled On demand Routing (ACOR) draft-kettaf-manet-acor-01.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 4, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Kettaf, et al. Expires April 4, 2007 [Page 1] Internet-Draft ACOR October 2006 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 4, 2007 [Page 2] Internet-Draft ACOR October 2006 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 4, 2007 [Page 3] Internet-Draft ACOR October 2006 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 4, 2007 [Page 4] Internet-Draft ACOR October 2006 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 4, 2007 [Page 5] Internet-Draft ACOR October 2006 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 4, 2007 [Page 6] Internet-Draft ACOR October 2006 particular, a high value of Fg represents an overloaded route. Kettaf, et al. Expires April 4, 2007 [Page 7] Internet-Draft ACOR October 2006 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 4, 2007 [Page 8] Internet-Draft ACOR October 2006 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 4, 2007 [Page 9] Internet-Draft ACOR October 2006 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 4, 2007 [Page 10] Internet-Draft ACOR October 2006 -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 4, 2007 [Page 11] Internet-Draft ACOR October 2006 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 4, 2007 [Page 12] Internet-Draft ACOR October 2006 -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 4, 2007 [Page 13] Internet-Draft ACOR October 2006 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 4, 2007 [Page 14] Internet-Draft ACOR October 2006 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 4, 2007 [Page 15] Internet-Draft ACOR October 2006 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 4, 2007 [Page 16] Internet-Draft ACOR October 2006 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 4, 2007 [Page 17] Internet-Draft ACOR October 2006 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 4, 2007 [Page 18] Internet-Draft ACOR October 2006 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 4, 2007 [Page 19] Internet-Draft ACOR October 2006 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 4, 2007 [Page 20] Internet-Draft ACOR October 2006 9. Acknowledgements The authors wish to thank M. Bryan Hogan, Dr Hasnaa Moustapha and all other colleagues for their helpful comments and suggestions. Kettaf, et al. Expires April 4, 2007 [Page 21] Internet-Draft ACOR October 2006 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-04.txt, March 2006 (Work in Progress), March 2006. Kettaf, et al. Expires April 4, 2007 [Page 22] Internet-Draft ACOR October 2006 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 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 4, 2007 [Page 23] Internet-Draft ACOR October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 4, 2007 [Page 24]