idnits 2.17.1 draft-ietf-manet-olsrv2-dat-metric-02.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 333 has weird spacing: '...eceived is a ...' == Line 337 has weird spacing: '...T_total is a ...' == Line 342 has weird spacing: '...lo_time is th...' == Line 344 has weird spacing: '...nterval is th...' == Line 348 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 (August 8, 2014) is 3549 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TAIL' is mentioned on line 492, 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: February 9, 2015 INRIA 6 August 8, 2014 8 Packet Sequence Number based directional airtime metric for OLSRv2 9 draft-ietf-manet-olsrv2-dat-metric-02 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 February 9, 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 . . . . . . . . . . . . . . . . 9 65 9.3.1. Packet Sequence based link loss . . . . . . . . . . . 10 66 9.3.2. HELLO based Link Loss . . . . . . . . . . . . . . . . 11 67 9.3.3. Other Measurement of Link Loss . . . . . . . . . . . 11 68 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 69 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12 70 10.1. HELLO Timeout Processing . . . . . . . . . . . . . . . . 12 71 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 14.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Appendix A. OLSR.org metric history . . . . . . . . . . . . . . 15 79 Appendix B. Linkspeed stabilization . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 One of the major shortcomings of OLSR [RFC3626] is the lack of a 85 granular link cost metric between OLSR routers. Operational 86 experience with OLSR networks gathered since the publication of OLSR 87 has revealed that wireless networks links can have highly variable 88 and heterogeneous properties. This makes a hopcount metric 89 insufficient for effective OLSR routing. 91 Based on this experience, OLSRv2 [RFC7181] integrates the concept of 92 link metrics directly into the core specification of the routing 93 protocol. The OLSRv2 routing metric is an external process, it can 94 be any kind of dimensionless additive cost function which reports to 95 the OLSRv2 protocol. 97 Since 2004 the OLSR.org [OLSR.org] implementation of OLSR included an 98 Estimated Transmission Count (ETX) metric [MOBICOM04] as a 99 proprietary extension. While this metric is not perfect, it proved 100 to be sufficient for a long time for Community Mesh Networks 101 (Appendix A). But the increasing maximum data rate of IEEE 802.11 102 made the ETX metric less efficient than in the past, which is one 103 reason to move to a different metric. 105 This document describes a Directional Airtime routing metric for 106 OLSRv2, a successor of the ETX-derived OLSR.org routing metric for 107 OLSR. It takes both the loss rate and the link speed into account to 108 provide a more accurate picture of the links within the network. 110 This experimental draft will allow OLSRv2 deployments with a metric 111 defined by the IETF Manet group. It enables easier interoperability 112 tests between implementations and will also deliver an useful 113 baseline to compare other metrics to. 115 2. Terminology 117 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 118 NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', 119 and 'OPTIONAL' in this document are to be interpreted as described in 120 [RFC2119]. 122 The terminology introduced in [RFC5444], [RFC7181] and [RFC6130], 123 including the terms "packet", "message" and "TLV" are to be 124 interpreted as described therein. 126 Additionally, this document uses the following terminology and 127 notational conventions: 129 QUEUE - a first in, first out queue of integers. 131 QUEUE[TAIL] - the most recent element in the queue. 133 add(QUEUE, value) - adds a new element to the TAIL of the queue. 135 remove(QUEUE) - removes the HEAD element of the queue 137 sum(QUEUE) - an operation which returns the sum of all elements in a 138 QUEUE. 140 diff_seqno(new, old) - an operation which returns the positive 141 distance between two elements of the circular sequence number 142 space defined in section 5.1 of [RFC5444]. Its value is either 143 (new - old) if this result is positive, or else its value is (new 144 - old + 65536). 146 MAX(a,b) - the maximum of a and b. 148 UNDEFINED - a value not in the normal value range of a variable. 150 airtime - the time a transmitted packet blocks the link layer, e.g., 151 a wireless link. 153 ETX - Expected Transmission Count, a link metric proportional to the 154 number of transmissions to successfully send an IP packet over a 155 link. 157 ETT - Estimated Travel Time, a link metric proportional to the 158 amount of airtime needed to transmit an IP packet over a link, not 159 considering layer-2 overhead created by preamble, backoff time and 160 queuing. 162 DAT - Directional Airtime Metric, the link metric described in this 163 document, which is a directional variant of ETT. It does not take 164 reverse path loss into account. 166 3. Applicability Statement 168 The Directional Airtime Metric was designed and tested in wireless 169 IEEE 802.11 [RFC7181] networks. These networks employ link layer 170 retransmission to increase the delivery probability and multiple 171 unicast data rates. 173 The metric must learn about the unicast data rate towards each one- 174 hop neighbor from an external process, either by configuration or by 175 an external measurement process. This measurement could be done by 176 gathering cross-layer data from the operating system or an external 177 daemon like DLEP [DLEP], but also by indirect layer-3 measurements 178 like packet-pair. 180 If [RFC5444] control traffic is used to determine the link packet 181 loss, the administrator should take care that link layer multicast 182 transmission do not not have a higher reception probability than the 183 slowest unicast transmission. It might, for example in 802.11g, be 184 necessary to increase the data-rate of the multicast transmissions, 185 e.g. set the multicast data-rate to 6 MBit/s. 187 The Directional Airtime metric can only handle a certain range of 188 packet loss and unicast data-rate. The maximum packet loss that can 189 be encoded into the metric a loss of 7 of 8 packets, without link 190 layer retransmissions. The unicast data-rate that can be encoded by 191 this metric can be between 1 kBit/s and 2 GBit/s. This metric has 192 been designed for data-rates of 1 MBit/s and hundreds of MBit/s. 194 4. Directional Airtime Metric Rationale 196 The Directional Airtime Metric has been inspired by the publications 197 on the ETX [MOBICOM03] and ETT [MOBICOM04] metric, but differs from 198 both of these in several ways. 200 Instead of measuring the combined loss probability of a bidirectional 201 transmission of a packet over a link in both directions, the 202 Directional Airtime Metric measures the incoming loss rate and 203 integrates the incoming linkspeed into the metric cost. There are 204 multiple reasons for this decision: 206 o OLSRv2 [RFC7181] defines the link metric as directional costs 207 between routers. 209 o Not all link layer implementations use acknowledgement mechanisms. 210 Most link layer implementations who do use them use less airtime 211 and a more robust modulation for the acknowledgement than the data 212 transmission, which makes it more likely for the data transmission 213 to be disrupted compared to the acknowledgement. 215 o Incoming packet loss and linkspeed can be measured locally, 216 symmetric link loss would need an additional signaling TLV in the 217 [RFC6130] HELLO and would delay metric calculation by up to one 218 HELLO interval. 220 The Directional Airtime Metric does not integrate the packet size 221 into the link cost. Doing so is not feasible in most link-state 222 routing protocol implementations. The routing decision of most 223 operation systems don't take packet size into account. Multiplying 224 all link costs of a topology with the size of a data-plane packet 225 would never change the dijkstra result anyways. 227 The queue based packet loss estimator has been tested extensively in 228 the OLSR.org ETX implementation, see Appendix A. The output is the 229 average of the packet loss over a configured time period. 231 5. Metric Functioning & Overview 233 The Directional Airtime Metric is calculated for each link set entry, 234 as defined in [RFC6130] section 7.1. 236 The metric processes two kinds of data into the metric value, namely 237 packet loss rate and link-speed. While the link-speed is taken from 238 an external process, the current packet loss rate is calculated by 239 keeping track of packet reception and packet loss events. 241 Multiple incoming packet loss/reception events must be combined into 242 a loss rate to get a smooth metric. Experiments with exponential 243 weighted moving average (EWMA) lead to a highly fluctuating or a slow 244 converging metric (or both). To get a smoother and more controllable 245 metric result, this metric uses two fixed length queues to measure 246 and average the incoming packet events, one queue for received 247 packets and one for the estimated number of packets sent by the other 248 side of the link. 250 Because the rate of incoming packets is not uniform over time, the 251 queue contains a number of counters, each representing a fixed time 252 interval. Incoming packet loss and packet reception event are 253 accumulated in the current queue element until a timer adds a new 254 empty counter to both queues and remove the oldest counter from both. 256 In addition to the packet loss stored in the queue, this metric uses 257 a timer to detect a total link-loss. For every NHDP HELLO interval 258 in which the metric received no packet from a neighbor, it scales the 259 number of received packets in the queue based on the total time 260 interval the queue represents compared to the total time of the lost 261 HELLO intervals. 263 The average packet loss ratio is calculated as the sum of the 'total 264 packets' counters divided by the sum of the 'packets received' 265 counters. This value is then divided through the current link-speed 266 and then scaled into the range of metrics allowed for OLSRv2. 268 The metric value is then used as L_in_metric of the Link Set (as 269 defined in section 8.1. of [RFC7181]). 271 6. Protocol Parameters 273 This specification defines two constants, agreement on which is 274 required, from all the OLSRv2 routers participating in the same 275 deployment. Two routers which use different values for these 276 constants will not be able to generate metric values which can be 277 correctly interpreted by both. These constants are: 279 DAT_MEMORY_LENGTH - Queue length for averaging packet loss. All 280 received and lost packets within the queue are used to calculate 281 the cost of the link. 283 DAT_REFRESH_INTERVAL - interval in seconds between two metric 284 recalculations as described in Section 10.2. This value SHOULD be 285 smaller than a typical HELLO interval. 287 DAT_HELLO_TIMEOUT_FACTOR - multiplier relative to the HELLO_INTERVAL 288 (see [RFC6130] Section 5.3.1) after which the DAT metric considers 289 a HELLO as lost. 291 DAT_SEQNO_RESTART_DETECTION - threshold in number of missing packets 292 (based on received packet sequence numbers) at which point the 293 router considers the neighbor has restarted. This parameter is 294 only used for packet sequence number based loss estimation. This 295 number MUST be larger than DAT_MAXIMUM_LOSS. 297 6.1. Recommended Values 299 The proposed values of the protocol parameters are for Community Mesh 300 Networks, which mostly use immobile routers. Using this metric for 301 mobile networks might require shorter DAT_REFRESH_INTERVAL and/or 302 DAT_MEMORY_LENGTH. 304 DAT_MEMORY_LENGTH := 64 306 DAT_REFRESH_INTERVAL := 1 308 DAT_HELLO_TIMEOUT_FACTOR := 1.2 310 DAT_SEQNO_RESTART_DETECTION := 256 312 7. Protocol Constants 314 This specification defines the following constants, which define the 315 range of metric values that can be encoded by the DAT metric. They 316 cannot be changed without making the metric outputs incomparable and 317 should only be changed for MANET's with a very slow or very fast 318 linklayer. 320 DAT_MAXIMUM_LOSS - Fraction of the loss rate used in this routing 321 metric. Loss rate will be between 0/DAT_MAXIMUM_LOSS and 322 (DAT_MAXIMUM_LOSS-1)/DAT_MAXIMUM_LOSS: 8. 324 DAT_MINIMUM_BITRATE - Minimal bit-rate in Bit/s used by this routing 325 metric: 1000. 327 8. Data Structures 329 This specification extends the Link Set of the Interface Information 330 Base, as defined in [RFC6130] section 7.1, by the adding the 331 following elements to each link tuple: 333 L_DAT_received is a QUEUE with DAT_MEMORY_LENGTH integer elements. 334 Each entry contains the number of successfully received packets 335 within an interval of DAT_REFRESH_INTERVAL. 337 L_DAT_total is a QUEUE with DAT_MEMORY_LENGTH integer elements. 338 Each entry contains the estimated number of packets transmitted by 339 the neighbor, based on the received packet sequence numbers within 340 an interval of DAT_REFRESH_INTERVAL. 342 L_DAT_hello_time is the time when the next hello will be expected. 344 L_DAT_hello_interval is the interval between two hello messages of 345 the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497] 346 of NHDP messages [RFC6130]. 348 L_DAT_lost_hello_messages is the estimated number of lost hello 349 messages from this neighbor, based on the value of the hello 350 interval. 352 L_DAT_rx_bitrate is the current bitrate of incoming unicast traffic 353 for this neighbor. 355 L_DAT_last_pkt_seqno is the last received packet sequence number 356 received from this link. 358 Methods to obtain the value of L_DAT_rx_bitrate are out of the scope 359 of this specification. Such methods may include static configuration 360 via a configuration file or dynamic measurement through mechanisms 361 described in a separate specification (e.g. [DLEP]). Any Link tuple 362 with L_status = HEARD or L_status = SYMMETRIC MUST have a specified 363 value of L_DAT_rx_bitrate if it is to be used by this routing metric. 365 This specification updates the L_in_metric field of the Link Set of 366 the Interface Information Base, as defined in section 8.1. of 367 [RFC7181]) 369 8.1. Initial Values 371 When generating a new tuple in the Link Set, as defined in [RFC6130] 372 section 12.5 bullet 3, the values of the elements specified in 373 Section 8 are set as follows: 375 o L_DAT_received := 0, ..., 0. The queue always has 376 DAT_MEMORY_LENGTH elements. 378 o L_DAT_total := 0, ..., 0. The queue always has DAT_MEMORY_LENGTH 379 elements. 381 o L_DAT_last_pkt_seqno := UNDEFINED (no earlier packet received). 383 o L_DAT_hello_time := EXPIRED (no earlier NHDP HELLO received). 385 o L_DAT_hello_interval := UNDEFINED (no earlier NHDP HELLO 386 received). 388 o L_DAT_lost_hello_messages := 0 (no HELLO interval without 389 packets). 391 o L_DAT_last_pkt_seqno := UNDEFINED (no earlier RFC5444 packet 392 received). 394 9. Packets and Messages 396 This section describes the necessary changes of [RFC7181] 397 implementations with DAT metric for the processing and modification 398 of incoming and outgoing [RFC5444] data. 400 9.1. Definitions 402 For the purpose of this section, note the following definitions: 404 o "pkt_seqno" is defined as the [RFC5444] packet sequence number of 405 the received packet. 407 o "interval_time" is the time encoded in the INTERVAL_TIME message 408 TLV of a received [RFC6130] HELLO message. 410 o "validity_time" is the time encoded in the VALIDITY_TIME message 411 TLV of a received [RFC6130] HELLO message. 413 9.2. Requirements for using DAT metric in OLSRv2 implementations 415 An implementation of OLSRv2 using the metric specified by this 416 document SHOULD include the following parts into its [RFC5444] 417 output: 419 o an INTERVAL_TIME message TLV in each HELLO message, as defined in 420 [RFC6130] section 4.3.2. 422 9.3. Link Loss Data Gathering 424 While this metric was designed for measuring the packet loss based on 425 the [RFC5444] packet sequence number, some implementations might not 426 be able to add the packet sequence number to their output. Because 427 of this the following section contains multiple alternatives to 428 calculate the packet loss. 430 9.3.1. Packet Sequence based link loss 432 An implementation of OLSRv2, using the metric specified by this 433 document with packet sequence based link loss, MUST include the 434 following element into its [RFC5444] output: 436 o an interface specific packet sequence number as defined in 437 [RFC5444] section 5.1 which is incremented by 1 for each outgoing 438 [RFC5444] packet on the interface. 440 For each incoming [RFC5444] packet, additional processing MUST be 441 carried out after the packet messages have been processed as 442 specified in [RFC6130] and [RFC7181]. 444 [RFC5444] packets without packet sequence number MUST NOT be 445 processed in this way by this metric. 447 The router MUST update the Link Set Tuple corresponding to the 448 originator of the packet: 450 1. If L_DAT_last_pkt_seqno = UNDEFINED, then: 452 1. L_DAT_received[TAIL] := 1. 454 2. L_DAT_total[TAIL] := 1. 456 2. Otherwise: 458 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 460 2. diff := seq_diff(pkt_seqno, L_DAT_last_pkt_seqno). 462 3. If diff > DAT_SEQNO_RESTART_DETECTION, then: 464 1. diff := 1. 466 4. L_DAT_total[TAIL] := L_DAT_total[TAIL] + diff. 468 3. L_DAT_last_pkt_seqno := pkt_seqno. 470 4. If L_DAT_hello_interval != UNDEFINED, then: 472 1. L_DAT_hello_time := current time + (L_DAT_hello_interval * 473 DAT_HELLO_TIMEOUT_FACTOR). 475 5. L_DAT_lost_hello_messages := 0. 477 9.3.2. HELLO based Link Loss 479 A metric might just use the incoming NHDP HELLO messages of a 480 neighbor to calculate the link loss. Because this method uses fewer 481 events to calculate the metric, the variance of the output will 482 increase. It might be necessary to increase the value of 483 DAT_MEMORY_LENGTH to compensate for this. 485 For each incoming HELLO message, after it has been processed as 486 defined in [RFC6130] section 12, the Link Set Tuple as defined in 487 section 7.1 corresponding to the incoming HELLO message must be 488 updated. 490 1. L_DAT_received[TAIL] := L_DAT_received[TAIL] + 1. 492 2. L_DAT_total[TAIL] := L_DAT_total[TAIL] + 1. 494 3. L_DAT_lost_hello_messages := 0. 496 9.3.3. Other Measurement of Link Loss 498 Instead of using incoming [RFC5444] packets or [RFC6130] messages, 499 the routing daemon can also use other sources to measure the link 500 layer lossrate (e.g. [DLEP]). 502 To use a source like this with the DAT metric, the routing daemon has 503 to add incoming total traffic (or the sum of received and lost 504 traffic) and lost traffic to the queued elements in the extension of 505 the Link Set Tuple defined in Section 8 corresponding to originator 506 of the traffic. 508 The routing daemon should also set L_DAT_lost_hello_messages to zero 509 every times new packages arrive. 511 9.4. HELLO Message Processing 513 For each incoming HELLO Message, after it has been processed as 514 defined in [RFC6130] section 12, the Link Set Tuple corresponding to 515 the incoming HELLO message must be updated. 517 1. If the HELLO message contains an INTERVAL_TIME message TLV, then: 519 1. L_DAT_hello_interval := interval_time. 521 2. Otherwise: 523 1. L_DAT_hello_interval := validity_time. 525 10. Timer Event Handling 527 In addition to changes in the [RFC5444] processing/generation code, 528 the DAT metric also uses two timer events. 530 10.1. HELLO Timeout Processing 532 When L_DAT_hello_time has timed out, the following step MUST be done: 534 1. L_DAT_lost_hello_messages := L_DAT_lost_hello_messages + 1. 536 2. L_DAT_hello_time := L_DAT_hello_time + L_DAT_hello_interval. 538 10.2. Metric Update 540 Once every DAT_REFRESH_INTERVAL, all L_in_metric values in all Link 541 Set entries MUST be recalculated: 543 1. sum_received := sum(L_DAT_total). 545 2. sum_total := sum(L_DAT_received). 547 3. If L_DAT_hello_interval != UNDEFINED and 548 L_DAT_lost_hello_messages > 0, then: 550 1. lost_time_proportion := L_DAT_hello_interval * 551 L_DAT_lost_hello_messages / DAT_MEMORY_LENGTH. 553 2. sum_received := sum_received * MAX ( 0, 1 - 554 lost_time_proportion); 556 4. If sum_received < 1, then: 558 1. L_in_metric := MAXIMUM_METRIC, as defined in [RFC7181] 559 section 5.6.1. 561 5. Otherwise: 563 1. loss := sum_total / sum_received. 565 2. If loss > DAT_MAXIMUM_LOSS, then: 567 1. loss := DAT_MAXIMUM_LOSS. 569 3. bitrate := L_DAT_rx_bitrate. 571 4. If bitrate < DAT_MINIMUM_BITRATE, then: 573 1. bitrate := DAT_MINIMUM_BITRATE. 575 5. L_in_metric := (2^24 / DAT_MAXIMUM_LOSS) * loss / (bitrate / 576 DAT_MINIMUM_BITRATE). 578 6. remove(L_DAT_total) 580 7. add(L_DAT_total, 0) 582 8. remove(L_DAT_received) 584 9. add(L_DAT_received, 0) 586 11. IANA Considerations 588 This document contains no actions for IANA. 590 12. Security Considerations 592 Artificial manipulation of metrics values can drastically alter 593 network performance. In particular, advertising a higher L_in_metric 594 value may decrease the amount of incoming traffic, while advertising 595 lower L_in_metric may increase the amount of incoming traffic. By 596 artificially increasing or decreasing the L_in_metric values it 597 advertises, a rogue router may thus attract or repulse data traffic. 598 A rogue router may then potentially degrade data throughput by not 599 forwarding data as it should or redirecting traffic into routing 600 loops or bad links. 602 An attacker might also inject packets with incorrect packet level 603 sequence numbers, pretending to be somebody else. This attack can be 604 prevented by the true originator of the RFC5444 packets by adding a 605 [RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet. 606 This allows the receiver to drop all incoming packets which have a 607 forged packet source, both packets generated by the attacker or 608 replayed packets. The signature scheme described in [RFC7183] does 609 not protect the additional sequence number of the DAT metric because 610 it does only sign the RFC5444 messages, not the RFC5444 packet 611 header. 613 13. Acknowledgements 615 The authors would like to acknowledge the network administrators from 616 Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for 617 endless hours of testing and suggestions to improve the quality of 618 the original ETX metric for the OLSR.org routing daemon. 620 This effort/activity is supported by the European Community Framework 621 Program 7 within the Future Internet Research and Experimentation 622 Initiative (FIRE), Community Networks Testbed for the Future Internet 623 ([CONFINE]), contract FP7-288535. 625 The authors would like to gratefully acknowledge the following people 626 for intense technical discussions, early reviews and comments on the 627 specification and its components (listed alphabetically): Teco Boot 628 (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), 629 Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology 630 Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus 631 Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research 632 Laboratory) and Stan Ratliff (Cisco Systems). 634 14. References 636 14.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", RFC 2119, BCP 14, March 1997. 641 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 642 Protocol", RFC 3626, October 2003. 644 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 645 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 646 Format", RFC 5444, February 2009. 648 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 649 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 650 2009. 652 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 653 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 654 RFC 6130, April 2011. 656 [RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized 657 Link State Routing Protocol version 2", RFC 7181, April 658 2014. 660 [RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check 661 Value and Timestamp TLV Definitions for Mobile Ad Hoc 662 Networks (MANETs)", RFC 7182, April 2014. 664 [RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity 665 Protection for the Neighborhood Discovery Protocol (NHDP) 666 and Optimized Link State Routing Protocol Version 2 667 (OLSRv2)", RFC 7183, April 2014. 669 14.2. Informative References 671 [CONFINE] "Community Networks Testbed for the Future Internet 672 (CONFINE)", 2013, . 674 [DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D. 675 Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", 676 draft-ietf-manet-dlep-04 , March 2013. 678 [MOBICOM03] 679 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 680 High-Throughput Path Metric for Multi-Hop Wireless 681 Routing", Proceedings of the MOBICOM Conference , 2003. 683 [MOBICOM04] 684 Richard, D., Jitendra, P., and Z. Brian, "Routing in 685 Multi-Radio, Multi-Hop Wireless Mesh Networks", 686 Proceedings of the MOBICOM Conference , 2004. 688 [OLSR.org] 689 "The OLSR.org OLSR routing daemon", 2013, 690 . 692 [FREIFUNK] 693 "Freifunk Wireless Community Networks", 2013, 694 . 696 [FUNKFEUER] 697 "Austria Wireless Community Network", 2013, 698 . 700 Appendix A. OLSR.org metric history 702 The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR- 703 based [RFC3626] or B.A.T.M.A.N. based wireless community networks 704 with hundreds of routers in permanent operation. The Vienna 705 Funkfeuer network in Austria, for instance, consists of 400 routers 706 (around 600 routes) covering the whole city of Vienna and beyond, 707 spanning roughly 40km in diameter. It has been in operation since 708 2003 and supplies its users with Internet access. A particularity of 709 the Vienna Funkfeuer network is that it manages to provide Internet 710 access through a city wide, large scale Wi-Fi MANET, with just a 711 single Internet uplink. 713 Operational experience of the OLSR project [OLSR.org] with these 714 networks have revealed that the use of hop-count as routing metric 715 leads to unsatisfactory network performance. Experiments with the 716 ETX metric [MOBICOM03] were therefore undertaken in parallel in the 717 Berlin Freifunk network as well as in the Vienna Funkfeuer network in 718 2004, and found satisfactory, i.e., sufficiently easy to implement 719 and providing sufficiently good performance. This metric has now 720 been in operational use in these networks for several years. 722 The ETX metric of a link is the estimated number of transmissions 723 required to successfully send a packet (each packet equal to or 724 smaller than MTU) over that link, until a link layer acknowledgement 725 is received. The ETX metric is additive, i.e., the ETX metric of a 726 path is the sum of the ETX metrics for each link on this path. 728 While the ETX metric delivers a reasonable performance, it doesn't 729 handle well networks with heterogeneous links that have different 730 bitrates. Since every wireless link, when using ETX metric, is 731 characterized only by its packet loss ratio, the ETX metric prefers 732 long-ranged links with low bitrate (with low loss ratios) over short- 733 ranged links with high bitrate (with higher but reasonable loss 734 ratios). Such conditions, when they occur, can degrade the 735 performance of a network considerably by not taking advantage of 736 higher capacity links. 738 Because of this the OLSR.org project has implemented the Directional 739 Airtime Metric for OLSRv2, which has been inspired by the Estimated 740 Travel Time (ETT) metric [MOBICOM04]. This metric uses an 741 unidirectional packet loss, but also takes the bitrate into account 742 to create a more accurate description of the relative costs or 743 capabilities of OLSRv2 links. 745 Appendix B. Linkspeed stabilization 747 The DAT metric describes how to generate a reasonable stable packet 748 loss value from incoming packet reception/loss events, the source of 749 the linkspeed used in this document is considered an external 750 process. 752 In the presence of a layer-2 technology with variable linkspeed it is 753 likely that the raw linkspeed will be fluctuating too fast to be 754 useful for the DAT metric. 756 The amount of stabilization necessary for the linkspeed depends on 757 the implementation of the mac-layer, especially the rate control 758 algorithm. 760 Experiments with the Linux 802.11 wifi stack have shown that a simple 761 Median filter over a series of raw linkspeed measurements can smooth 762 the calculated value without introducing intermediate linkspeed 763 values you would get by using averaging or an exponential weighted 764 moving average. 766 Authors' Addresses 768 Henning Rogge 769 Fraunhofer FKIE 771 Email: henning.rogge@fkie.fraunhofer.de 772 URI: http://www.fkie.fraunhofer.de 774 Emmanuel Baccelli 775 INRIA 777 Email: Emmanuel.Baccelli@inria.fr 778 URI: http://www.emmanuelbaccelli.org/