idnits 2.17.1 draft-clausen-olsrv2-link-hysteresis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 384. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 112: '... recommendations SHOULD be considered ...' RFC 2119 keyword, line 121: '... recommendations SHOULD be considered ...' RFC 2119 keyword, line 127: '... SHOULD include (i) a L_link_pending...' RFC 2119 keyword, line 137: '...ssage generation SHOULD consider those...' RFC 2119 keyword, line 143: '..."true", the link SHOULD NOT be adverti...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (11 July 2005) is 6864 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '5' is mentioned on line 84, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 3626 (ref. '1') == Outdated reference: A later version (-01) exists of draft-clausen-manet-olsrv2-00 -- Possible downref: Normative reference to a draft: ref. '2' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Clausen 3 IETF MANET Working Group Emmanuel Baccelli 4 Expiration: 11 January 2006 LIX, Ecole Polytechnique, France 5 11 July 2005 7 OLSRv2 Link Hysteresis 8 draft-clausen-olsrv2-link-hysteresis-00.txt 10 Status of this Memo 12 This document is a submission to the Mobile Adhoc NETworks (MANET) 13 Working Group of the Internet Engineering Task Force (IETF). Comments 14 should be submitted to the manet@ietf.org mailing list. 16 Distribution of this memo is unlimited. 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC 2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 Established links between MANET nodes should be as reliable as 44 possible in order to avoid data packet loss. This implies that MANET 45 nodes' link sensing should be robust against bursty loss or transient 46 connectivity between nodes. Therefore, in order to enhance the 47 robustness of link sensing mechanisms, additional link hysteresis 48 strategies are used. This draft describes such a hysteresis mechanism 49 for OLSRv2. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. OLSRv2 Link Hysteresis . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Additional Information in the Link Set . . . . . . . . . . . . 4 58 2.2. Additional Steps in Hello Message Generation . . . . . . . . . 4 59 2.3. Hysteresis Strategy . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Interoperability Considerations . . . . . . . . . . . . . . . . 7 61 2.5. Proposed Values for Constants . . . . . . . . . . . . . . . . . 7 62 3. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Established links between MANET nodes should be as reliable as possi- 72 ble in order to avoid data packet loss. This implies that link sens- 73 ing should be robust against bursty loss or transient connectivity 74 between nodes. Hence, to enhance the robustness of the link sensing 75 mechanism, an additional link hysteresis strategy should be used. 76 This draft describes such a hysteresis mechanism for OLSRv2. This 77 draft supplements OLSRv2 basic specifications [2]. 79 1.1. Terminology 81 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC2119 [5]. 85 This document supplements the OLSRv2 specification. Several refer- 86 ences are made to the OLSR terminology described in [1] and [2]. 87 Among others, this document uses the following terminology: 89 - Node: a device capable of participating in a MANET. 91 - Neighbor Node: A node X is a neighbor node of node Y if node 92 Y can hear node X. 94 - Multipoint Relay (MPR): A node which is selected by its 95 neighbor, node X, to "re-transmit" all the broadcast messages 96 it emits. 98 - Neighbor Set: The information repository including the list 99 of the links established by a node with its neighbors. This 100 information also includes the quality of those links. 102 - HELLO messages: A node performs link sensing (the discovery 103 of its neighborhood) via the periodic exchange of HELLO 104 messages with its neighbors. 106 - TLV: a TLV is an attribute, associated to a message or set of 107 addresses. This attribute is in a type-length-value format. 109 1.2. Applicability 111 This draft describes a link hysteresis mechanism for OLSRv2. The 112 specified recommendations SHOULD be considered for an OLSRv2 imple- 113 mentation. This draft supplements OLSRv2 basic specifications [2]. 115 2. OLSRv2 Link Hysteresis 117 Established links should be as reliable as possible to avoid data 118 packet loss. This implies that link sensing should be robust against 119 bursty loss or transient connectivity between nodes. Hence, to 120 enhance the robustness of the link sensing mechanism, the following 121 implementation recommendations SHOULD be considered in OLSRv2. These 122 recommendations are supplement to the specifications of [2]. 124 2.1. Additional Information in the Link Set 126 Each link tuple in the neighbor links set of a given OLSRv2 node 127 SHOULD include (i) a L_link_pending field, (ii) a L_link_quality 128 field, and (iii) a L_LOST_LINK_time field. L_link_pending is a 129 boolean value specifying if the link is considered pending (i.e., the 130 link is not considered established). L_link_quality is a dimension- 131 less number between 0 and 1 describing the quality of the link. 132 L_LOST_LINK_time is a timer for declaring a link as lost when an 133 established link becomes pending. 135 2.2. Additional Steps in Hello Message Generation 137 HELLO message generation SHOULD consider those fields as follows: 139 1 if L_LOST_LINK_time is not expired, the link is advertised 140 with a link type of LOST_LINK. 142 2 otherwise, if L_LOST_LINK_time is expired and L_link_pending 143 is set to "true", the link SHOULD NOT be advertised at all; 145 3 otherwise, if L_LOST_LINK_time is expired and L_link_pending 146 is set to "false", the link is advertised. 148 A node considers that it has a symmetric link for each link tuple 149 where: 151 1 L_LOST_LINK_time is expired, AND 153 2 L_link_pending is "false", AND 155 3 L_SYM_time is not expired. 157 This definition for "symmetric link" SHOULD thereby also be used as 158 basis for the symmetric neighborhood when computing the MPR set, as 159 well as for "the symmetric neighbors" in the first steps of the rout- 160 ing table calculation. 162 The L_link_quality, L_link_pending and L_LOST_LINK_time fields are 163 exclusively updated according to the present section. This section 164 does not modify the function of any other fields in the link tuples. 166 Additionally, HELLO messages must include a specific message TLV 167 called H-Time (see Table 1). 169 +-------------+-------------------------------------+---------------+ 170 | TLV Type | TLV Value | Default Value | 171 +-------------+-------------------------------------+---------------+ 172 | H-Time | HELLO emission interval | HTIME_DEFAULT | 173 +-------------+-------------------------------------+---------------+ 175 Table 1 177 This TLV specifies the HELLO emission interval used by the node on 178 this particular interface, i.e., the time before the transmission of 179 the next HELLO. The HELLO emission interval is represented by its 180 mantissa (four highest bits of H-Time field) and by its exponent 181 (four lowest bits of Htime field). In other words: 183 HELLO emission interval = C*(1+a/16)*2^b [in seconds] 185 where a is the integer represented by the four highest bits of H-Time 186 field and b the integer represented by the four lowest bits of H-Time 187 field. This H-Time value, as the additional parameters 188 L_LOST_LINK_time, L_link_pending and L_link_quality, is used by the 189 hysteresis strategy described in the following section. 191 2.3. Hysteresis Strategy 193 The link between a node and some of its neighbor interfaces might be 194 "bad", i.e., from time to time let HELLOs pass through only to fade 195 out immediately after. In this case, the neighbor information base 196 would contain a bad link for at least "validity time". The following 197 hysteresis strategy SHOULD be adopted to counter this situation. 199 For each neighbor interface NI heard by interface I, the L_link_qual- 200 ity field of the corresponding Link Tuple determines the establish- 201 ment of the link. The value of L_link_quality is compared to two 202 thresholds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed between 0 203 and 1 and such that HYST_THRESHOLD_HIGH >= HYST_THRESHOLD_LOW. With 204 L_time specifying the time at which the Link Tuple expires, the 205 L_link_pending field is set according to the following: 207 1 if L_link_quality > HYST_THRESHOLD_HIGH: 209 L_link_pending = false 211 L_LOST_LINK_time = current time - 1 (expired) 213 2 otherwise, if L_link_quality < HYST_THRESHOLD_LOW: 215 L_link_pending = true 217 L_LOST_LINK_time = min (L_time, current time + 218 NEIGHB_HOLD_TIME) 220 3 otherwise, if HYST_THRESHOLD_LOW <= L_link_quality 221 <= HYST_THRESHOLD_HIGH: 223 L_link_pending and L_LOST_LINK_time remain unchanged. 225 The condition for considering a link established is thus stricter 226 than the condition for dropping a link. Notice thus, that a link can 227 be dropped based on either timer expiration or on L_link_quality 228 dropping below HYST_THRESHOLD_LOW. 230 Also notice, that even if a link is not considered as established by 231 the link hysteresis, the link tuples are still updated for each 232 received HELLO message. Specifically, this implies that, regardless 233 of whether or not the link hysteresis considers a link as "estab- 234 lished", tuples in the link set do not expire except as determined by 235 the L_time field of the link tuples. 237 As a basic implementation requirement, an estimation of the link 238 quality must be maintained and stored in the L_link_quality field. 239 If some measure of the signal/noise level on a received message is as 240 estimation after normalization. 242 If no signal/noise information or other link quality information is 243 available from the link layer, an algorithm such as the following can 244 be utilized (it is an exponentially smoothed moving average of the 245 transmission success rate). The algorithm is parameterized by a 246 scaling parameter HYST_SCALING which is a number fixed between 0 and 247 1. For each neighbor interface NI heard by interface I, the first 248 time NI is heard by I, L_link_quality is set to HYST_SCALING 249 (L_link_pending is set to true and L_LOST_LINK_time to current time - 250 1). 252 A tuple is updated according to two rules. Every time an OLSR packet 253 emitted by NI is received by I, the stability rule is applied: 255 L_link_quality = (1-HYST_SCALING)*L_link_quality 256 + HYST_SCALING. 258 When an OLSRv2 packet emitted by NI is lost by I, the instability 259 rule is applied: 261 L_link_quality = (1-HYST_SCALING)*L_link_quality. 263 The loss of OLSRv2 packet is detected by tracking the missing Packet 264 Sequence Numbers on a per interface basis and by "long period of 265 silence" from a node. A "long period of silence" may be detected 266 thus: if no OLSRv2 packet has been received on interface I from 267 interface NI during HELLO emission interval of interface NI (computed 268 from the H-Time field in the last HELLO message received from NI), a 269 loss of an OLSRv2 packet is detected. 271 2.4. Interoperability Considerations 273 Link hysteresis determines, for a node, the criteria at which a link 274 to a neighbor node is accepted or rejected. Nodes in a network may 275 have different criteria, according to the nature of the media over 276 which they are communicating. Once a link is accepted, it is adver- 277 tised, in accordance with the provisions described in the previous 278 sections of this specification. 280 2.5. Proposed Values for Constants 282 Here are the proposed values for the constants mentionned in the pre- 283 vious sections. 285 HYST_THRESHOLD_HIGH = 0.8 287 HYST_THRESHOLD_LOW = 0.3 289 HYST_SCALING = 0.5 291 NEIGHB_HOLD_TIME = 6 seconds 293 H-Time = 2 seconds 295 C = 1/16 297 3. Authors' Addresses 299 Thomas Heide Clausen, 300 Project PCRI 301 Pole Commun de Recherche en Informatique du plateau de Saclay, 302 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 303 Ecole polytechnique, 304 Laboratoire d'informatique, 305 91128 Palaiseau Cedex, France 306 Phone: +33 1 69 33 40 73, 307 Email: T.Clausen@computer.org 309 Emmanuel Baccelli 310 HITACHI Labs Europe/ Project PCRI, 311 Pole Commun de Recherche en Informatique du plateau de Saclay, 312 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 313 Ecole polytechnique, 314 Laboratoire d'informatique, 315 91128 Palaiseau Cedex, France 316 Phone: +33 1 69 33 40 73, 317 Email: Emmanuel.Baccelli@inria.fr 319 4. Contributors 321 Cedric Adjih, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le 322 Chesnay Cedex, France, Phone: +33 1 3963 5215, Email: 323 Cedric.Adjih@inria.fr 325 Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 326 Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email: 327 Philippe.Jacquet@inria.fr 329 Anis Laouiti, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le 330 Chesnay Cedex, France, Phone: +33 1 3963 5088, Email: 331 Anis.Laouiti@inria.fr 333 Paul Muhlethaler, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 334 Le Chesnay Cedex, France, Phone: +33 1 3963 5278, Email: 335 Paul.Muhlethaler@inria.fr 336 Ryuji Wakikawa, Keio University and WIDE, 5322 Endo Fujisawa 337 Kanagawa, 252 JAPAN, Email: ryuji@sfc.wide.ad.jp 339 Christopher Dearlove, BAE SYSTEMS Advanced Technology Centre, Great 340 Baddow, Chelmsford, UK. Phone: +44 1245 242194 Email: 341 chris.dearlove@baesystems.com 343 Amir Qayyum Center for Advanced Research in Engineering Pvt. Ltd. 19 344 Ataturk Avenue Islamabad, Pakistan Phone: +92-51-2874115 Email: 345 amir@carepvtltd.com 347 Laurent Viennot Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le 348 Chesnay Cedex, France Phone: +33 1 3963 5225 Email: 349 Laurent.Viennot@inria.fr 351 5. References 353 [1] T. Clausen, P. Jacquet, RFC 3626: Optimized Link State Routing Pro- 354 tocol. Request for Comments (Experimental), Internet Engineering 355 Task Force, October 2003. 357 [2] T. Clausen, Optimized Link State Routing Protocol version 2, IETF 358 Internet Draft draft-clausen-manet-olsrv2-00, July 2005. 360 6. Changes 362 This is the initial version of this specification. 364 7. IANA Considerations 366 This document does currently not specify IANA considerations. 368 8. Security Considerations 370 This document does not specify any security considerations. 372 9. Copyright 374 Copyright (C) The Internet Society (2005). This document is subject 375 to the rights, licenses and restrictions contained in BCP 78, and 376 except as set forth therein, the authors retain all their rights. 378 This document and the information contained herein are provided on 379 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 380 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 381 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 382 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 383 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.