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