idnits 2.17.1 draft-ietf-manet-nhdp-optimization-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7181, but the abstract doesn't seem to directly say this. It does mention RFC7181 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6130, updated by this document, for RFC5378 checks: 2006-06-21) (Using the creation date from RFC7181, updated by this document, for RFC5378 checks: 2005-10-21) -- 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 (January 23, 2015) is 3352 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) C. Dearlove 3 Internet-Draft BAE Systems ATC 4 Updates: 6130, 7181 T. Clausen 5 (if approved) LIX, Ecole Polytechnique 6 Intended status: Standards Track January 23, 2015 7 Expires: July 27, 2015 9 An Optimization for the MANET Neighborhood Discovery Protocol (NHDP) 10 draft-ietf-manet-nhdp-optimization-04 12 Abstract 14 The link quality mechanism of the MANET Neighborhood Discovery 15 Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the 16 measured link quality from that 1-hop neighbor is below an acceptable 17 threshold, while still retaining the corresponding link information 18 as acquired from HELLO message exchange. This allows immediate 19 reinstatement of the 1-hop neighbor if the link quality later 20 improves sufficiently. 22 NHDP also collects information about symmetric 2-hop neighbors. 23 However it specifies that if a link from a symmetric 1-hop neighbor 24 ceases being symmetric, including while "ignored" as described above, 25 then corresponding symmetric 2-hop neighbors are removed. This may 26 lead to symmetric 2-hop neighborhood information being permanently 27 removed (until further HELLO messages are received) if the link 28 quality of a symmetric 1-hop neighbor drops below the acceptable 29 threshold, even if only for a moment. 31 This specification updates RFC6130 "Mobile Ad Hoc Network (MANET) 32 Neighborhood Discovery Protocol (NHDP)", and RFC7181 "The Optimized 33 Link State Routing Protocol version 2 (OLSRv2)" to permit, as an 34 option, retaining, but ignoring, symmetric 2-hop information when the 35 link quality from the corresponding 1-hop neighbor drops below the 36 acceptable threshold. This allows immediate reinstatement of the 37 symmetric 2-hop neighbor if the link quality later improves 38 sufficiently, thus making the symmetric 2-hop neighborhood more 39 "robust". 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on July 27, 2015. 58 Copyright Notice 60 Copyright (c) 2015 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 5 78 4. Changes to NHDP . . . . . . . . . . . . . . . . . . . . . . . . 5 79 4.1. Interface Information Bases . . . . . . . . . . . . . . . . 6 80 4.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 6 81 4.3. Information Base Changes . . . . . . . . . . . . . . . . . 6 82 4.4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . 7 83 5. Changes to OLSRv2 . . . . . . . . . . . . . . . . . . . . . . . 7 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 92 1. Introduction 94 The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130], Section 95 14, contains a link admission mechanism known as "link quality" that 96 allows a router using that protocol to "take considerations other 97 than message exchange into account for determining when a link is and 98 is not a candidate for being considered as HEARD or SYMMETRIC". 99 Specifically, [RFC6130] permits a router to disallow consideration of 100 some of its 1-hop neighbors, for as long as the quality of the link 101 from that 1-hop neighbor is below an acceptable link quality 102 threshold. 104 A feature of this mechanism is that while the link quality remains 105 too low, the link information, established by the exchange of HELLO 106 messages, is retained. Thus if the link quality later goes above the 107 required threshold (note that a hysteresis mechanism means that two 108 thresholds are used) then the link is immediately established and 109 will be immediately available for use. 111 [RFC6130] collects not just 1-hop neighbor information, but also 112 information about symmetric 2-hop neighbors. However [RFC6130] 113 specifies that if a 1-hop neighbor was, but no longer is, considered 114 symmetric, then the corresponding 2-Hop Tuples that may have been 115 recorded for that 2-hop neighbor, are to be removed, without a 116 retention mechanism for a (possibly temporary) loss due to link 117 quality. 119 This means that if there is a short period in which link quality is 120 too low, then when the link quality is reestablished, all 1-hop 121 neighbor information is immediately available for use again. 122 However, the corresponding symmetric 2-hop neighbor information has 123 been removed, and is not available for use until restored by receipt 124 of the next corresponding HELLO message. 126 This specification describes how [RFC6130] can be modified to avoid 127 this situation, by retaining (but not using) 2-hop information, 128 similar to what is done with 1-hop information. This modification is 129 strictly optional, and routers that do and do not implement it can 130 interwork entirely successfully (as they also can with different link 131 quality specifications). In addition, by a suitable interpretation 132 (that ignored 2-Hop Tuples are not externally advertised), this 133 change can be invisible to any other protocols using [RFC6130], in 134 particular [RFC7181]. However the impact on [RFC7181] when 2-Hop 135 Tuples are not so handled is also described, in particular owing to 136 the existence of implementations of that protocol that are not 137 modularly separated from [RFC6130]. 139 This specification therefore updates [RFC6130] and [RFC7181]. 141 This update to [RFC6130] does not change the definition of a 142 symmetric 2-hop neighbor, but adds new state information to each 143 2-Hop Tuple of [RFC6130]. This is to retain some 2-hop neighbor 144 information, while recording it as currently not to be used. The new 145 state information and retained 2-Hop Tuples are reflected in the 146 corresponding tables of the updated NHDP-MIB module [RFC6779bis]. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 [RFC2119]. 155 Additionally, this document uses the terminology of [RFC6130] and 156 [RFC7181]. 158 3. Applicability Statement 160 This specification updates [RFC6130]. The optimization presented in 161 this specification is simply permissive, as it allows retaining 162 information which otherwise would have been removed, but does not use 163 that information except when it could have been used by [RFC6130]. 165 This can, in some cases, ensure that the symmetric 2-hop neighborhood 166 is more robust against temporary link quality changes, and 167 consequently yield a more stable network. The only other consequence 168 of this optimization is that state for some otherwise expired 2-Hop 169 Tuples may be maintained for longer. 171 This specification also updates [RFC7181]. This could have been 172 avoided by this specification describing how the updates to [RFC6130] 173 may be handled so as to be invisible to any other protocol using it. 174 However, as it is known that some implementations of [RFC7181] are 175 not independent of the implementation of [RFC6130] that they use, it 176 is useful to indicate the direct impact on [RFC7181]. 178 A router that implements the optimization described in this 179 specification will interoperate successfully with routers that 180 implement [RFC6130], but do not implement this optimization. 182 4. Changes to NHDP 184 The following changes are made to [RFC6130] if using this 185 specification. Note that while this specification is OPTIONAL, if 186 any of these changes are made then all of these changes MUST be made. 188 4.1. Interface Information Bases 190 The 2-Hop Set is modified by adding this additional element to each 191 2-Hop Tuple: 193 N2_lost is a boolean flag, which indicates the state of the 194 corresponding Link Tuple. If L_status = SYMMETRIC (and thus 195 L_lost = false), then N2_lost = false. If L_SYM_time has not 196 expired, and L_lost = true (and hence L_status = LOST), then 197 N2_lost = true. 199 In all other cases, including other cases with L_status = LOST, there 200 will be no such 2-Hop Tuples. 202 4.2. HELLO Message Processing 204 In Section 12.6 of [RFC6130] make the following changes: 206 o In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not 207 expired". 209 o When creating a 2-Hop Tuple, set N2_lost := L_lost. 211 4.3. Information Base Changes 213 In Section 13, replace the second bullet point by: 215 o A Link Tuple's L_status changes from SYMMETRIC, L_SYM_time 216 expires, or the Link Tuple is removed. In this case, the actions 217 specified in Section 13.2 are performed. 219 and replace the paragraph after the bullet points by: 221 If a Link Tuple is removed, or if L_HEARD_time expires and either 222 L_status changes from SYMMETRIC or L_SYM_time expires, then the 223 actions specified in Section 13.2 MUST be performed before the 224 actions specified in Section 13.3 are performed for that Link Tuple. 226 In Section 13.2 of [RFC6130], add the following, before all other 227 text: 229 For each Link Tuple that has L_SYM_time not expired: 231 1. If L_SYM_time then expires, or if the Link Tuple is removed: 233 1. Remove each 2-Hop Tuple for the same MANET interface with: 235 + N2_neighbor_iface_addr_list contains one or more network 236 addresses in L_neighbor_iface_addr_list. 238 2. If L_status then changes from SYMMETRIC to LOST because L_lost is 239 set to true: 241 1. For each 2-Hop Tuple for the same MANET interface with: 243 + N2_neighbor_iface_addr_list contains one or more network 244 addresses in L_neighbor_iface_addr_list; 246 set N2_lost := true. 248 Also in Section 13.2 of [RFC6130], remove point 2, renumbering point 249 2 as point 1. 251 4.4. Constraints 253 In Appendix B, under "In each 2-Hop Tuple:" change the first bullet 254 point to: 256 o There MUST be a Link Tuple associated with the same MANET 257 interface with: 259 * L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND 261 * L_SYM_time not expired; AND 263 * L_lost = N2_lost. 265 5. Changes to OLSRv2 267 If the implementation of [RFC6130] conceals from any protocol using 268 it the existence of all 2-Hop Tuples with N2_lost = true, then no 269 changes are required to any protocol using [RFC6130], in particular 270 no changes are required to [RFC7181]. 272 However if instead the implementation of [RFC6130] makes all 2-Hop 273 Tuples visible, including those with N2_lost = true, then protocols 274 using [RFC6130] MUST ignore such 2-Hop Tuples. 276 For [RFC7181], given that this protocol uses 2-hop information for 277 MPR Set and Routing Set calculation, but not includes that 278 information in control traffic, this means that an implementation 279 must be (i) behaving as if a 2-Hop Tuple only exists if 280 N2_lost=false, and (ii) as if a change of N2_lost (from false to 281 true, or true to false) corresponds to a 2-Hop Tuple appearing or 282 being removed. Specifically, this means behaving as if all of the 283 following changes were to be made to [RFC7181]: 285 o In Section 17.6 of [RFC7181], point 1, replace the final two 286 bullet points with: 288 * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost 289 = false is added or removed, OR; 291 * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost 292 changed, OR; 294 * The N2_out_metric of any 2-Hop Tuple with N2_lost = false 295 changes, and either the flooding MPR selection process uses 296 metric values (see Section 18.4) or the change is to or from 297 UNKNOWN_METRIC. 299 o In Section 17.6 of [RFC7181], point 3, replace the final two 300 bullet points with: 302 * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost = 303 false is added or removed, OR; 305 * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost 306 changed, OR; 308 * The N2_in_metric of any 2-Hop Tuple with N2_lost = false 309 changes. 311 o In Section 17.7 of [RFC7181], in the fifth bullet point, add "and 312 N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". 314 o In Section 18.4 of [RFC7181], in the third bullet point, add ", 315 N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". 317 o In Section 18.5 of [RFC7181], in the third bullet point, add ", 318 N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC". 320 o In Section 19.1 of [RFC7181], in the final main bullet point 321 (marked as "(OPTIONAL)"), add "and N2_lost = false" after 322 "N2_out_metric != UNKNOWN_METRIC". 324 o In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost = 325 false" after "N2_out_metric != UNKNOWN_METRIC". 327 6. IANA Considerations 329 This document has no actions for IANA. 331 [This section may be removed by the RFC Editor.] 333 7. Security Considerations 335 The update to [RFC6130] enables the retention and reuse of some 336 information collected by that protocol, for only the duration that it 337 could have been used in any case. As such, this protocol introduces 338 no new security considerations to an implementation of [RFC6130] or 339 of any other protocol that uses it, such as [RFC7181]. 341 8. Acknowledgments 343 The authors would like to thank Liz Cullen (BAE Systems) for first 344 illustrating the issue addressed in this specification. 346 9. References 348 9.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 354 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 355 RFC 6130, April 2011. 357 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 358 "The Optimized Link State Routing Protocol version 2", 359 RFC 7181, April 2014. 361 9.2. Informative References 363 [RFC6779bis] 364 Herberg, U., Cole, R., Chakeres, I., and T. Clausen, 365 "Definition of Managed Objects for the Neighborhood 366 Discovery Protocol", draft-ietf-manet-rfc6779bis (work in 367 progress), August 2014. 369 Authors' Addresses 371 Christopher Dearlove 372 BAE Systems Advanced Technology Centre 373 West Hanningfield Road 374 Great Baddow, Chelmsford 375 United Kingdom 377 Phone: +44 1245 242194 378 Email: chris.dearlove@baesystems.com 379 URI: http://www.baesystems.com/ 381 Thomas Heide Clausen 382 LIX, Ecole Polytechnique 384 Phone: +33 6 6058 9349 385 Email: T.Clausen@computer.org 386 URI: http://www.ThomasClausen.org/