idnits 2.17.1 draft-ietf-manet-olsrv2-multitopology-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 23, 2014) is 3593 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'OLSRv2' is mentioned on line 503, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Experimental T. Clausen 5 Expires: December 25, 2014 LIX, Ecole Polytechnique 6 June 23, 2014 8 Multi-Topology Extension for the Optimized Link State Routing Protocol 9 version 2 (OLSRv2) 10 draft-ietf-manet-olsrv2-multitopology-01 12 Abstract 14 This specification describes an extension to the Optimized Link State 15 Routing Protocol version 2 (OLSRv2) to support multiple routing 16 topologies, while retaining interoperability with OLSRv2 routers that 17 do not implement this extension. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 25, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3 55 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 56 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4 57 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 6 60 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 7 64 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 7 65 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 7 66 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 8 70 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 8 71 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 9 72 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 9 73 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 10 75 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 11 77 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 11 78 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 12 80 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 12 81 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 13 82 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 13 83 12. Management Considerations . . . . . . . . . . . . . . . . . . 13 84 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 14 86 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 15 87 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 16 88 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 90 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 16.1. Normative References . . . . . . . . . . . . . . . . . . . 18 92 16.2. Informative References . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 The Optimized Link State Routing Protocol, version 2 [RFC7181] 98 (OLSRv2) is a proactive link state routing protocol designed for use 99 in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant 100 improvements of OLSRv2 over its Experimental precursor [RFC3626] is 101 the ability of OLSRv2 to route over other than minimum hop routes, 102 using a link metric. 104 A limitation that remains in OLSRv2 is that it uses a single link 105 metric type for all routes. However in some MANETs it would be 106 desirable to be able to use alternative metrics for different packet 107 routing. This specification describes an extension to OLSRv2, that 108 is designed to permit this, while maintaining maximal 109 interoperability with OLSRv2 routers not implementing this extension. 111 The purpose of OLSRv2 can be described as to create and maintain a 112 Routing Set, which contains all the necessary information to populate 113 an IP routing table. In a similar way, the role of this extension 114 can be described as to create and maintain multiple Routing Sets, one 115 for each link metric type supported by the router maintaining the 116 sets. 118 2. Terminology and Notation 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119]. 125 This specification uses the terminology of [RFC5444], [RFC6130] and 126 [RFC7181], which is to be interpreted as described in those 127 specifications. 129 Additionally, this specification uses the following terminology: 131 Router - A MANET router that implements [RFC7181]. 133 MT-OLSRv2 - The protocol defined in this specification as an 134 extension to [RFC7181]. 136 This specification introduces the notation map[A -> B] to represent 137 an associative mapping. The domain of this mapping (A) is, in this 138 specification, always a set of link metric types that the router 139 supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as 140 defined in Section 5. The codomain of this mapping (B) is a set of 141 all possible values of an appropriate type, in this specification 142 this type is always one of: 144 o boolean (true or false), 146 o willingness (a 4 bit unsigned integer from 0 to 15); 148 o number of hops (an 8 bit unsigned integer from 0 to 255), or 150 o link metric (either a representable link metric value, as 151 described in [RFC7181], or UNKNOWN_METRIC). 153 3. Applicability Statement 155 The protocol described in this specification is applicable to a MANET 156 for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), 157 but in which multiple topologies are maintained, each characterized 158 by a different choice of link metric type. It is assumed, but 159 outside the scope of this specification, that the network layer is 160 able to choose which topology to use for each packet, for example 161 using the DiffServ Code Point (DSCP) defined in [RFC2474]. 163 4. Protocol Overview and Functioning 165 The purpose of this specification is to extend [RFC7181] so as to 166 enable a router to establish and maintain multiple routing topologies 167 in a MANET, each topology associated with a link metric type. 168 Routers in the MANET may each form part of some or all of these 169 topologies, and each router will maintain a Routing Set for each 170 topology that it forms part of, allowing separate routing of packets 171 for each topology. 173 Each router implementing this specification selects a set of link 174 metric types for each of its OLSRv2 interfaces. If all routers in 175 the MANET implement MT-OLSRv2, then there are no restrictions on how 176 these sets of link metrics are selected. However there may be 177 deployments where routers, that do not implement MT-OLSRv2 (non-MT- 178 OLSRv2 routers), are to participate in a MANET with MT-OLSRv2 179 routers. In this case, the single link metric used by these non-MT- 180 OLSRv2 routers must be included in the set of link metrics for each 181 OLSRv2 interface of an MT-OLSRv2 router that may be heard on an 182 OLSRv2 interface of a non-MT-OLSRv2 router in the MANET. 184 Each router then determines an incoming link metric for each link 185 metric type selected for each of its OLSRv2 interfaces. These link 186 metrics are distributed using link metric TLVs contained in all HELLO 187 messages sent on OLSRv2 interfaces, and in all TC messages. 189 In addition to link and neighbor metric values for each link metric 190 type, router MPR (multipoint relay) and MPR selector status, and 191 advertised neighbor status, is maintained per supported neighbor 192 metric type for each symmetric 1-hop neighbor. Each router may 193 choose a different willingness to be a routing MPR for each link 194 metric type that it supports. 196 More so than OLSRv2, the use of multiple metric types across the 197 MANET must be managed, by administrative configuration or otherwise. 198 Similarly to other decisions that may be made using OLSRv2, a bad 199 collective choice will make the MANET anywhere from inefficient to 200 non-functional, so care will be needed in selecting supported link 201 metric types across the MANET. 203 5. Parameters 205 The parameters used in [RFC7181], including from its normative 206 references, are used in this specification with the following 207 changes. 209 Each OLSRv2 interface will support a number of link metric types, 210 corresponding to Type Extensions of the LINK_METRIC TLV defined in 211 [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers 212 that do not implement MT-OLSRv2, and used with that definition in 213 this specification, is replaced in routers implementing MT-OLSRv2 by 214 an interface parameter array IFACE_METRIC_TYPES and a router 215 parameter array ROUTER_METRIC_TYPES. Each element in these arrays is 216 a link metric type (i.e., a type extension used by the LINK_METRIC 217 TLV [RFC7181]). 219 The interface parameter array IFACE_METRIC_TYPES contains the link 220 metric types supported on that OLSRv2 interface. The router 221 parameter array ROUTER_METRIC_TYPES is the union of all of the 222 IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. 224 If in a given deployment there may be any routers that do not 225 implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include 226 LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate 227 with any routers that do not implement MT-OLSRv2. In that case, 228 ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE. 230 In addition, the router parameter WILL_ROUTING is extended to an 231 array of values, one each for each link metric type in the router 232 parameter list ROUTER_METRIC_TYPES. 234 6. Information Bases 236 The Information Bases specified in [RFC7181], which extend those 237 specified in in [RFC6130], are further extended in this 238 specification. With the exception of the Routing Set, the extensions 239 in this specification are the replacement of single values (boolean, 240 willingness, number of hops, or link-metric) from [RFC7181] with 241 elements representing multiple values (associative mappings from a 242 set of metric types to their corresponding values). The following 243 subsections detail these extensions. 245 Note that, as in [RFC7181], an implementation is free to organize its 246 internal data in any manner it chooses, it needs only to behave as if 247 it were organized as described in [RFC7181] and this specification. 249 6.1. Local Attached Network Set 251 Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of 252 hops]. 254 Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link 255 metric]. 257 6.2. Link Sets 259 Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link 260 metric]. 262 Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link 263 metric]. 265 The elements of L_in_metric MUST be set following the same rules that 266 apply to the setting of the single element L_in_metric in [RFC7181]. 268 6.3. 2-Hop Sets 270 Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 271 metric]. 273 Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 274 metric]. 276 6.4. Neighbor Set 278 Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 279 metric]. 281 Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 282 metric]. 284 Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> 285 willingness]. 287 Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> 288 boolean]. 290 Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> 291 boolean]. 293 Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> 294 boolean]. 296 6.5. Router Topology Set 298 Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link 299 metric]. 301 Note that some values of TR_metric may now take the value 302 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 303 corresponding link metric value from this mapping is used, Router 304 Topology Tuples whose corresponding value from TR_metric is 305 UNKNOWN_METRIC are ignored. 307 6.6. Routable Address Topology Set 309 Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link 310 metric]. 312 Note that some values of TA_metric may now take the value 313 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 314 corresponding link metric value from this mapping is used, Routable 315 Address Topology Tuples whose corresponding value from TA_metric is 316 UNKNOWN_METRIC are ignored. 318 6.7. Attached Network Set 320 Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of 321 hops]. 323 Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link 324 metric]. 326 Note that some values of AN_metric may now take the value 327 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 328 corresponding link metric value from this mapping is used, Attached 329 Network Tuples whose corresponding value from AN_metric is 330 UNKNOWN_METRIC are ignored. 332 6.8. Routing Sets 334 There is a separate Routing Set for each link metric type in 335 ROUTER_METRIC_TYPES. 337 7. TLVs 339 This specification makes the following additions and extensions to 340 the TLVs defined in [RFC7181]. 342 7.1. Message TLVs 344 One new Message TLV is defined in this specification, and one 345 existing Message TLV is extended by this specification. 347 7.1.1. MPR_TYPES TLV 349 The MPR_TYPES TLV is used in HELLO messages, and may be used in TC 350 messages. A message MUST NOT contain more than one MPR_TYPES TLV. 352 The presence of this TLV in a HELLO message is used to indicate that 353 the router supports MT-OLSRv2, in the same way that the presence of 354 the MPR_WILLING TLV is used to indicate that the router supports 355 OLSRv2, as specified in [RFC7181]. For this reason, the MPR_TYPES 356 TLV has been defined with the same Type as the MPR_WILLING TLV, but 357 with Type Extension == 1. (The different symbolic name is used for 358 convenience, any reference to a MPR_TYPES TLV means to this TLV, with 359 this Type and Type Extension.) 361 This TLV may take a Value field of any size. Each octet in its Value 362 field will contain a link metric type that is supported for the 363 OLSRv2 interface over which the HELLO message containing this TLV is 364 sent. These octets MAY be in any order, except that if there may be 365 any routers in the MANET not implementing MT-OLSRv2, then the first 366 octet MUST be LINK_METRIC_TYPE. 368 7.1.2. MPR_WILLING TLV 370 The MPR_WILLING TLV, which is used in HELLO messages, is specified in 371 [RFC7181], and extended in this specification as enabled by 372 [RFC7188]. 374 The interpretation of this TLV, specified by [RFC7181], and which 375 uses all of its single octet Value field, is unchanged. That 376 interpretation uses bits 0-3 of its Value field to specify its 377 willingness to be a flooding TLV, and bits 4-7 of its Value field to 378 be a routing TLV. Those latter bits are, when using this 379 specification, interpreted as its willingness to be a routing TLV 380 using the link metric type LINK_METRIC_TYPE. 382 The extended use of this message TLV, as defined by this 383 specification, defines additional 4 bit sub-fields of the Value 384 field, starting with bits 4-7 of the first octet and continuing with 385 bits 0-3 of the second octet, to represent willingness to be a 386 routing MPR using the link metric types specified in this OLSRv2 387 interface's IFACE_METRIC_TYPES parameter, ordered as reported in the 388 included MPR_TYPES Message TLV. (If there is no such TLV included, 389 then the router does not support MT-OLSRv2, and only the first octet 390 of the Value field will be used.) 392 If the number of link metric types in this OLSRv2 interface's 393 IFACE_METRIC_TYPES parameter is even, then there will be an unused 4 394 bit sub-field in bits 4-7 of the last octet of a full sized Value 395 field. These bits will not be used, they SHOULD all be cleared 396 ('0'). 398 If the Value field in an MPR_WILLING TLV is shorter than its full 399 length, then, as specified in [RFC7188], missing Value octets, i.e., 400 missing willingness values, are considered as zero, i.e., as 401 WILL_NEVER. This is the correct behavior. (In particular it means 402 that an OLSRv2 router that is not implementing MT-OLSRv2 will not act 403 as a routing MPR for any link metric that it does not recognize.) 405 7.2. Address Block TLVs 407 New Type Extensions are defined for the LINK_METRIC TLV defined in 408 [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, 409 both defined in [RFC7181], are extended, as enabled by [RFC7188]. 411 7.2.1. LINK_METRIC TLV 413 The LINK_METRIC TLV is used in HELLO messages and TC messages. This 414 TLV is unchanged from the definition in [RFC7181]. 416 Only a single Type Extension was specified by [RFC7181] (link metric 417 type) 0 as defined by administrative action. This specification 418 extends this range, it is suggested either to 0-7 or to 0-15. This 419 specification will work with any combination of Type Extensions both 420 within and without that range (assuming that the latter are defined 421 as specified in [RFC7181]). 423 7.2.2. MPR TLV 425 The MPR TLV is used in HELLO messages, and indicates that an address 426 with which it is associated is of a symmetric 1-hop neighbor that has 427 been selected as an MPR. 429 The Value field of this address block TLV is, in [RFC7181], defined 430 to be one octet long, with the values 1, 2 and 3 defined. [RFC7188] 431 redefines this Value field to be a bitfield where bit 7 (the lsb) 432 denotes flooding status, bit 6 denotes routing MPR status, and bits 433 5-0 are unallocated (respecting the semantics of the bits/values 1, 2 434 and 3 from [RFC7181]). 436 This specification, as enabled by [RFC7188], extends the MPR TLV to 437 have a variable-length Value field. For interoperability with a 438 router not implementing MT-OLSRv2, the two least significant bits of 439 the first octet in the Value field of this TLV MUST be the TLV Value 440 of the MPR TLV, generated according to [RFC7181]. 442 Subsequent bits (in increasing significance within an octet, then 443 continuing with the least significant bit in the next octet, if 444 required) in the TLV Value field indicate which link metric types, 445 for which the corresponding address is selected as a routing MPR, 446 link metric types (including the first) being indicated in the Value 447 field of an MPR_TYPES Message TLV. 449 7.2.3. GATEWAY TLV 451 The GATEWAY TLV is used in TC messages to indicate that a network 452 address is of an attached network. 454 The Value field of this address block TLV is, in [RFC7181] defined to 455 be one octet long, containing the number of hops to that attached 456 network. 458 This specification, as enabled by [RFC7181], allows the extension the 459 GATEWAY TLV to have a variable-length Value field when the number of 460 hops to each attached network is different for different link metric 461 types. For interoperability with a router not implementing MT- 462 OLSRv2, the first octet in the Value field of this TLV MUST be the 463 TLV Value of the GATEWAY TLV generated according to [RFC7181]. 465 Any subsequent octets in the TLV Value field indicate the number of 466 hops to the attached network for each other link metric type, link 467 metric types (including the first) being indicated in the Value field 468 of an MPR_TYPES Message TLV. 470 +---------+---------------------------------------------------------+ 471 | Type | Value | 472 +---------+---------------------------------------------------------+ 473 | GATEWAY | Number of hops to attached network for each link metric | 474 | | type. | 475 +---------+---------------------------------------------------------+ 477 Table 1: GATEWAY TLV definition 479 8. HELLO Messages 481 The following changes are made to the generation and processing of 482 HELLO messages compared to that described in [RFC7181] by routers 483 that implement MT-OLSRv2. 485 8.1. HELLO Message Generation 487 A generated HELLO message to be sent on an OLSRv2 interface is 488 extended by: 490 o Adding an MPR_TYPES TLV. The value octets will be the link metric 491 types in IFACE_METRIC_TYPES. 493 o Extending the MPR_WILLING TLV Value field to report the 494 willingness values from the WILL_ROUTING parameter list that 495 correspond to the link metric types in IFACE_METRIC_LIST, in the 496 same order as reported in the MPR_TYPES TLV, each value (also 497 including one representing WILL_FLOODING) occupying 4 bits. 499 o Including LINK_METRIC TLVs that report all values of L_in_metric, 500 L_out_metric, N_in_metric and N_out_metric that are not equal to 501 UNKNOWN_METRIC, with the TLV Type Extension being the link metric 502 type, and otherwise following the rules for such inclusions 503 specified in [OLSRv2]. 505 o Including MPR TLVs such that for each link metric type in 506 IFACE_METRIC_TYPES, and for the choice of flooding MPRs, these 507 MUST be an MPR set as specified for a single link metric type in 508 [RFC7181]. 510 8.2. HELLO Message Processing 512 On receipt of a HELLO message, a router implementing MT-OLSRv2 MUST, 513 in addition to the processing described in [RFC7181]: 515 1. Determine the list of link metric types supported by the sending 516 router on the relevant OLSRv2 interface, either from an MPR_TYPES 517 TLV or, if not present, the type LINK_METRIC_TYPE supported by a 518 router not implementing the extension described in this 519 specification. 521 2. For those link metric types supported by both routers, set the 522 appropriate L_out_metric, N_in_metric, N_out_metric, 523 N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and 524 N2_out_metric values as described for the single such elements in 525 [RFC7181]. 527 3. For any other metric types supported by the receiving router 528 only, set those elements to their default value: UNKNOWN_METRIC, 529 WILL_NEVER (not WILL_DEFAULT), or false. 531 9. TC Messages 533 The following changes are made to the generation and processing of TC 534 messages compared to that described in [RFC7181] by routers that 535 implement MT-OLSRv2. 537 9.1. TC Message Generation 539 A generated TC message is extended by: 541 o If any GATEWAY TLVs are included requiring more than one number of 542 hops value, then adding an MPR_TYPES TLV with Value octets being 543 the link metric types in ROUTER_METRIC_TYPES. 545 o Including LINK_METRIC TLVs that report all values of N_out_metric 546 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 547 being the link metric type, and otherwise following the rules for 548 such inclusions specified in [RFC7181]. 550 o When not all the same, including a number of hops per reported (in 551 an MPR_TYPES Message TLV) link metric type in the Value field of 552 each GATEWAY TLV included. 554 9.2. TC Message Processing 556 On receipt of a TC message, a router implementing this extension 557 MUST, in addition to the processing specified in [RFC7181]: 559 o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric 560 elements using the rules for setting the single elements of those 561 types specified in [RFC7181]. 563 o For any other metric types supported by the receiving router that 564 do not have an advertised outgoing neighbor metric of that type, 565 set the corresponding elements of TR_metric, TA_metric and 566 AN_metric to UNKNOWN_METRIC. (The corresponding element of 567 AN_dist may be set to any value.) 569 10. MPR Calculation 571 Routing MPRs are calculated for each link metric type in 572 ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 573 interfaces that do not support that link metric type are not 574 considered. The determined status (routing MPR or not routing MPR) 575 for each link metric type is recorded in the relevant element of 576 N_routing_mpr. 578 Each router may make its own decision as to whether or not to use a 579 link metric, or link metrics, for flooding MPR calculation, and if so 580 which and how. This decision MUST be made in a manner that ensures 581 that flooded messages will reach the same symmetric 2-hop neighbors 582 as would be the case for a router not supporting MT-OLSRv2. 584 Note that it is possible that a 2-Hop Tuple in the Information Base 585 for a given OLSRv2 interface does not support any of the link metric 586 types that are in the router's corresponding IFACE_METRIC_TYPES, but 587 nevertheless that 2-Hop Tuple MUST be considered when determining 588 flooding MPRs. 590 11. Routing Set Calculation 592 A Routing Set is calculated for each link metric type in 593 ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except 594 that where an element is now represented by a map, the value from the 595 map for the selected link metric type is used. Where this is a link 596 metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for 597 the calculation. 599 12. Management Considerations 601 MT-OLSRv2 may require greater management than unextended OLSRv2. In 602 particular MT-OLSRv2 requires the following management 603 considerations: 605 o Selecting which link metrics to support on each OLSRv2 interface 606 and implementing that decision. (Different interfaces may have 607 different physical and data link layer properties, and this may 608 inform the selection of link metrics to support, and their 609 values.) 611 o Ensuring that the MANET is sufficiently connected. Note that if 612 there is any possibility that there are any routers not 613 implementing MT-OLSRv2, then the MANET will be connected, to the 614 maximum extent possible, using the link metric type 615 LINK_METRIC_TYPE. 617 o Deciding which link metric, and hence which Routing Set to use, 618 for received packets, hence how to use the Routing Sets to 619 configure the network layer (IP). An obvious approach is to map 620 each DiffServ Code Point (DSCP) [RFC2474] to a single link metric. 621 (This may be a many to one mapping.) 623 o Note that there could be cases where a router that is not 624 implementing MT-OLSRv2 is the source or destination of an IP 625 packet that is mapped to a link metric that is not the link metric 626 LINK_METRIC_TYPE used by that router. 628 o If such a router is the source, then routing may work if the first 629 router implementing MT-OLSRv2 to receive the packet supports the 630 appropriate link metric type. At worst the packet will be 631 dropped, it will not loop. 633 o If such a router is the destination, then the packet will never 634 reach its destination, as the source will not have a suitable 635 routing table entry for the destination. Network management may 636 be required to ensure that the MANET still functions in these 637 cases. 639 13. IANA Considerations 641 This specification adds one new Message TLV, allocated as a new Type 642 Extension to an existing Message TLV, using a new name. It also 643 modifies the Value field of an existing Message TLV, and of an 644 existing Address Block TLV. Finally, this specification makes 645 additional allocations from the LINK_METRIC Address Block TLV Type 646 registry. 648 13.1. Expert Review: Evaluation Guidelines 650 For the registry where an Expert Review is required, the designated 651 expert SHOULD take the same general recommendations into 652 consideration as are specified by [RFC5444]. 654 13.2. Message TLV Types 656 This specification replaces Table 11 of [RFC7181]. That specified a 657 Message MPR Type described as MPR_WILLING, for which only Type 658 Extension 0 was defined. This specification reserves that name 659 MPR_WILLING for Type Extension 0, defines a new Type Extension 1, 660 with a new name MPR_TYPES, and leaves the remaining Type Extensions 661 of this TLV Type unnamed. It also changes the Value field 662 specification of the MPR_WILLING TLV. 664 Specifications of these TLVs are in Table 2. Each of these TLVs MUST 665 NOT be included more than once in a Message TLV Block. 667 +-------------+------+-----------+---------------------+------------+ 668 | Name | Type | Type | Description | Allocation | 669 | | | Extension | | Policy | 670 +-------------+------+-----------+---------------------+------------+ 671 | MPR_WILLING | 7 | 0 | Bits 0-3 specify | | 672 | | | | the originating | | 673 | | | | router's | | 674 | | | | willingness to act | | 675 | | | | as a flooding MPR. | | 676 | | | | Each following 4 | | 677 | | | | bit subfield (using | | 678 | | | | bits 0-3 of an | | 679 | | | | octet before bits | | 680 | | | | 4-7) specifies the | | 681 | | | | originating | | 682 | | | | router's | | 683 | | | | willingness to act | | 684 | | | | as a routing MPR | | 685 | | | | for a link metric, | | 686 | | | | either a single | | 687 | | | | such field (bits | | 688 | | | | 4-7) when no | | 689 | | | | MPR_TYPES Message | | 690 | | | | TLV is present, or | | 691 | | | | one subfield per | | 692 | | | | type reported in an | | 693 | | | | MPR_TYPES Message | | 694 | | | | TLV Value field (in | | 695 | | | | the same order). | | 696 | MPR_TYPES | 7 | 1 | The link metric | | 697 | | | | types supported on | | 698 | | | | this OLSRv2 | | 699 | | | | interface of this | | 700 | | | | router (one octet | | 701 | | | | each). | | 702 | Unnamed | 7 | 2-255 | Unassigned. | Expert | 703 | | | | | Review | 704 +-------------+------+-----------+---------------------+------------+ 706 Table 2: Message TLV Type assignment: MPR_WILLING and MPR_TYPES 708 13.3. Address Block TLV Types 710 Table 16 of [RFC7181] is replaced by Table 3. Note that the only 711 change is to the description of the Value field. 713 +---------+------+-----------+-------------------------+------------+ 714 | Name | Type | Type | Description | Allocation | 715 | | | extension | | Policy | 716 +---------+------+-----------+-------------------------+------------+ 717 | GATEWAY | 10 | 0 | Specifies that a given | | 718 | | | | network address is | | 719 | | | | reached via a gateway | | 720 | | | | on the originating | | 721 | | | | router. The number of | | 722 | | | | hops is indicated by | | 723 | | | | the Value field, either | | 724 | | | | using a single octet | | 725 | | | | (if no MPR_TYPES | | 726 | | | | Message TLV is present) | | 727 | | | | or one octet per type | | 728 | | | | reported in an | | 729 | | | | MPR_TYPES Message TLV | | 730 | | | | (in the same order). | | 731 | GATEWAY | 10 | 1-255 | | Expert | 732 | | | | | Review | 733 +---------+------+-----------+-------------------------+------------+ 735 Table 3: Address Block TLV Type assignment: GATEWAY 737 Table 13 of [RFC7181] is replaced by Table 4. Note that the only 738 change is to allocate 8 Type Extensions as assigned by administrative 739 action, in order to support administratively determined multi- 740 topologies. 742 +-------------+------+-----------+-------------------+--------------+ 743 | Name | Type | Type | Description | Allocation | 744 | | | Extension | | Policy | 745 +-------------+------+-----------+-------------------+--------------+ 746 | LINK_METRIC | 7 | 0-7 | Link metric | | 747 | | | | meaning assigned | | 748 | | | | by administrative | | 749 | | | | action. | | 750 | LINK_METRIC | 7 | 8-223 | Unassigned. | Expert | 751 | | | | | Review | 752 | LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental | 753 | | | | | Use | 754 +-------------+------+-----------+-------------------+--------------+ 756 Table 4: Address Block TLV Type assignment: LINK_METRIC 758 14. Security Considerations 760 This extension to OLSRv2 allows a router to support more than one 761 link metric type for each link advertised in HELLO and TC messages, 762 and for routers to support different sets of types. Link metric 763 values of additional types are reported by the inclusion of 764 additional TLVs in the messages sent by a router, which will report 765 known values of all supported types. 767 HELLO and TC message processing is then extended simply to record, 768 for each supported type, all of the received link metric values for 769 each link. Protocol internal processing (specifically MPR set and 770 shortest path calculations) then operate as specified in [RFC7181] 771 for each link metric type that the router supports. 773 Consequently the security considerations, including the security 774 architecture and the mandatory security mechanisms, from [RFC7181] 775 are directly applicable to MT-OLSRv2. 777 Furthermore, this extension does not introduce any additional 778 vulnerabilities over those of [RFC7181], because each link metric 779 type is used independently, and each one could have been the single 780 link metric type supported by an implementation of [RFC7181] 781 receiving the same information, as received information of an 782 unsupported type is ignored by all routers. 784 15. Acknowledgments 786 TBD. 788 16. References 790 16.1. Normative References 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 796 "Generalized MANET Packet/Message Format", RFC 5444, 797 February 2009. 799 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 800 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 801 RFC 6130, April 2011. 803 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 804 "The Optimized Link State Routing Protocol version 2", 805 RFC 7181, April 2014. 807 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 808 Protocol version 2 (OLSRv2) and MANET Neighborhood 809 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 810 April 2014. 812 16.2. Informative References 814 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 815 "Definition of the Differentiated Services Field (DS 816 Field) in the IPv4 and IPv6 Headers", RFC 2474, 817 December 1998. 819 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 820 (MANET): Routing Protocol Performance Issues and 821 Evaluation Considerations", RFC 2501, January 1999. 823 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 824 Routing Protocol", RFC 3626, October 2003. 826 Authors' Addresses 828 Christopher Dearlove 829 BAE Systems Advanced Technology Centre 830 West Hanningfield Road 831 Great Baddow, Chelmsford 832 United Kingdom 834 Phone: +44 1245 242194 835 Email: chris.dearlove@baesystems.com 836 URI: http://www.baesystems.com/ 838 Thomas Heide Clausen 839 LIX, Ecole Polytechnique 841 Phone: +33 6 6058 9349 842 Email: T.Clausen@computer.org 843 URI: http://www.ThomasClausen.org/