idnits 2.17.1 draft-ietf-manet-nhdp-optimization-00.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC7181, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6130, but the abstract doesn't seem to mention this, which it should. 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 (July 21, 2014) is 3567 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) ** Obsolete normative reference: RFC 6779 (Obsoleted by RFC 7939) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 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: RFC 6130, RFC 7181 T. Clausen 5 (if approved) LIX, Ecole Polytechnique 6 Intended status: Standards Track July 21, 2014 7 Expires: January 22, 2015 9 An Optimization for the MANET Neighborhood Discovery Protocol (NHDP) 10 draft-ietf-manet-nhdp-optimization-00 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 NHDP, and the Optimized Link State Routing 32 Protocol version 2 (OLSRv2) to permit retaining, but ignoring, 33 symmetric 2-hop information when the link quality from the 34 corresponding 1-hop neighbor drops below the acceptable threshold. 35 This allows immediate reinstatement of the symmetric 2-hop neighbor 36 if the link quality later improves sufficiently, thus making the 37 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 January 22, 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 . . . . . . . . . . . . . . . 5 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. MIB Considerations . . . . . . . . . . . . . . . . . . . . . . 8 83 6.1. Updates to the State Group . . . . . . . . . . . . . . . . 9 84 6.2. Updates to the Notification Group . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 88 10. Normative References . . . . . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130], Section 94 14, contains a link admission mechanism known as "link quality" that 95 allows a router using that protocol to "take considerations other 96 than message exchange into account for determining when a link is and 97 is not a candidate for being considered as HEARD or SYMMETRIC". 98 Specifically, [RFC6130] permits a router to disallow consideration of 99 some of its 1-hop neighbors, for as long as the quality of the link 100 from that 1-hop neighbor is below an acceptable link quality 101 threshold. 103 A feature of this mechanism is that while the link quality remains 104 too low, the link information, established by the exchange of HELLO 105 messages, is retained. Thus if the link quality later goes above the 106 required threshold (note that a hysteresis mechanism means that two 107 thresholds are used) then the link is immediately established and 108 will be immediately available for use. 110 [RFC6130] collects not just 1-hop neighbor information, but also 111 information about symmetric 2-hop neighbors. However [RFC6130] 112 specifies that if a 1-hop neighbor was, but no longer is, considered 113 symmetric, then the corresponding 2-Hop Tuples that may have been 114 recorded for that 2-hop neighbor, are to be removed, without a 115 retention mechanism for a (possibly temporary) loss due to link 116 quality. 118 This means that if there is a short period in which link quality is 119 too low, then when the link quality is reestablished, all 1-hop 120 neighbor information is immediately available for use again. 121 However, the corresponding symmetric 2-hop neighbor information has 122 been removed, and is not available for use until restored by receipt 123 of the next corresponding HELLO message. 125 This specification describes how [RFC6130] can be modified to avoid 126 this situation, by retaining (but not using) 2-hop information, 127 similar to what is done with 1-hop information. This modification is 128 strictly optional, and routers that do and do not implement it can 129 interwork entirely successfully (as they also can with different link 130 quality specifications). In addition, by a suitable interpretation 131 (that ignored 2-Hop Tuples are not externally advertised), this 132 change can be invisible to any other protocols using [RFC6130], in 133 particular [RFC7181]. However the impact on [RFC7181] when 2-Hop 134 Tuples are not so handled is also described, in particular owing to 135 the existence of implementations of that protocol that are not 136 modularly separated from [RFC6130]. 138 This specification therefore updates [RFC6130] and [RFC7181]. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 [RFC2119]. 147 Additionally, this document uses the terminology of [RFC6130] and 148 [RFC7181]. 150 3. Applicability Statement 152 This specification updates [RFC6130]. The optimization presented in 153 this specification is simply permissive, as it allows retaining 154 information which otherwise would have been removed, but does not use 155 that information except when it could have been used by [RFC6130]. 157 This can, in some cases, ensure that the symmetric 2-hop neighborhood 158 is more robust against temporary link quality changes, and 159 consequently yield a more stable network. The only other consequence 160 of this optimization is that state for some otherwise expired 2-Hop 161 Tuples may be maintained for longer. 163 This specification also updates [RFC7181]. This could be avoided by 164 simply noting that this specification describes how the updates to 165 [RFC6130] may be handled so as to be invisible to any other protocol 166 using it. However as it is known that some implementations of 167 [RFC7181] are not independent of the implementation of [RFC6130] that 168 they use, it is useful to indicate the direct impact on [RFC7181]. 170 A router that implements the optimization described in this 171 specification will interoperate successfully with routers that 172 implement [RFC6130], but do not implement this optimization. 174 4. Changes to NHDP 176 The following changes are made to [RFC6130] if using this 177 specification. Note that while this specification is OPTIONAL, if 178 any of these changes are made then all of these changes MUST be made. 180 4.1. Interface Information Bases 182 The 2-Hop Set is modified by adding this additional element to each 183 2-Hop Tuple: 185 N2_lost is a boolean flag, which indicates the state of the 186 corresponding Link Tuple. If L_status = SYMMETRIC (and thus 187 L_lost = false), then N2_lost = false. If L_SYM_time has not 188 expired, and L_lost = false (and hence L_status = LOST), then 189 N2_lost = true. 191 In all other cases, including other cases with L_status = LOST, there 192 will be no such 2-Hop Tuples. 194 4.2. HELLO Message Processing 196 In Section 12.6 of [RFC6130] make the following changes: 198 o In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not 199 expired". 201 o When creating a 2-Hop Tuple, set N2_lost := L_lost. 203 4.3. Information Base Changes 205 In Section 13, replace the second bullet point by: 207 o A Link Tuple's L_status changes from SYMMETRIC, L_SYM_time 208 expires, or the Link Tuple is removed. In this case, the actions 209 specified in Section 13.2 are performed. 211 and replace the paragraph after the bullet points by: 213 If a Link Tuple is removed, or if L_HEARD_time expires and either 214 L_status changes from SYMMETRIC or L_SYM_time expires, then the 215 actions specified in Section 13.2 MUST be performed before the 216 actions specified in Section 13.3 are performed for that Link Tuple. 218 In Section 13.2 of [RFC6130], add the following, before all other 219 text: 221 For each Link Tuple that has L_SYM_time not expired: 223 1. If L_SYM_time then expires, or if the Link Tuple is removed: 225 1. Remove each 2-Hop Tuple for the same MANET interface with: 227 + N2_neighbor_iface_addr_list contains one or more network 228 addresses in L_neighbor_iface_addr_list. 230 2. If L_status then changes from SYMMETRIC to LOST because L_lost is 231 set to true: 233 1. For 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 set N2_lost := true. 240 Also in Section 13.2 of [RFC6130], remove point 2, renumbering point 241 2 as point 1. 243 4.4. Constraints 245 In Appendix B, under "In each 2-Hop Tuple:" change the first bullet 246 point to: 248 o There MUST be a Link Tuple associated with the same MANET 249 interface with: 251 * L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND 253 * L_SYM_time not expired; AND 255 * L_lost = N2_lost. 257 5. Changes to OLSRv2 259 If the implementation of [RFC6130] conceals from any protocol using 260 it the existence of all 2-Hop Tuples with N2_lost = true, then no 261 changes are required to any protocol using [RFC6130], in particular 262 no changes are required to [RFC7181]. 264 However if instead the implementation of [RFC6130] makes all 2-Hop 265 Tuples visible, including those with N2_lost = true, then protocols 266 using [RFC6130] MUST ignore such 2-Hop Tuples. 268 For [RFC7181], given that this protocol uses 2-hop information for 269 MPR Set and Routing Set calculation, but not includes that 270 information in control traffic, this means that an implementation 271 must be (i) behaving as if a 2-Hop Tuple only exists if 272 N2_lost=false, and (ii) as if a change of N2_lost (from false to 273 true, or true to false) corresponds to a 2-Hop Tuple appearing or 274 being removed. Specifically, this means behaving as if all of the 275 following changes were to be made to [RFC7181]: 277 o In Section 17.6 of [RFC7181], point 1, replace the final two 278 bullet points with: 280 * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost 281 = false is added or removed, OR; 283 * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost 284 changed, OR; 286 * The N2_out_metric of any 2-Hop Tuple with N2_lost = false 287 changes, and either the flooding MPR selection process uses 288 metric values (see Section 18.4) or the change is to or from 289 UNKNOWN_METRIC. 291 o In Section 17.6 of [RFC7181], point 3, replace the final two 292 bullet points with: 294 * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost = 295 false is added or removed, OR; 297 * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost 298 changed, OR; 300 * The N2_in_metric of any 2-Hop Tuple with N2_lost = false 301 changes. 303 o In Section 17.7 of [RFC7181], in the fifth bullet point, add "and 304 N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". 306 o In Section 18.4 of [RFC7181], in the third bullet point, add ", 307 N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". 309 o In Section 18.5 of [RFC7181], in the third bullet point, add ", 310 N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC". 312 o In Section 19.1 of [RFC7181], in the final main bullet point 313 (marked as "(OPTIONAL)"), add "and N2_lost = false" after 314 "N2_out_metric != UNKNOWN_METRIC". 316 o In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost = 317 false" after "N2_out_metric != UNKNOWN_METRIC". 319 6. MIB Considerations 321 This update to [RFC6130] does not change the definition of a 322 symmetric 2-hop neighbor. It adds new information and states for 323 each symmetric 2-hop neighbor, recorded in the Neighbor Information 324 Base of a router and to be reflected in the appropriate tables of the 325 corresponding NHDP-MIB module [RFC6779]. 327 6.1. Updates to the State Group 329 This update introduces, to the state of each 2-Hop Tuple, the boolean 330 flag N2_lost. In order to reflect this, the updates in this section 331 are to be made to the State Group (nhdpStateObjGrp) of the NHDP-MIB 332 module [RFC6779]. 334 The DESCRIPTION of nhdpIib2HopSetEntry Object Type is to be updated, 335 so as to read as follows: 337 nhdpIib2HopSetEntry OBJECT-TYPE 338 SYNTAX NhdpIib2HopSetEntry 339 MAX-ACCESS not-accessible 340 STATUS current 341 DESCRIPTION 342 "nhdpIib2HopSetTable consists of 2-Hop Tuples, each 343 representing a single network address of a symmetric 344 2-hop neighbor and a single MANET interface of a 345 symmetric 1-hop neighbor. 347 (N2_neighbor_iface_addr_list, 348 N2_2hop_addr, N2_lost, N2_time). 350 The entries include the 2-hop neighbor addresses, which 351 act as the table index, and associated symmetric 1-hop 352 neighbor address set, designated through nhdpDiscIfIndex, 353 an expiration time, and a flag indicating if the 1-hop 354 neighbor, through which this 2-hop neighbor is reachable, 355 is considered lost due to link quality, or not. 357 The nhdpIfIndex in the INDEX is the interface index of 358 the local interface through which these 2-hop addresses 359 are accessible. The nhdpDiscIfIndex in the INDEX 360 represents the 1-hop neighbor interface through which 361 these 2-hop neighbor addresses are reachable." 363 REFERENCE 364 "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood 365 Discovery Protocol (NHDP), Clausen, T., Dearlove, 366 C., and J. Dean, April 2011" 367 INDEX { nhdpIfIndex, 368 nhdpDiscIfIndex, 369 nhdpIib2HopSetIpAddressType, 370 nhdpIib2HopSetIpAddress 371 } 372 ::= { nhdpIib2HopSetTable 1 } 374 The SEQUENCE of NhdpIib2HopSetEntry is to be updated, so as to read 375 as follows: 377 NhdpIib2HopSetEntry ::= 378 SEQUENCE { 379 nhdpIib2HopSetIpAddressType 380 InetAddressType, 381 nhdpIib2HopSetIpAddress 382 InetAddress, 383 nhdpIib2HopSetIpAddrPrefixLen 384 InetAddressPrefixLength, 385 nhdpIib2HopSet1HopIfIndex 386 NeighborIfIndex, 387 nhdpIib2HopSetN2Time 388 TimeStamp, 389 nhdpIib2HopSetN2Lost 390 TruthValue 391 } 393 The nhdpIib2HopSetN2Lost OBJECT-TYPE is to be defined as follows: 395 nhdpIib2HopSetN2Lost OBJECT-TYPE 396 SYNTAX TruthValue 397 MAX-ACCESS read-only 398 STATUS current 399 DESCRIPTION 400 "nhdpIib2HopSetN2Lost corresponds to N2_lost of NHDP and 401 is a boolean flag, describing if for a 2-Hop Tuple, the 402 corresponding Link Tuple currently is considered lost 403 due to link quality." 405 REFERENCE 406 "draft-ietf-manet-nhdp-optimization-00" 407 ::= {nhdpIib2HopSetEntry 5} 409 6.2. Updates to the Notification Group 411 This update introduces an additional state for each 2-Hop Tuple. 412 Whereas [RFC6130] has two states for 2-Hop Tuples, 'up' (a 2-Hop 413 Tuple exists) and 'down' (a 2-Hop Tuple expires), this update 414 introduces a third state for a 2-Hop Tuple: it exists, but (due to 415 the link quality of the link to the corresponding 1-Hop neighbor) is 416 not currently considered. 418 To reflect this, the SYNTAX and DESCRIPTION of nhdp2HopNbrState 419 OBJECT-TYPE are to be updated, so as to read as follows: 421 nhdp2HopNbrState OBJECT-TYPE 422 SYNTAX INTEGER { 423 down(0), 424 up(1), 425 notconsidered(2) 426 } 427 MAX-ACCESS read-only 428 STATUS current 429 DESCRIPTION 430 "NHDP 2-hop neighbor states. In NHDP, it is not necessary 431 to remove Protocol Tuples from Protocol Sets at the 432 exact time indicated, only to behave as if the Protocol 433 Tuples were removed at that time. This case is indicated 434 here as 'down(0)'; otherwise, it is either 'up(1)', if 435 N2_lost for the 2-Hop Tuple is equal to false, or 436 'notconsidered(2)' otherwise." 437 ::= { nhdpNotificationsStates 2 } 439 7. IANA Considerations 441 This document has no actions for IANA. 443 [This section may be removed by the RFC Editor.] 445 8. Security Considerations 447 The update to [RFC6130] enables the retention and reuse of some 448 information collected by that protocol, for only the duration that it 449 could have been used in any case. As such, this protocol introduces 450 no new security considerations to an implementation of [RFC6130] or 451 of any other protocol that uses it, such as [RFC7181]. 453 9. Acknowledgments 455 The authors would like to thank Liz Cullen (BAE Systems) for first 456 illustrating the issue addressed in this specification. 458 10. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 464 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 465 RFC 6130, April 2011. 467 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of 468 Managed Objects for the Neighborhood Discovery Protocol", 469 RFC 6779, October 2012. 471 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 472 "The Optimized Link State Routing Protocol version 2", 473 RFC 7181, April 2014. 475 Authors' Addresses 477 Christopher Dearlove 478 BAE Systems Advanced Technology Centre 479 West Hanningfield Road 480 Great Baddow, Chelmsford 481 United Kingdom 483 Phone: +44 1245 242194 484 Email: chris.dearlove@baesystems.com 485 URI: http://www.baesystems.com/ 487 Thomas Heide Clausen 488 LIX, Ecole Polytechnique 490 Phone: +33 6 6058 9349 491 Email: T.Clausen@computer.org 492 URI: http://www.ThomasClausen.org/