idnits 2.17.1 draft-ietf-manet-olsrv2-dat-metric-03.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 330 has weird spacing: '...eceived is a ...' == Line 334 has weird spacing: '...T_total is a ...' == Line 339 has weird spacing: '...lo_time is th...' == Line 341 has weird spacing: '...nterval is th...' == Line 345 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 (November 24, 2014) is 3440 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TAIL' is mentioned on line 496, but not defined == Outdated reference: A later version (-29) exists of draft-ietf-manet-dlep-04 Summary: 0 errors (**), 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: Experimental E. Baccelli 5 Expires: May 28, 2015 INRIA 6 November 24, 2014 8 Packet Sequence Number based directional airtime metric for OLSRv2 9 draft-ietf-manet-olsrv2-dat-metric-03 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 May 28, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 53 4. Directional Airtime Metric Rationale . . . . . . . . . . . . 5 54 5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 5 55 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 56 6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7 57 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 7 58 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7 59 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 8 60 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 9 61 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 62 9.2. Requirements for using DAT metric in OLSRv2 63 implementations . . . . . . . . . . . . . . . . . . . . . 9 64 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10 65 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 10 66 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11 67 10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 11 68 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 11 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 14.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 15 76 Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 One of the major shortcomings of OLSR [RFC3626] is the lack of a 82 granular link cost metric between OLSR routers. Operational 83 experience with OLSR networks gathered since the publication of OLSR 84 has revealed that wireless networks links can have highly variable 85 and heterogeneous properties. This makes a hopcount metric 86 insufficient for effective OLSR routing. 88 Based on this experience, OLSRv2 [RFC7181] 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 ETX-derived OLSR.org routing metric for 104 OLSR. It takes both the loss rate and the link speed into account to 105 provide a more accurate picture of the links within the network. 107 This experimental draft will allow OLSRv2 deployments with a metric 108 defined by the IETF Manet group. It enables easier interoperability 109 tests between implementations and will also deliver an useful 110 baseline to compare other metrics to. 112 2. Terminology 114 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 115 NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', 116 and 'OPTIONAL' in this document are to be interpreted as described in 117 [RFC2119]. 119 The terminology introduced in [RFC5444], [RFC7181] and [RFC6130], 120 including the terms "packet", "message" and "TLV" are to be 121 interpreted as described therein. 123 Additionally, this document uses the following terminology and 124 notational conventions: 126 QUEUE - a first in, first out queue of integers. 128 QUEUE[TAIL] - the most recent element in the queue. 130 add(QUEUE, value) - adds a new element to the TAIL of the queue. 132 remove(QUEUE) - removes the HEAD element of the queue 134 sum(QUEUE) - an operation which returns the sum of all elements in a 135 QUEUE. 137 diff_seqno(new, old) - an operation which returns the positive 138 distance between two elements of the circular sequence number 139 space defined in section 5.1 of [RFC5444]. Its value is either 140 (new - old) if this result is positive, or else its value is (new 141 - old + 65536). 143 MAX(a,b) - the maximum of a and b. 145 UNDEFINED - a value not in the normal value range of a variable. 147 airtime - the time a transmitted packet blocks the link layer, e.g., 148 a wireless link. 150 ETX - Expected Transmission Count, a link metric proportional to the 151 number of transmissions to successfully send an IP packet over a 152 link. 154 ETT - Estimated Travel Time, a link metric proportional to the 155 amount of airtime needed to transmit an IP packet over a link, not 156 considering layer-2 overhead created by preamble, backoff time and 157 queuing. 159 DAT - Directional Airtime Metric, the link metric described in this 160 document, which is a directional variant of ETT. It does not take 161 reverse path loss into account. 163 3. Applicability Statement 165 The Directional Airtime Metric was designed and tested in wireless 166 IEEE 802.11 [RFC7181] networks. These networks employ link layer 167 retransmission to increase the delivery probability and multiple 168 unicast data rates. 170 The metric must learn about the unicast data rate towards each one- 171 hop neighbor from an external process, either by configuration or by 172 an external measurement process. This measurement could be done by 173 gathering cross-layer data from the operating system or an external 174 daemon like DLEP [DLEP], but also by indirect layer-3 measurements 175 like packet-pair. 177 If [RFC5444] control traffic is used to determine the link packet 178 loss, the administrator should take care that link layer multicast 179 transmission do not not have a higher reception probability than the 180 slowest unicast transmission. It might, for example in 802.11g, be 181 necessary to increase the data-rate of the multicast transmissions, 182 e.g. set the multicast data-rate to 6 MBit/s. 184 The Directional Airtime metric can only handle a certain range of 185 packet loss and unicast data-rate. The maximum packet loss that can 186 be encoded into the metric a loss of 7 of 8 packets, without link 187 layer retransmissions. The unicast data-rate that can be encoded by 188 this metric can be between 1 kBit/s and 2 GBit/s. This metric has 189 been designed for data-rates of 1 MBit/s and hundreds of MBit/s. 191 4. Directional Airtime Metric Rationale 193 The Directional Airtime Metric has been inspired by the publications 194 on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but differs from 195 both of these in several ways. 197 Instead of measuring the combined loss probability of a bidirectional 198 transmission of a packet over a link in both directions, the 199 Directional Airtime Metric measures the incoming loss rate and 200 integrates the incoming linkspeed into the metric cost. There are 201 multiple reasons for this decision: 203 o OLSRv2 [RFC7181] defines the link metric as directional costs 204 between routers. 206 o Not all link layer implementations use acknowledgement mechanisms. 207 Most link layer implementations who do use them use less airtime 208 and a more robust modulation for the acknowledgement than the data 209 transmission, which makes it more likely for the data transmission 210 to be disrupted compared to the acknowledgement. 212 o Incoming packet loss and linkspeed can be measured locally, 213 symmetric link loss would need an additional signaling TLV in the 214 [RFC6130] HELLO and would delay metric calculation by up to one 215 HELLO interval. 217 The Directional Airtime Metric does not integrate the packet size 218 into the link cost. Doing so is not feasible in most link-state 219 routing protocol implementations. The routing decision of most 220 operation systems don't take packet size into account. Multiplying 221 all link costs of a topology with the size of a data-plane packet 222 would never change the dijkstra result anyways. 224 The queue based packet loss estimator has been tested extensively in 225 the OLSR.org ETX implementation, see Appendix A. The output is the 226 average of the packet loss over a configured time period. 228 5. Metric Functioning & Overview 230 The Directional Airtime Metric is calculated for each link set entry, 231 as defined in [RFC6130] section 7.1. 233 The metric processes two kinds of data into the metric value, namely 234 packet loss rate and link-speed. While the link-speed is taken from 235 an external process, the current packet loss rate is calculated by 236 keeping track of packet reception and packet loss events. 238 Multiple incoming packet loss/reception events must be combined into 239 a loss rate to get a smooth metric. Experiments with exponential 240 weighted moving average (EWMA) lead to a highly fluctuating or a slow 241 converging metric (or both). To get a smoother and more controllable 242 metric result, this metric uses two fixed length queues to measure 243 and average the incoming packet events, one queue for received 244 packets and one for the estimated number of packets sent by the other 245 side of the link. 247 Because the rate of incoming packets is not uniform over time, the 248 queue contains a number of counters, each representing a fixed time 249 interval. Incoming packet loss and packet reception event are 250 accumulated in the current queue element until a timer adds a new 251 empty counter to both queues and remove the oldest counter from both. 253 In addition to the packet loss stored in the queue, this metric uses 254 a timer to detect a total link-loss. For every NHDP HELLO interval 255 in which the metric received no packet from a neighbor, it scales the 256 number of received packets in the queue based on the total time 257 interval the queue represents compared to the total time of the lost 258 HELLO intervals. 260 The average packet loss ratio is calculated as the sum of the 'total 261 packets' counters divided by the sum of the 'packets received' 262 counters. This value is then divided through the current link-speed 263 and then scaled into the range of metrics allowed for OLSRv2. 265 The metric value is then used as L_in_metric of the Link Set (as 266 defined in section 8.1. of [RFC7181]). 268 6. Protocol Parameters 270 This specification defines two constants, agreement on which is 271 required, from all the OLSRv2 routers participating in the same 272 deployment. Two routers which use different values for these 273 constants will not be able to generate metric values which can be 274 correctly interpreted by both. These constants are: 276 DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All 277 received and lost packets within the queue are used to calculate 278 the cost of the link. 280 DAT_REFRESH_INTERVAL - interval in seconds between two metric 281 recalculations as described in Section 10.2. This value SHOULD be 282 smaller than a typical HELLO interval. 284 DAT_HELLO_TIMEOUT_FACTOR - multiplier relative to the HELLO_INTERVAL 285 (see [RFC6130] Section 5.3.1) after which the DAT metric considers 286 a HELLO as lost. 288 DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets 289 (based on received packet sequence numbers) at which point the 290 router considers the neighbor has restarted. This parameter is 291 only used for packet sequence number based loss estimation. This 292 number MUST be larger than DAT_MAXIMUM_LOSS. 294 6.1. Recommended Values 296 The proposed values of the protocol parameters are for Community Mesh 297 Networks, which mostly use immobile routers. Using this metric for 298 mobile networks might require shorter DAT_REFRESH_INTERVAL and/or 299 DAT_MEMORY_LENGTH. 301 DAT_MEMORY_LENGTH := 64 303 DAT_REFRESH_INTERVAL := 1 305 DAT_HELLO_TIMEOUT_FACTOR := 1.2 307 DAT_SEQNO_RESTART_DETECTION := 256 309 7. Protocol Constants 311 This specification defines the following constants, which define the 312 range of metric values that can be encoded by the DAT metric. They 313 cannot be changed without making the metric outputs incomparable and 314 should only be changed for MANET's with a very slow or very fast 315 linklayer. 317 DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing 318 metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and 319 (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS: 8. 321 DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing 322 metric: 1000. 324 8. Data Structures 326 This specification extends the Link Set of the Interface Information 327 Base, as defined in [RFC6130] section 7.1, by the adding the 328 following elements to each link tuple: 330 L_DAT_received is a QUEUE with DAT_MEMORY_LENGTH integer elements. 331 Each entry contains the number of successfully received packets 332 within an interval of DAT_REFRESH_INTERVAL. 334 L_DAT_total is a QUEUE with DAT_MEMORY_LENGTH integer elements. 335 Each entry contains the estimated number of packets transmitted by 336 the neighbor, based on the received packet sequence numbers within 337 an interval of DAT_REFRESH_INTERVAL. 339 L_DAT_hello_time is the time when the next hello will be expected. 341 L_DAT_hello_interval is the interval between two hello messages of 342 the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] 343 of NHDP messages [RFC6130]. 345 L_DAT_lost_hello_messages is the estimated number of lost hello 346 messages from this neighbor, based on the value of the hello 347 interval. 349 L_DAT_rx_bitrate is the current bitrate of incoming unicast traffic 350 for this neighbor. 352 L_DAT_last_pkt_seqno is the last received packet sequence number 353 received from this link. 355 Methods to obtain the value of L_DAT_rx_bitrate are out of the scope 356 of this specification. Such methods may include static configuration 357 via a configuration file or dynamic measurement through mechanisms 358 described in a separate specification (e.g. [DLEP]). Any Link tuple 359 with L_status = HEARD or L_status = SYMMETRIC MUST have a specified 360 value of L_DAT_rx_bitrate if it is to be used by this routing metric. 362 This specification updates the L_in_metric field of the Link Set of 363 the Interface Information Base, as defined in section 8.1. of 364 [RFC7181]) 366 8.1. Initial Values 368 When generating a new tuple in the Link Set, as defined in [RFC6130] 369 section 12.5 bullet 3, the values of the elements specified in 370 Section 8 are set as follows: 372 o L_DAT_received := 0, ..., 0. The queue always has 373 DAT_MEMORY_LENGTH elements. 375 o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH 376 elements. 378 o L_DAT_last_pkt_seqno := UNDEFINED (no earlier packet received). 380 o L_DAT_hello_time := EXPIRED (no earlier NHDP HELLO received). 382 o L_DAT_hello_interval := UNDEFINED (no earlier NHDP HELLO 383 received). 385 o L_DAT_lost_hello_messages := 0 (no HELLO interval without 386 packets). 388 o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet with 389 sequence number received). 391 9. Packets and Messages 393 This section describes the necessary changes of [RFC7181] 394 implementations with DAT metric for the processing and modification 395 of incoming and outgoing [RFC5444] data. 397 9.1. Definitions 399 For the purpose of this section, note the following definitions: 401 o "pkt_seqno" is defined as the [RFC5444] packet sequence number of 402 the received packet. 404 o "interval_time" is the time encoded in the INTERVAL_TIME message 405 TLV of a received [RFC6130] HELLO message. 407 o "validity_time" is the time encoded in the VALIDITY_TIME message 408 TLV of a received [RFC6130] HELLO message. 410 9.2. Requirements for using DAT metric in OLSRv2 implementations 412 An implementation of OLSRv2 using the metric specified by this 413 document SHOULD include the following parts into its [RFC5444] 414 output: 416 o an INTERVAL_TIME message TLV in each HELLO message, as defined in 417 [RFC6130] section 4.3.2. 419 o an interface specific packet sequence number as defined in 420 [RFC5444] section 5.1 which is incremented by 1 for each outgoing 421 [RFC5444] packet on the interface. 423 9.3. Link Loss Data Gathering 425 For each incoming [RFC5444] packet, additional processing SHOULD be 426 carried out after the packet messages have been processed as 427 specified in [RFC6130] and [RFC7181]. 429 [RFC5444] packets without packet sequence number MUST NOT be 430 processed in this way by this metric. 432 The router updates the Link Set Tuple corresponding to the originator 433 of the packet: 435 1. If L_DAT_last_pkt_seqno = UNDEFINED, then: 437 1. L_DAT_received[TAIL] := 1. 439 2. L_DAT_total[TAIL] := 1. 441 2. Otherwise: 443 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 445 2. diff := seq_diff(pkt_seqno, L_DAT_last_pkt_seqno). 447 3. If diff > DAT_SEQNO_RESTART_DETECTION, then: 449 1. diff := 1. 451 4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff. 453 3. L_DAT_last_pkt_seqno := pkt_seqno. 455 4. If L_DAT_hello_interval != UNDEFINED, then: 457 1. L_DAT_hello_time := current time + (L_DAT_hello_interval * 458 DAT_HELLO_TIMEOUT_FACTOR). 460 5. L_DAT_lost_hello_messages := 0. 462 9.4. HELLO Message Processing 464 For each incoming HELLO Message, after it has been processed as 465 defined in [RFC6130] section 12, the Link Set Tuple corresponding to 466 the incoming HELLO message MUST be updated. 468 1. If the HELLO message contains an INTERVAL_TIME message TLV, then: 470 1. L_DAT_hello_interval := interval_time. 472 2. Otherwise: 474 1. L_DAT_hello_interval := validity_time. 476 3. If L_DAT_last_pkt_seqno = UNDEFINED, then: 478 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 480 2. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1. 482 3. L_DAT_hello_time := current time + (L_DAT_hello_interval * 483 DAT_HELLO_TIMEOUT_FACTOR). 485 10. Timer Event Handling 487 In addition to changes in the [RFC5444] processing/generation code, 488 the DAT metric also uses two timer events. 490 10.1. HELLO Timeout Processing 492 When L_DAT_hello_time has timed out, the following step MUST be done: 494 1. If L_DAT_last_pkt_seqno = UNDEFINED, then: 496 1. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1. 498 2. Otherwise: 500 1. L_DAT_lost_hello_messages := L_DAT_lost_hello_messages + 1. 502 3. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval. 504 10.2. Metric Update 506 Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link 507 Set entries MUST be recalculated: 509 1. sum_received := sum(L_DAT_total). 511 2. sum_total := sum(L_DAT_received). 513 3. If L_DAT_hello_interval != UNDEFINED and 514 L_DAT_lost_hello_messages > 0, then: 516 1. lost_time_proportion := L_DAT_hello_interval * 517 L_DAT_lost_hello_messages / DAT_MEMORY_LENGTH. 519 2. sum_received := sum_received * MAX ( 0, 1 - 520 lost_time_proportion); 522 4. If sum_received < 1, then: 524 1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181] 525 section 5.6.1. 527 5. Otherwise: 529 1. loss := sum_total / sum_received. 531 2. If loss > DAT_MAXIMUM_LOSS, then: 533 1. loss := DAT_MAXIMUM_LOSS. 535 3. bitrate := L_DAT_rx_bitrate. 537 4. If bitrate < DAT_MINIMUM_BITRATE, then: 539 1. bitrate := DAT_MINIMUM_BITRATE. 541 5. L_in_metric := (2^24 / DAT_MAXIMUM_LOSS) * loss / (bitrate / 542 DAT_MINIMUM_BITRATE). 544 6. remove(L_DAT_total) 546 7. add(L_DAT_total, 0) 548 8. remove(L_DAT_received) 550 9. add(L_DAT_received, 0) 552 11. IANA Considerations 554 This document contains no actions for IANA. 556 12. Security Considerations 558 Artificial manipulation of metrics values can drastically alter 559 network performance. In particular, advertising a higher L_in_metric 560 value may decrease the amount of incoming traffic, while advertising 561 lower L_in_metric may increase the amount of incoming traffic. By 562 artificially increasing or decreasing the L_in_metric values it 563 advertises, a rogue router may thus attract or repulse data traffic. 564 A rogue router may then potentially degrade data throughput by not 565 forwarding data as it should or redirecting traffic into routing 566 loops or bad links. 568 An attacker might also inject packets with incorrect packet level 569 sequence numbers, pretending to be somebody else. This attack can be 570 prevented by the true originator of the RFC5444 packets by adding a 571 [RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet. 572 This allows the receiver to drop all incoming packets which have a 573 forged packet source, both packets generated by the attacker or 574 replayed packets. The signature scheme described in [RFC7183] does 575 not protect the additional sequence number of the DAT metric because 576 it does only sign the RFC5444 messages, not the RFC5444 packet 577 header. 579 13. Acknowledgements 581 The authors would like to acknowledge the network administrators from 582 Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for 583 endless hours of testing and suggestions to improve the quality of 584 the original ETX metric for the OLSR.org routing daemon. 586 This effort/activity is supported by the European Community Framework 587 Program 7 within the Future Internet Research and Experimentation 588 Initiative (FIRE), Community Networks Testbed for the Future Internet 589 ([CONFINE]), contract FP7-288535. 591 The authors would like to gratefully acknowledge the following people 592 for intense technical discussions, early reviews and comments on the 593 specification and its components (listed alphabetically): Teco Boot 594 (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), 595 Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology 596 Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus 597 Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research 598 Laboratory) and Stan Ratliff (Cisco Systems). 600 14. References 602 14.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", RFC 2119, BCP 14, March 1997. 607 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 608 Protocol", RFC 3626, October 2003. 610 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 611 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 612 Format", RFC 5444, February 2009. 614 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 615 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 616 2009. 618 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 619 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 620 RFC 6130, April 2011. 622 [RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized 623 Link State Routing Protocol version 2", RFC 7181, April 624 2014. 626 [RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check 627 Value and Timestamp TLV Definitions for Mobile Ad Hoc 628 Networks (MANETs)", RFC 7182, April 2014. 630 [RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity 631 Protection for the Neighborhood Discovery Protocol (NHDP) 632 and Optimized Link State Routing Protocol Version 2 633 (OLSRv2)", RFC 7183, April 2014. 635 14.2. Informative References 637 [CONFINE] "Community Networks Testbed for the Future Internet 638 (CONFINE)", 2013, . 640 [DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D. 641 Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", 642 draft-ietf-manet-dlep-04 , March 2013. 644 [MOBICOM03] 645 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 646 High-Throughput Path Metric for Multi-Hop Wireless 647 Routing", Proceedings of the MOBICOM Conference , 2003. 649 [MOBICOM04] 650 Richard, D., Jitendra, P., and Z. Brian, "Routing in 651 Multi-Radio, Multi-Hop Wireless Mesh Networks", 652 Proceedings of the MOBICOM Conference , 2004. 654 [OLSR.org] 655 "The OLSR.org OLSR routing daemon", 2013, 656 . 658 [FREIFUNK] 659 "Freifunk Wireless Community Networks", 2013, 660 . 662 [FUNKFEUER] 663 "Austria Wireless Community Network", 2013, 664 . 666 Appendix A. OLSR.org metric history 668 The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR- 669 based [RFC3626] or B.A.T.M.A.N. based wireless community networks 670 with hundreds of routers in permanent operation. The Vienna 671 Funkfeuer network in Austria, for instance, consists of 400 routers 672 (around 600 routes) covering the whole city of Vienna and beyond, 673 spanning roughly 40km in diameter. It has been in operation since 674 2003 and supplies its users with Internet access. A particularity of 675 the Vienna Funkfeuer network is that it manages to provide Internet 676 access through a city wide, large scale Wi-Fi MANET, with just a 677 single Internet uplink. 679 Operational experience of the OLSR project [OLSR.org] with these 680 networks have revealed that the use of hop-count as routing metric 681 leads to unsatisfactory network performance. Experiments with the 682 ETX metric [MOBICOM03] were therefore undertaken in parallel in the 683 Berlin Freifunk network as well as in the Vienna Funkfeuer network in 684 2004, and found satisfactory, i.e., sufficiently easy to implement 685 and providing sufficiently good performance. This metric has now 686 been in operational use in these networks for several years. 688 The ETX metric of a link is the estimated number of transmissions 689 required to successfully send a packet (each packet equal to or 690 smaller than MTU) over that link, until a link layer acknowledgement 691 is received. The ETX metric is additive, i.e., the ETX metric of a 692 path is the sum of the ETX metrics for each link on this path. 694 While the ETX metric delivers a reasonable performance, it doesn't 695 handle well networks with heterogeneous links that have different 696 bitrates. Since every wireless link, when using ETX metric, is 697 characterized only by its packet loss ratio, the ETX metric prefers 698 long-ranged links with low bitrate (with low loss ratios) over short- 699 ranged links with high bitrate (with higher but reasonable loss 700 ratios). Such conditions, when they occur, can degrade the 701 performance of a network considerably by not taking advantage of 702 higher capacity links. 704 Because of this the OLSR.org project has implemented the Directional 705 Airtime Metric for OLSRv2, which has been inspired by the Estimated 706 Travel Time (ETT) metric [MOBICOM04]. This metric uses an 707 unidirectional packet loss, but also takes the bitrate into account 708 to create a more accurate description of the relative costs or 709 capabilities of OLSRv2 links. 711 Appendix B. Linkspeed stabilization 713 The DAT metric describes how to generate a reasonable stable packet 714 loss value from incoming packet reception/loss events, the source of 715 the linkspeed used in this document is considered an external 716 process. 718 In the presence of a layer-2 technology with variable linkspeed it is 719 likely that the raw linkspeed will be fluctuating too fast to be 720 useful for the DAT metric. 722 The amount of stabilization necessary for the linkspeed depends on 723 the implementation of the mac-layer, especially the rate control 724 algorithm. 726 Experiments with the Linux 802.11 wifi stack have shown that a simple 727 Median filter over a series of raw linkspeed measurements can smooth 728 the calculated value without introducing intermediate linkspeed 729 values you would get by using averaging or an exponential weighted 730 moving average. 732 Authors' Addresses 734 Henning Rogge 735 Fraunhofer FKIE 737 Email: henning.rogge@fkie.fraunhofer.de 738 URI: http://www.fkie.fraunhofer.de 740 Emmanuel Baccelli 741 INRIA 743 Email: Emmanuel.Baccelli@inria.fr 744 URI: http://www.emmanuelbaccelli.org/