idnits 2.17.1 draft-rogge-baccelli-olsrv2-ett-metric-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 323 has weird spacing: '...eceived is a ...' == Line 327 has weird spacing: '...T_total is a ...' == Line 332 has weird spacing: '...lo_time is th...' == Line 334 has weird spacing: '...nterval is th...' == Line 338 has weird spacing: '...essages is th...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TAIL' is mentioned on line 468, but not defined ** Obsolete normative reference: RFC 6622 (Obsoleted by RFC 7182) == Outdated reference: A later version (-29) exists of draft-ietf-manet-dlep-04 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET H. Rogge 3 Internet-Draft Fraunhofer FKIE 4 Intended status: Informational E. Baccelli 5 Expires: August 18, 2014 INRIA 6 February 14, 2014 8 Packet Sequence Number based directional airtime metric for OLSRv2 9 draft-rogge-baccelli-olsrv2-ett-metric-04 11 Abstract 13 This document specifies an directional airtime link metric for usage 14 in OLSRv2. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 18, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 53 4. Directional Airtime Metric Rational . . . . . . . . . . . . . 5 54 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6 55 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 56 6.1. Recommended Values . . . . . . . . . . . . . . . . . . . . 7 57 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 7 58 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 8 59 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . . 9 60 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 9 61 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 62 9.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 9 63 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . . 10 64 9.3.1. Packet Sequence based link loss . . . . . . . . . . . 10 65 9.3.2. HELLO based Link Loss . . . . . . . . . . . . . . . . 11 66 9.3.3. Other Measurement of Link Loss . . . . . . . . . . . . 11 67 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . . 11 68 10. HELLO Timeout Processing . . . . . . . . . . . . . . . . . . . 12 69 11. Metric Update . . . . . . . . . . . . . . . . . . . . . . . . 12 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 73 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 15.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 15.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Appendix A. OLSR.org metric history . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 One of the major shortcomings of OLSR [RFC3626] is the missing of a 82 link cost metric between mesh nodes. Operational experience with 83 mesh networks gathered since the standardization of OLSR has revealed 84 that wireless networks links can have highly variable and 85 heterogeneous properties. This makes a hopcount metric insufficient 86 for effective mesh routing. 88 Based on this experience, OLSRv2 [OLSRV2] integrates the concept of 89 link metrics directly into the core specification of the routing 90 protocol. The OLSRv2 routing metric is an external process, it can 91 be any kind of dimensionless additive cost function which reports to 92 the OLSRv2 protocol. 94 Since 2004 the OLSR.org [OLSR.org] implementation of OLSR included an 95 Estimated Transmission Count (ETX) metric [MOBICOM04] as a 96 proprietary extension. While this metric is not perfect, it proved 97 to be sufficient for a long time for Community Mesh Networks 98 (Appendix A). But the increasing maximum data rate of IEEE 802.11 99 made the ETX metric less efficient than in the past, which is one 100 reason to move to a different metric. 102 This document describes a Directional Airtime routing metric for 103 OLSRv2, a successor of the OLSR.org routing metric for [RFC3626]. It 104 takes both the loss rate and the link speed into account to provide a 105 more accurate picture of the mesh network links. 107 2. Terminology 109 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 110 NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', 111 and 'OPTIONAL' in this document are to be interpreted as described in 112 [RFC2119]. 114 The terminology introduced in [RFC5444], [OLSRV2] and [RFC6130], 115 including the terms "packet", "message" and "TLV" are to be 116 interpreted as described therein. 118 Additionally, this document uses the following terminology and 119 notational conventions: 121 QUEUE - a first in, first out queue of integers. 123 QUEUE[TAIL] - the most recent element in the queue. 125 add(QUEUE, value) - adds a new element to the TAIL of the queue. 127 remove(QUEUE) - removes the HEAD element of the queue 129 sum(QUEUE) - an operation which returns the sum of all elements in a 130 QUEUE. 132 diff_seqno(new, old) - an operation which returns the positive 133 distance between two elements of the circular sequence number 134 space defined in section 5.1 of [RFC5444]. Its value is either 135 (new - old) if this result is positive, or else its value is (new 136 - old + 65536). 138 MAX(a,b) - the maximum of a and b. 140 UNDEFINED - a value not in the normal value range of a variable. 141 Might be -1 for this protocol. 143 airtime - the time a transmitted packet blocks the link layer, e.g., 144 a wireless link. 146 ETX - Expected Transmission Count, a link metric proportional to the 147 number of transmissions to successfully send an IP packet over a 148 link. 150 ETT - Estimated Travel Time, a link metric proportional to the 151 amount of airtime needed to transmit an IP packet over a link, not 152 considering layer-2 overhead created by preamble, backoff time and 153 queuing. 155 DAT - Directional Airtime Metric, the link metric described in this 156 document, which is a directional variant of ETT. It does not take 157 reverse path loss into account. 159 3. Applicability Statement 161 The Directional Airtime Metric was designed and tested in wireless 162 IEEE 802.11 mesh networks. These networks employ link layer 163 retransmission to increase the delivery probability and multiple 164 unicast data rates. 166 The metric must learn about the unicast data rate towards each one- 167 hop neighbor from an external process, either by configuration or by 168 an external measurement process. This measurement could be done by 169 gathering cross-layer data from the operating system or an external 170 daemon like DLEP [DLEP], but also by indirect layer-3 measurements 171 like packet-pair. 173 If [RFC5444] control traffic is used to determine the link packet 174 loss, the administrator should take care that link layer multicast 175 transmission do not not have a higher reception probability than the 176 slowest unicast transmission. It might be necessary to increase the 177 data-rate of the multicast transmissions, e.g. set the multicast 178 data-rate to 6 MBit/s if you use IEEE 802.11g only. 180 The metric can only handle a certain range of packet loss and unicast 181 data-rate. Maximum packet loss is "ETX 4" (1 of 4 packets is 182 successfully sent to the receiver, without link layer 183 retransmissions), the unicast data-rate can be between 1024 Bit/s and 184 4 GBit/s. The metric has been designed for data-rates of 1 MBit/s 185 and hundreds of MBit/s. 187 4. Directional Airtime Metric Rational 189 The Directional Airtime Metric has been inspired by the publications 190 on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but has several 191 key differences. 193 Instead of measuring the combined loss probability of a bidirectional 194 transmission of a packet over a link in both directions, the 195 Directional Airtime Metric measures the incoming loss rate and 196 integrates the incoming linkspeed into the metric cost. There are 197 multiple reasons for this decision: 199 o OLSRv2 [OLSRV2] defines the link metric as directional costs 200 between nodes. 202 o Not all link layer implementations use acknowledgement mechanisms. 203 Most link layer implementations who do use them use less airtime 204 and a more robust modulation for the acknowledgement than the data 205 transmission, which makes it more likely for the data transmission 206 to be disrupted compared to the acknowledgement. 208 o Incoming packet loss and linkspeed can be measured locally, 209 symmetric link loss would need an additional signaling TLV in the 210 [RFC6130] HELLO and would delay metric calculation by up to one 211 HELLO interval. 213 The Directional Airtime Metric does not integrate the packet size 214 into the link cost. Doing so is not feasible in most link-state 215 routing protocol implementations. The routing decision of most 216 operation systems don't take packet size into account. Multiplying 217 all link costs of a topology with the size of a data-plane packet 218 would never change the dijkstra result anyways. 220 The queue based packet loss estimator has been tested extensively in 221 the OLSR.org ETX implementation, see Appendix A. The output is the 222 average of the packet loss over a configured time period. 224 5. Metric Functioning & Overview 226 The Directional Airtime Metric is calculated for each link set entry, 227 as defined in [RFC6130] section 7.1. 229 The metric processes two kinds of data into the metric value, namely 230 packet loss rate and link-speed. While the link-speed is taken from 231 an external process, the current packet loss rate is calculated by 232 keeping track of packet reception and packet loss events. 234 Multiple incoming packet loss/reception events must be combined into 235 a loss rate to get a smooth metric. Experiments with exponential 236 weighted moving average (EWMA) lead to a highly fluctuating or a slow 237 converging metric (or both). To get a smoother and more controllable 238 metric result, this metric uses two fixed length queues to measure 239 and average the incoming packet events, one queue for received 240 packets and one for the estimated number of packets sent by the other 241 side of the link. 243 Because the rate of incoming packets is not uniform over time, the 244 queue contains a number of counters, each representing a fixed time 245 interval. Incoming packet loss and packet reception event are 246 accumulated in the current queue element until a timer adds a new 247 empty counter to both queues and remove the oldest counter from both. 249 In addition to the packet loss stored in the queue, this metric uses 250 a timer to detect a total link-loss. For every NHDP HELLO interval 251 in which the metric received no packet from a neighbor, it scales the 252 number of received packets in the queue based on the total time 253 interval the queue represents compared to the total time of the lost 254 HELLO intervals. 256 The average packet loss ratio is calculated as the sum of the 'total 257 packets' counters divided by the sum of the 'packets received' 258 counters. This value is then divided through the current link-speed 259 and then scaled into the range of metrics allowed for OLSRv2. 261 The metric value is then used as L_in_metric of the Link Set (as 262 defined in section 8.1. of [OLSRV2]). 264 6. Protocol Parameters 266 This specification defines the following parameters, which can be 267 changed without making the metric outputs incomparable with each 268 other: 270 DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All 271 received and lost packets within the queue are used to calculate 272 the cost of the link. 274 DAT_REFRESH_INTERVAL - interval in seconds between two metric 275 recalculations as described in Section 11. This value SHOULD be 276 smaller than a typical HELLO interval. 278 DAT_HELLO_TIMEOUT_FACTOR - timeout factor for HELLO interval at 279 which point a HELLO is definitely considered lost. The value must 280 be a floating point number between 1.0 and 2.0, large enough to 281 take the delay and jitter for message aggregation into account. 283 DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets 284 (based on received packet sequence numbers) at which point the 285 router considers the neighbor has restarted. This parameter is 286 only used for packet sequence number based loss estimation. This 287 number MUST be larger than DAT_MAXIMUM_LOSS. 289 6.1. Recommended Values 291 The proposed values of the protocol parameters are for Community Mesh 292 Networks, which mostly use immobile mesh nodes. Using this metric 293 for mobile networks might require shorter DAT_REFRESH_INTERVAL and/or 294 DAT_MEMORY_LENGTH. 296 DAT_MEMORY_LENGTH := 64 298 DAT_REFRESH_INTERVAL := 1 300 DAT_HELLO_TIMEOUT_FACTOR := 1.2 302 DAT_SEQNO_RESTART_DETECTION := 256 304 7. Protocol Constants 306 This specification defines the following constants, which cannot be 307 changed without making the metric outputs incomparable: 309 DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing 310 metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and 311 (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS: 4. 313 DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing 314 metric: 1024. 316 8. Data Structures 318 This specification extends the Link Set Tuples of the Interface 319 Information Base, as defined in [RFC6130] section 7.1, by the 320 following additional elements for each link tuple when being used 321 with this metric: 323 L_DAT_received is a QUEUE with DAT_MEMORY_LENGTH integer elements. 324 Each entry contains the number of successfully received packets 325 within an interval of DAT_REFRESH_INTERVAL. 327 L_DAT_total is a QUEUE with DAT_MEMORY_LENGTH integer elements. 328 Each entry contains the estimated number of packets transmitted by 329 the neighbor, based on the received packet sequence numbers within 330 an interval of DAT_REFRESH_INTERVAL. 332 L_DAT_hello_time is the time when the next hello will be expected. 334 L_DAT_hello_interval is the interval between two hello messages of 335 the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] 336 of NHDP messages [RFC6130]. 338 L_DAT_lost_hello_messages is the estimated number of lost hello 339 messages from this neighbor, based on the value of the hello 340 interval. 342 L_DAT_rx_bitrate is the current bitrate of incoming unicast traffic 343 for this neighbor. 345 Methods to obtain the value of L_DAT_rx_bitrate are out of the scope 346 of this specification. Such methods may include static configuration 347 via a configuration file or dynamic measurement through mechanisms 348 described in a separate specification (e.g. [DLEP]). Any Link tuple 349 with L_status = HEARD or L_status = SYMMETRIC MUST have a specified 350 value of L_DAT_rx_bitrate if it is to be used by this routing metric. 352 When using packet sequence numbers to estimate the loss rate, the 353 Link Set Tuples get another field: 355 L_DAT_last_pkt_seqno is the last received packet sequence number 356 received from this link. 358 8.1. Initial Values 360 When generating a new tuple in the Link Set, as defined in [RFC6130] 361 section 12.5 bullet 3, the values of the elements specified in 362 Section 8 are set as follows: 364 o L_DAT_received := 0, ..., 0. The queue always has 365 DAT_MEMORY_LENGTH elements. 367 o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH 368 elements. 370 o L_DAT_last_pkt_seqno := UNDEFINED (no earlier packet received). 372 o L_DAT_hello_time := EXPIRED (no earlier NHDP HELLO received). 374 o L_DAT_hello_interval := UNDEFINED (no earlier NHDP HELLO 375 received). 377 o L_DAT_lost_hello_messages := 0 (no HELLO interval without 378 packets). 380 9. Packets and Messages 382 9.1. Definitions 384 For the purpose of this section, note the following definitions: 386 o "pkt_seqno" is defined as the [RFC5444] packet sequence number of 387 the received packet. 389 o "interval_time" is the time encoded in the INTERVAL_TIME message 390 TLV of a received [RFC6130] HELLO message. 392 9.2. Requirements 394 An implementation of OLSRv2 using the metric specified by this 395 document MUST include the following parts into its [RFC5444] output: 397 o an INTERVAL_TIME message TLV in each HELLO message, as defined in 398 [RFC6130] section 4.3.2. 400 9.3. Link Loss Data Gathering 402 While this metric was designed for measuring the packet loss based on 403 the [RFC5444] packet sequence number, some implementations might not 404 be able to add the packet sequence number to their output. 406 9.3.1. Packet Sequence based link loss 408 An implementation of OLSRv2, using the metric specified by this 409 document with packet sequence based link loss, MUST include the 410 following element into its [RFC5444] output: 412 o an interface specific packet sequence number as defined in 413 [RFC5444] section 5.1 which is incremented by 1 for each outgoing 414 [RFC5444] packet on the interface. 416 For each incoming [RFC5444] packet, additional processing MUST be 417 carried out after the packet messages have been processed as 418 specified in [RFC6130] and [OLSRV2]. 420 [RFC5444] packets without packet sequence number MUST NOT be 421 processed in this way by this metric. 423 The router MUST update the Link Set Tuple corresponding to the 424 originator of the packet: 426 1. If L_DAT_last_pkt_seqno = UNDEFINED, then: 428 1. L_DAT_received[TAIL] := 1. 430 2. L_DAT_total[TAIL] := 1. 432 2. Otherwise: 434 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 436 2. diff := seq_diff(pkt_seqno, L_DAT_last_pkt_seqno). 438 3. If diff > DAT_SEQNO_RESTART_DETECTION, then: 440 1. diff := 1. 442 4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff. 444 3. L_DAT_last_pkt_seqno := pkt_seqno. 446 4. If L_DAT_hello_interval != UNDEFINED, then: 448 1. L_DAT_hello_time := current time + (L_DAT_hello_interval * 449 DAT_HELLO_TIMEOUT_FACTOR). 451 5. L_DAT_lost_hello_messages := 0. 453 9.3.2. HELLO based Link Loss 455 A metric might just use the incoming NHDP HELLO messages of a 456 neighbor to calculate the link loss. Because this method uses fewer 457 events to calculate the metric, the variance of the output will 458 increase. It might be necessary to increase the value of 459 DAT_MEMORY_LENGTH to compensate for this. 461 For each incoming HELLO message, after it has been processed as 462 defined in [RFC6130] section 12, the Link Set Tuple as defined in 463 section 7.1 corresponding to the incoming HELLO message must be 464 updated. 466 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 468 2. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1. 470 3. L_DAT_lost_hello_messages := 0. 472 9.3.3. Other Measurement of Link Loss 474 Instead of using incoming [RFC5444] packets or [RFC6130] messages, 475 the routing daemon can also use other sources to measure the link 476 layer lossrate (e.g. [DLEP]). 478 To use a source like this with the DAT metric, the routing daemon has 479 to add incoming total traffic (or the sum of received and lost 480 traffic) and lost traffic to the queued elements in the extension of 481 the Link Set Tuple defined in Section 8 corresponding to originator 482 of the traffic. 484 The routing daemon should also set L_DAT_lost_hello_messages to zero 485 every times new packages arrive. 487 9.4. HELLO Message Processing 489 For each incoming HELLO Message, after it has been processed as 490 defined in [RFC6130] section 12, the Link Set Tuple corresponding to 491 the incoming HELLO message must be updated. 493 Only HELLO messages with an INTERVAL_TIME message TLVs must be 494 processed. 496 1. L_DAT_hello_interval := interval_time. 498 10. HELLO Timeout Processing 500 When L_DAT_hello_time has timed out, the following step MUST be done: 502 1. L_DAT_lost_hello_messages := L_DAT_lost_hello_messages + 1. 504 2. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval. 506 11. Metric Update 508 Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link 509 Set entries MUST be recalculated: 511 1. sum_received := sum(L_DAT_total). 513 2. sum_total := sum(L_DAT_received). 515 3. If L_DAT_hello_interval != UNDEFINED and 516 L_DAT_lost_hello_messages > 0, then: 518 1. lost_time_proportion := L_DAT_hello_interval * 519 L_DAT_lost_hello_messages / DAT_MEMORY_LENGTH. 521 2. sum_received := sum_received * MAX ( 0, 1 - 522 lost_time_proportion); 524 4. If sum_received < 1, then: 526 1. L_in_metric := MAXIMUM_METRIC, as defined in [OLSRV2] section 527 5.6.1. 529 5. Otherwise: 531 1. loss := sum_total / sum_received. 533 2. If loss > DAT_MAXIMUM_LOSS, then: 535 1. loss := DAT_MAXIMUM_LOSS. 537 3. bitrate := L_DAT_rx_bitrate. 539 4. If bitrate < DAT_MINIMUM_BITRATE, then: 541 1. bitrate := DAT_MINIMUM_BITRATE. 543 5. L_in_metric := (2^24 / DAT_MAXIMUM_LOSS) * loss / (bitrate / 544 DAT_MINIMUM_BITRATE). 546 6. remove(L_DAT_total) 548 7. add(L_DAT_total, 0) 550 8. remove(L_DAT_received) 552 9. add(L_DAT_received, 0) 554 12. IANA Considerations 556 This document contains no actions for IANA. 558 13. Security Considerations 560 Artificial manipulation of metrics values can drastically alter 561 network performance. In particular, advertising a higher L_in_metric 562 value may decrease the amount of incoming traffic, while advertising 563 lower L_in_metric may increase the amount of incoming traffic. By 564 artificially increasing or decreasing the L_in_metric values it 565 advertises, a rogue router may thus attract or repulse data traffic. 566 A rogue router may then potentially degrade data throughput by not 567 forwarding data as it should or redirecting traffic into routing 568 loops or bad links. 570 An attacker might also inject packets with incorrect packet level 571 sequence numbers, pretending to be somebody else. This attack could 572 be prevented by the true originator of the RFC5444 packets by adding 573 a [RFC6622] ICV Packet TLV and TIMESTAMP Packet TLV to each packet. 574 This allows the receiver to drop all incoming packets which have a 575 forged packet source, both packets generated by the attacker or 576 replayed packets. 578 14. Acknowledgements 580 The authors would like to acknowledge the network administrators from 581 Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for 582 endless hours of testing and suggestions to improve the quality of 583 the original ETX metric for the OLSR.org routing daemon. 585 This effort/activity is supported by the European Community Framework 586 Program 7 within the Future Internet Research and Experimentation 587 Initiative (FIRE), Community Networks Testbed for the Future Internet 588 ([CONFINE]), contract FP7-288535. 590 The authors would like to gratefully acknowledge the following people 591 for intense technical discussions, early reviews and comments on the 592 specification and its components (listed alphabetically): Teco Boot 593 (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), 594 Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology 595 Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus 596 Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research 597 Laboratory) and Stan Ratliff (Cisco Systems). 599 15. References 601 15.1. Normative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", RFC 2119, BCP 14, March 1997. 606 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 607 Protocol", RFC 3626, October 2003. 609 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 610 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 611 Format", RFC 5444, February 2009. 613 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 614 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 615 March 2009. 617 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 618 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 619 RFC 6130, April 2011. 621 [RFC6622] Ulrich, U. and T. Clausen, "Integrity Check Value and 622 Timestamp TLV Definitions for Mobile Ad Hoc Networks 623 (MANETs)", RFC 6622, May 2012. 625 [OLSRV2] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized 626 Link State Routing Protocol version 2", 627 draft-ietf-manet-olsrv2-19 , March 2013. 629 15.2. Informative References 631 [CONFINE] "Community Networks Testbed for the Future Internet 632 (CONFINE)", 2013, . 634 [DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D. 635 Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", 636 draft-ietf-manet-dlep-04 , March 2013. 638 [MOBICOM03] 639 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 640 High-Throughput Path Metric for Multi-Hop Wireless 641 Routing", Proceedings of the MOBICOM Conference , 2003. 643 [MOBICOM04] 644 Richard, D., Jitendra, P., and Z. Brian, "Routing in 645 Multi-Radio, Multi-Hop Wireless Mesh Networks", 646 Proceedings of the MOBICOM Conference , 2004. 648 [OLSR.org] 649 "The OLSR.org OLSR routing daemon", 2013, 650 . 652 [FREIFUNK] 653 "Freifunk Wireless Community Networks", 2013, 654 . 656 [FUNKFEUER] 657 "Austria Wireless Community Network", 2013, 658 . 660 Appendix A. OLSR.org metric history 662 The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR- 663 based [RFC3626] or B.A.T.M.A.N. based wireless community networks 664 with hundreds of routers in permanent operation. The Vienna 665 Funkfeuer network in Austria, for instance, consists of 400 routers 666 (around 600 routes) covering the whole city of Vienna and beyond, 667 spanning roughly 40km in diameter. It has been in operation since 668 2003 and supplies its users with Internet access. A particularity of 669 the Vienna Funkfeuer network is that it manages to provide Internet 670 access through a city wide, large scale Wi-Fi mesh network, with just 671 a single Internet uplink. 673 Operational experience of the OLSR project [OLSR.org] with these 674 networks have revealed that the use of hop-count as routing metric 675 leads to unsatisfactory network performance. Experiments with the 676 ETX metric [MOBICOM03] were therefore undertaken in parallel in the 677 Berlin Freifunk network as well as in the Vienna Funkfeuer network in 678 2004, and found satisfactory, i.e., sufficiently easy to implement 679 and providing sufficiently good performance. This metric has now 680 been in operational use in these networks for several years. 682 The ETX metric of a link is the estimated number of transmissions 683 required to successfully send a packet (each packet equal to or 684 smaller than MTU) over that link, until a link layer acknowledgement 685 is received. The ETX metric is additive, i.e., the ETX metric of a 686 path is the sum of the ETX metrics for each link on this path. 688 While the ETX metric delivers a reasonable performance, it doesn't 689 handle well networks with heterogeneous links that have different 690 bitrates. Since every wireless link, when using ETX metric, is 691 characterized only by its packet loss ratio, the ETX metric prefers 692 long-ranged links with low bitrate (with low loss ratios) over short- 693 ranged links with high bitrate (with higher but reasonable loss 694 ratios). Such conditions, when they occur, can degrade the 695 performance of a network considerably by not taking advantage of 696 higher capacity links. 698 Because of this the OLSR.org project has implemented the Directional 699 Airtime Metric for OLSRv2, which has been inspired by the Estimated 700 Travel Time (ETT) metric [MOBICOM04]. This metric uses an 701 unidirectional packet loss, but also takes the bitrate into account 702 to create a more accurate description of the relative costs or 703 capabilities of mesh links. 705 Authors' Addresses 707 Henning Rogge 708 Fraunhofer FKIE 710 Email: henning.rogge@fkie.fraunhofer.de 711 URI: http://www.fkie.fraunhofer.de 713 Emmanuel Baccelli 714 INRIA 716 Email: Emmanuel.Baccelli@inria.fr 717 URI: http://www.emmanuelbaccelli.org/