idnits 2.17.1 draft-ietf-manet-olsrv2-dat-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 353 has weird spacing: '...eceived is a ...' == Line 357 has weird spacing: '...T_total is a ...' == Line 362 has weird spacing: '...lo_time is th...' == Line 364 has weird spacing: '...nterval is th...' == Line 368 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 (December 12, 2014) is 3422 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TAIL' is mentioned on line 519, 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: June 15, 2015 INRIA 6 December 12, 2014 8 Packet Sequence Number based directional airtime metric for OLSRv2 9 draft-ietf-manet-olsrv2-dat-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 June 15, 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 . . . . . . . . . . . . . . . . 6 55 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 56 6.1. Recommended Values . . . . . . . . . . . . . . . . . . . 7 57 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 8 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 for using DAT metric in OLSRv2 63 implementations . . . . . . . . . . . . . . . . . . . . . 10 64 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 10 65 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 66 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 11 67 10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 11 68 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 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 As specified in [RFC7181] the metric calculates only the incoming 171 link cost. It does neither calculate the outgoing metric, nor does 172 it decide the link status (heard, symmetric, lost). 174 The metric works both for nodes which can send/receive [RFC5444] 175 packet sequence numbers and such which do not have this capability. 176 In the absence of such sequence numbers the metric calculates the 177 packet loss based on Hello message timeouts. 179 The metric must learn about the unicast data rate towards each one- 180 hop neighbor from an external process, either by configuration or by 181 an external measurement process. This measurement could be done by 182 gathering cross-layer data from the operating system or an external 183 daemon like DLEP [DLEP], but also by indirect layer-3 measurements 184 like packet-pair. 186 The metric uses [RFC5444] multicast control traffic to determine the 187 link packet loss. The administrator should take care that link layer 188 multicast transmission do not not have a higher reception probability 189 than the slowest unicast transmission. It might, for example in 190 802.11g, be necessary to increase the data-rate of the multicast 191 transmissions, e.g. set the multicast data-rate to 6 MBit/s. 193 The metric can only handle a certain range of packet loss and unicast 194 data-rate. The maximum packet loss that can be encoded into the 195 metric a loss of 7 of 8 packets, without link layer retransmissions. 196 The unicast data-rate that can be encoded by this metric can be 197 between 1 kBit/s and 2 GBit/s. This metric has been designed for 198 data-rates of 1 MBit/s and hundreds of MBit/s. 200 4. Directional Airtime Metric Rationale 202 The Directional Airtime Metric has been inspired by the publications 203 on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but differs from 204 both of these in several ways. 206 Instead of measuring the combined loss probability of a bidirectional 207 transmission of a packet over a link in both directions, the 208 Directional Airtime Metric measures the incoming loss rate and 209 integrates the incoming linkspeed into the metric cost. There are 210 multiple reasons for this decision: 212 o OLSRv2 [RFC7181] defines the link metric as directional costs 213 between routers. 215 o Not all link layer implementations use acknowledgement mechanisms. 216 Most link layer implementations who do use them use less airtime 217 and a more robust modulation for the acknowledgement than the data 218 transmission, which makes it more likely for the data transmission 219 to be disrupted compared to the acknowledgement. 221 o Incoming packet loss and linkspeed can be measured locally, 222 symmetric link loss would need an additional signaling TLV in the 223 [RFC6130] HELLO and would delay metric calculation by up to one 224 HELLO interval. 226 The Directional Airtime Metric does not integrate the packet size 227 into the link cost. Doing so is not feasible in most link-state 228 routing protocol implementations. The routing decision of most 229 operation systems don't take packet size into account. Multiplying 230 all link costs of a topology with the size of a data-plane packet 231 would never change the dijkstra result anyways. 233 The queue based packet loss estimator has been tested extensively in 234 the OLSR.org ETX implementation, see Appendix A. The output is the 235 average of the packet loss over a configured time period. 237 The metric normally measures the loss of a link by tracking the 238 incoming [RFC5444] packet sequence numbers. Without these packet 239 sequence numbers, the metric does calculate the loss of the link 240 based of received and lost Hello messages. It uses the incoming 241 Hello interval time (or if not present, the validity time) to decide 242 when a Hello is lost. 244 When a neighbor router resets, its packet sequence number might jump 245 to a random value. The metric tries to detect jumps in the packet 246 sequence number and removes them from the data set, because the 247 already gathered link loss data should still be valid. The link loss 248 data is only removed from memory when a Link times out completely and 249 its Link Set tuple is removed from the database. 251 5. Metric Functioning & Overview 253 The Directional Airtime Metric is calculated for each link set entry, 254 as defined in [RFC6130] section 7.1. 256 The metric processes two kinds of data into the metric value, namely 257 packet loss rate and link-speed. While the link-speed is taken from 258 an external process, the current packet loss rate is calculated by 259 keeping track of packet reception and packet loss events. 261 Multiple incoming packet loss/reception events must be combined into 262 a loss rate to get a smooth metric. Experiments with exponential 263 weighted moving average (EWMA) lead to a highly fluctuating or a slow 264 converging metric (or both). To get a smoother and more controllable 265 metric result, this metric uses two fixed length queues to measure 266 and average the incoming packet events, one queue for received 267 packets and one for the estimated number of packets sent by the other 268 side of the link. 270 Because the rate of incoming packets is not uniform over time, the 271 queue contains a number of counters, each representing a fixed time 272 interval. Incoming packet loss and packet reception event are 273 accumulated in the current queue element until a timer adds a new 274 empty counter to both queues and remove the oldest counter from both. 276 In addition to the packet loss stored in the queue, this metric uses 277 a timer to detect a total link-loss. For every NHDP HELLO interval 278 in which the metric received no packet from a neighbor, it scales the 279 number of received packets in the queue based on the total time 280 interval the queue represents compared to the total time of the lost 281 HELLO intervals. 283 The average packet loss ratio is calculated as the sum of the 'total 284 packets' counters divided by the sum of the 'packets received' 285 counters. This value is then divided through the current link-speed 286 and then scaled into the range of metrics allowed for OLSRv2. 288 The metric value is then used as L_in_metric of the Link Set (as 289 defined in section 8.1. of [RFC7181]). 291 6. Protocol Parameters 293 This specification defines two constants, agreement on which is 294 required, from all the OLSRv2 routers participating in the same 295 deployment. Two routers which use different values for these 296 constants will not be able to generate metric values which can be 297 correctly interpreted by both. These constants are: 299 DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All 300 received and lost packets within the queue are used to calculate 301 the cost of the link. 303 DAT_REFRESH_INTERVAL - interval in seconds between two metric 304 recalculations as described in Section 10.2. This value SHOULD be 305 smaller than a typical HELLO interval. 307 DAT_HELLO_TIMEOUT_FACTOR - multiplier relative to the HELLO_INTERVAL 308 (see [RFC6130] Section 5.3.1) after which the DAT metric considers 309 a HELLO as lost. 311 DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets 312 (based on received packet sequence numbers) at which point the 313 router considers the neighbor has restarted. This parameter is 314 only used for packet sequence number based loss estimation. This 315 number MUST be larger than DAT_MAXIMUM_LOSS. 317 6.1. Recommended Values 319 The proposed values of the protocol parameters are for Community Mesh 320 Networks, which mostly use immobile routers. Using this metric for 321 mobile networks might require shorter DAT_REFRESH_INTERVAL and/or 322 DAT_MEMORY_LENGTH. 324 DAT_MEMORY_LENGTH := 64 326 DAT_REFRESH_INTERVAL := 1 328 DAT_HELLO_TIMEOUT_FACTOR := 1.2 330 DAT_SEQNO_RESTART_DETECTION := 256 332 7. Protocol Constants 334 This specification defines the following constants, which define the 335 range of metric values that can be encoded by the DAT metric. They 336 cannot be changed without making the metric outputs incomparable and 337 should only be changed for MANET's with a very slow or very fast 338 linklayer. 340 DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing 341 metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and 342 (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS: 8. 344 DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing 345 metric: 1000. 347 8. Data Structures 349 This specification extends the Link Set of the Interface Information 350 Base, as defined in [RFC6130] section 7.1, by the adding the 351 following elements to each link tuple: 353 L_DAT_received is a QUEUE with DAT_MEMORY_LENGTH integer elements. 354 Each entry contains the number of successfully received packets 355 within an interval of DAT_REFRESH_INTERVAL. 357 L_DAT_total is a QUEUE with DAT_MEMORY_LENGTH integer elements. 358 Each entry contains the estimated number of packets transmitted by 359 the neighbor, based on the received packet sequence numbers within 360 an interval of DAT_REFRESH_INTERVAL. 362 L_DAT_hello_time is the time when the next hello will be expected. 364 L_DAT_hello_interval is the interval between two hello messages of 365 the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] 366 of NHDP messages [RFC6130]. 368 L_DAT_lost_hello_messages is the estimated number of lost hello 369 messages from this neighbor, based on the value of the hello 370 interval. 372 L_DAT_rx_bitrate is the current bitrate of incoming unicast traffic 373 for this neighbor. 375 L_DAT_last_pkt_seqno is the last received packet sequence number 376 received from this link. 378 Methods to obtain the value of L_DAT_rx_bitrate are out of the scope 379 of this specification. Such methods may include static configuration 380 via a configuration file or dynamic measurement through mechanisms 381 described in a separate specification (e.g. [DLEP]). Any Link tuple 382 with L_status = HEARD or L_status = SYMMETRIC MUST have a specified 383 value of L_DAT_rx_bitrate if it is to be used by this routing metric. 385 This specification updates the L_in_metric field of the Link Set of 386 the Interface Information Base, as defined in section 8.1. of 387 [RFC7181]) 389 8.1. Initial Values 391 When generating a new tuple in the Link Set, as defined in [RFC6130] 392 section 12.5 bullet 3, the values of the elements specified in 393 Section 8 are set as follows: 395 o L_DAT_received := 0, ..., 0. The queue always has 396 DAT_MEMORY_LENGTH elements. 398 o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH 399 elements. 401 o L_DAT_last_pkt_seqno := UNDEFINED (no earlier packet received). 403 o L_DAT_hello_time := EXPIRED (no earlier NHDP HELLO received). 405 o L_DAT_hello_interval := UNDEFINED (no earlier NHDP HELLO 406 received). 408 o L_DAT_lost_hello_messages := 0 (no HELLO interval without 409 packets). 411 o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet with 412 sequence number received). 414 9. Packets and Messages 416 This section describes the necessary changes of [RFC7181] 417 implementations with DAT metric for the processing and modification 418 of incoming and outgoing [RFC5444] data. 420 9.1. Definitions 422 For the purpose of this section, note the following definitions: 424 o "pkt_seqno" is defined as the [RFC5444] packet sequence number of 425 the received packet. 427 o "interval_time" is the time encoded in the INTERVAL_TIME message 428 TLV of a received [RFC6130] HELLO message. 430 o "validity_time" is the time encoded in the VALIDITY_TIME message 431 TLV of a received [RFC6130] HELLO message. 433 9.2. Requirements for using DAT metric in OLSRv2 implementations 435 An implementation of OLSRv2 using the metric specified by this 436 document SHOULD include the following parts into its [RFC5444] 437 output: 439 o an INTERVAL_TIME message TLV in each HELLO message, as defined in 440 [RFC6130] section 4.3.2. 442 o an interface specific packet sequence number as defined in 443 [RFC5444] section 5.1 which is incremented by 1 for each outgoing 444 [RFC5444] packet on the interface. 446 9.3. Link Loss Data Gathering 448 For each incoming [RFC5444] packet, additional processing SHOULD be 449 carried out after the packet messages have been processed as 450 specified in [RFC6130] and [RFC7181]. 452 [RFC5444] packets without packet sequence number MUST NOT be 453 processed in this way by this metric. 455 The router updates the Link Set Tuple corresponding to the originator 456 of the packet: 458 1. If L_DAT_last_pkt_seqno = UNDEFINED, then: 460 1. L_DAT_received[TAIL] := 1. 462 2. L_DAT_total[TAIL] := 1. 464 2. Otherwise: 466 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 468 2. diff := seq_diff(pkt_seqno, L_DAT_last_pkt_seqno). 470 3. If diff > DAT_SEQNO_RESTART_DETECTION, then: 472 1. diff := 1. 474 4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff. 476 3. L_DAT_last_pkt_seqno := pkt_seqno. 478 4. If L_DAT_hello_interval != UNDEFINED, then: 480 1. L_DAT_hello_time := current time + (L_DAT_hello_interval * 481 DAT_HELLO_TIMEOUT_FACTOR). 483 5. L_DAT_lost_hello_messages := 0. 485 9.4. HELLO Message Processing 487 For each incoming HELLO Message, after it has been processed as 488 defined in [RFC6130] section 12, the Link Set Tuple corresponding to 489 the incoming HELLO message MUST be updated. 491 1. If the HELLO message contains an INTERVAL_TIME message TLV, then: 493 1. L_DAT_hello_interval := interval_time. 495 2. Otherwise: 497 1. L_DAT_hello_interval := validity_time. 499 3. If L_DAT_last_pkt_seqno = UNDEFINED, then: 501 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 503 2. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1. 505 3. L_DAT_hello_time := current time + (L_DAT_hello_interval * 506 DAT_HELLO_TIMEOUT_FACTOR). 508 10. Timer Event Handling 510 In addition to changes in the [RFC5444] processing/generation code, 511 the DAT metric also uses two timer events. 513 10.1. HELLO Timeout Processing 515 When L_DAT_hello_time has timed out, the following step MUST be done: 517 1. If L_DAT_last_pkt_seqno = UNDEFINED, then: 519 1. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1. 521 2. Otherwise: 523 1. L_DAT_lost_hello_messages := L_DAT_lost_hello_messages + 1. 525 3. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval. 527 10.2. Metric Update 529 Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link 530 Set entries MUST be recalculated: 532 1. sum_received := sum(L_DAT_total). 534 2. sum_total := sum(L_DAT_received). 536 3. If L_DAT_hello_interval != UNDEFINED and 537 L_DAT_lost_hello_messages > 0, then: 539 1. lost_time_proportion := L_DAT_hello_interval * 540 L_DAT_lost_hello_messages / DAT_MEMORY_LENGTH. 542 2. sum_received := sum_received * MAX ( 0, 1 - 543 lost_time_proportion); 545 4. If sum_received < 1, then: 547 1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181] 548 section 5.6.1. 550 5. Otherwise: 552 1. loss := sum_total / sum_received. 554 2. If loss > DAT_MAXIMUM_LOSS, then: 556 1. loss := DAT_MAXIMUM_LOSS. 558 3. bitrate := L_DAT_rx_bitrate. 560 4. If bitrate < DAT_MINIMUM_BITRATE, then: 562 1. bitrate := DAT_MINIMUM_BITRATE. 564 5. L_in_metric := (2^24 / DAT_MAXIMUM_LOSS) * loss / (bitrate / 565 DAT_MINIMUM_BITRATE). 567 6. remove(L_DAT_total) 569 7. add(L_DAT_total, 0) 571 8. remove(L_DAT_received) 572 9. add(L_DAT_received, 0) 574 11. IANA Considerations 576 This document contains no actions for IANA. 578 12. Security Considerations 580 Artificial manipulation of metrics values can drastically alter 581 network performance. In particular, advertising a higher L_in_metric 582 value may decrease the amount of incoming traffic, while advertising 583 lower L_in_metric may increase the amount of incoming traffic. By 584 artificially increasing or decreasing the L_in_metric values it 585 advertises, a rogue router may thus attract or repulse data traffic. 586 A rogue router may then potentially degrade data throughput by not 587 forwarding data as it should or redirecting traffic into routing 588 loops or bad links. 590 An attacker might also inject packets with incorrect packet level 591 sequence numbers, pretending to be somebody else. This attack can be 592 prevented by the true originator of the RFC5444 packets by adding a 593 [RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet. 594 This allows the receiver to drop all incoming packets which have a 595 forged packet source, both packets generated by the attacker or 596 replayed packets. The signature scheme described in [RFC7183] does 597 not protect the additional sequence number of the DAT metric because 598 it does only sign the RFC5444 messages, not the RFC5444 packet 599 header. 601 13. Acknowledgements 603 The authors would like to acknowledge the network administrators from 604 Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for 605 endless hours of testing and suggestions to improve the quality of 606 the original ETX metric for the OLSR.org routing daemon. 608 This effort/activity is supported by the European Community Framework 609 Program 7 within the Future Internet Research and Experimentation 610 Initiative (FIRE), Community Networks Testbed for the Future Internet 611 ([CONFINE]), contract FP7-288535. 613 The authors would like to gratefully acknowledge the following people 614 for intense technical discussions, early reviews and comments on the 615 specification and its components (listed alphabetically): Teco Boot 616 (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), 617 Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology 618 Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus 619 Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research 620 Laboratory) and Stan Ratliff (Cisco Systems). 622 14. References 624 14.1. Normative References 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", RFC 2119, BCP 14, March 1997. 629 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 630 Protocol", RFC 3626, October 2003. 632 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 633 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 634 Format", RFC 5444, February 2009. 636 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 637 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 638 2009. 640 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 641 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 642 RFC 6130, April 2011. 644 [RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized 645 Link State Routing Protocol version 2", RFC 7181, April 646 2014. 648 [RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check 649 Value and Timestamp TLV Definitions for Mobile Ad Hoc 650 Networks (MANETs)", RFC 7182, April 2014. 652 [RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity 653 Protection for the Neighborhood Discovery Protocol (NHDP) 654 and Optimized Link State Routing Protocol Version 2 655 (OLSRv2)", RFC 7183, April 2014. 657 14.2. Informative References 659 [CONFINE] "Community Networks Testbed for the Future Internet 660 (CONFINE)", 2013, . 662 [DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D. 663 Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", 664 draft-ietf-manet-dlep-04 , March 2013. 666 [MOBICOM03] 667 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 668 High-Throughput Path Metric for Multi-Hop Wireless 669 Routing", Proceedings of the MOBICOM Conference , 2003. 671 [MOBICOM04] 672 Richard, D., Jitendra, P., and Z. Brian, "Routing in 673 Multi-Radio, Multi-Hop Wireless Mesh Networks", 674 Proceedings of the MOBICOM Conference , 2004. 676 [OLSR.org] 677 "The OLSR.org OLSR routing daemon", 2013, 678 . 680 [FREIFUNK] 681 "Freifunk Wireless Community Networks", 2013, 682 . 684 [FUNKFEUER] 685 "Austria Wireless Community Network", 2013, 686 . 688 Appendix A. OLSR.org metric history 690 The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR- 691 based [RFC3626] or B.A.T.M.A.N. based wireless community networks 692 with hundreds of routers in permanent operation. The Vienna 693 Funkfeuer network in Austria, for instance, consists of 400 routers 694 (around 600 routes) covering the whole city of Vienna and beyond, 695 spanning roughly 40km in diameter. It has been in operation since 696 2003 and supplies its users with Internet access. A particularity of 697 the Vienna Funkfeuer network is that it manages to provide Internet 698 access through a city wide, large scale Wi-Fi MANET, with just a 699 single Internet uplink. 701 Operational experience of the OLSR project [OLSR.org] with these 702 networks have revealed that the use of hop-count as routing metric 703 leads to unsatisfactory network performance. Experiments with the 704 ETX metric [MOBICOM03] were therefore undertaken in parallel in the 705 Berlin Freifunk network as well as in the Vienna Funkfeuer network in 706 2004, and found satisfactory, i.e., sufficiently easy to implement 707 and providing sufficiently good performance. This metric has now 708 been in operational use in these networks for several years. 710 The ETX metric of a link is the estimated number of transmissions 711 required to successfully send a packet (each packet equal to or 712 smaller than MTU) over that link, until a link layer acknowledgement 713 is received. The ETX metric is additive, i.e., the ETX metric of a 714 path is the sum of the ETX metrics for each link on this path. 716 While the ETX metric delivers a reasonable performance, it doesn't 717 handle well networks with heterogeneous links that have different 718 bitrates. Since every wireless link, when using ETX metric, is 719 characterized only by its packet loss ratio, the ETX metric prefers 720 long-ranged links with low bitrate (with low loss ratios) over short- 721 ranged links with high bitrate (with higher but reasonable loss 722 ratios). Such conditions, when they occur, can degrade the 723 performance of a network considerably by not taking advantage of 724 higher capacity links. 726 Because of this the OLSR.org project has implemented the Directional 727 Airtime Metric for OLSRv2, which has been inspired by the Estimated 728 Travel Time (ETT) metric [MOBICOM04]. This metric uses an 729 unidirectional packet loss, but also takes the bitrate into account 730 to create a more accurate description of the relative costs or 731 capabilities of OLSRv2 links. 733 Appendix B. Linkspeed stabilization 735 The DAT metric describes how to generate a reasonable stable packet 736 loss value from incoming packet reception/loss events, the source of 737 the linkspeed used in this document is considered an external 738 process. 740 In the presence of a layer-2 technology with variable linkspeed it is 741 likely that the raw linkspeed will be fluctuating too fast to be 742 useful for the DAT metric. 744 The amount of stabilization necessary for the linkspeed depends on 745 the implementation of the mac-layer, especially the rate control 746 algorithm. 748 Experiments with the Linux 802.11 wifi stack have shown that a simple 749 Median filter over a series of raw linkspeed measurements can smooth 750 the calculated value without introducing intermediate linkspeed 751 values you would get by using averaging or an exponential weighted 752 moving average. 754 Authors' Addresses 756 Henning Rogge 757 Fraunhofer FKIE 759 Email: henning.rogge@fkie.fraunhofer.de 760 URI: http://www.fkie.fraunhofer.de 761 Emmanuel Baccelli 762 INRIA 764 Email: Emmanuel.Baccelli@inria.fr 765 URI: http://www.emmanuelbaccelli.org/