idnits 2.17.1 draft-ietf-manet-olsrv2-multitopology-02.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 25, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'OLSRv2' is mentioned on line 539, 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 27, 2014 LIX, Ecole Polytechnique 6 June 25, 2014 8 Multi-Topology Extension for the Optimized Link State Routing Protocol 9 version 2 (OLSRv2) 10 draft-ietf-manet-olsrv2-multitopology-02 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 27, 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 1.1. Motivation and Experimentation . . . . . . . . . . . . . . 3 55 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 56 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 57 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5 58 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 7 61 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 8 65 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 8 66 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 8 67 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 9 71 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 9 72 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 10 73 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 10 74 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 11 76 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 12 78 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 12 79 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 13 81 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 13 82 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 13 83 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 14 84 12. Management Considerations . . . . . . . . . . . . . . . . . . 14 85 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 15 87 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 15 88 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 16 89 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 91 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 16.1. Normative References . . . . . . . . . . . . . . . . . . . 18 93 16.2. Informative References . . . . . . . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 The Optimized Link State Routing Protocol, version 2 [RFC7181] 99 (OLSRv2) is a proactive link state routing protocol designed for use 100 in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant 101 improvements of OLSRv2 over its Experimental precursor [RFC3626] is 102 the ability of OLSRv2 to route over other than minimum hop routes, 103 using a link metric. 105 A limitation that remains in OLSRv2 is that it uses a single link 106 metric type for all routes. However in some MANETs it would be 107 desirable to be able to use alternative metrics for different packet 108 routing. This specification describes an extension to OLSRv2, that 109 is designed to permit this, while maintaining maximal 110 interoperability with OLSRv2 routers not implementing this extension. 112 The purpose of OLSRv2 can be described as to create and maintain a 113 Routing Set, which contains all the necessary information to populate 114 an IP routing table. In a similar way, the role of this extension 115 can be described as to create and maintain multiple Routing Sets, one 116 for each link metric type supported by the router maintaining the 117 sets. 119 1.1. Motivation and Experimentation 121 Multi-topology routing is a natural extension to a link state routing 122 protocol, as for example to OSPF (see [RFC4915]). However multi- 123 topology routing for OLSRv2 does not yet benefit from extensive 124 operational, or even experimental, experience. This specification is 125 published to facilitate collecting such experience, with the intent 126 that in a reasonable period of time after the acceptance of this 127 specification as an Experimental RFC (as soon as possible after 128 experimental evidence is collected), an OLSRv2 Multi-Topology Routing 129 Extension will be proposed for advancement onto Standards Track. 131 While general experiences with this protocol extension, including 132 interoperability of implementations, are encouraged, specific 133 information would be particularly appreciated on the following areas: 135 o Operation in a network that contains both routers implementing 136 this extension, and routers implementing only [RFC7181], in 137 particular are there any unexpected interactions that can break 138 the network? 140 o Operation in realistic deployments, and details thereof, including 141 in particular indicating how many concurrent topologies were 142 required. 144 A broader issue that applies to unextended [RFC7181] as well as this 145 extension (and potentially to other MANET routing protocols) is which 146 link metric types are useful in a MANET, and how to establish the 147 metrics to associate with a given link. While this issue is not only 148 related to this extension, the ability for an OLSRv2 network to 149 maintain different concurrent link metrics may facilitate both 150 experiments with different link metric types, ways to measure them, 151 etc. and may also allow experimentation with link metric types that 152 are not compromises to handle multiple traffic types. 154 2. Terminology and Notation 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in 159 [RFC2119]. 161 This specification uses the terminology of [RFC5444], [RFC6130] and 162 [RFC7181], which is to be interpreted as described in those 163 specifications. 165 Additionally, this specification uses the following terminology: 167 Router - A MANET router that implements [RFC7181]. 169 MT-OLSRv2 - The protocol defined in this specification as an 170 extension to [RFC7181]. 172 This specification introduces the notation map[A -> B] to represent 173 an associative mapping. The domain of this mapping (A) is, in this 174 specification, always a set of link metric types that the router 175 supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as 176 defined in Section 5. The codomain of this mapping (B) is a set of 177 all possible values of an appropriate type, in this specification 178 this type is always one of: 180 o boolean (true or false), 182 o willingness (a 4 bit unsigned integer from 0 to 15); 184 o number of hops (an 8 bit unsigned integer from 0 to 255), or 186 o link metric (either a representable link metric value, as 187 described in [RFC7181], or UNKNOWN_METRIC). 189 3. Applicability Statement 191 The protocol described in this specification is applicable to a MANET 192 for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), 193 but in which multiple topologies are maintained, each characterized 194 by a different choice of link metric type. It is assumed, but 195 outside the scope of this specification, that the network layer is 196 able to choose which topology to use for each packet, for example 197 using the DiffServ Code Point (DSCP) defined in [RFC2474]. 199 4. Protocol Overview and Functioning 201 The purpose of this specification is to extend [RFC7181] so as to 202 enable a router to establish and maintain multiple routing topologies 203 in a MANET, each topology associated with a link metric type. 204 Routers in the MANET may each form part of some or all of these 205 topologies, and each router will maintain a Routing Set for each 206 topology that it forms part of, allowing separate routing of packets 207 for each topology. 209 Each router implementing this specification selects a set of link 210 metric types for each of its OLSRv2 interfaces. If all routers in 211 the MANET implement MT-OLSRv2, then there are no restrictions on how 212 these sets of link metrics are selected. However there may be 213 deployments where routers, that do not implement MT-OLSRv2 (non-MT- 214 OLSRv2 routers), are to participate in a MANET with MT-OLSRv2 215 routers. In this case, the single link metric used by these non-MT- 216 OLSRv2 routers must be included in the set of link metrics for each 217 OLSRv2 interface of an MT-OLSRv2 router that may be heard on an 218 OLSRv2 interface of a non-MT-OLSRv2 router in the MANET. 220 Each router then determines an incoming link metric for each link 221 metric type selected for each of its OLSRv2 interfaces. These link 222 metrics are distributed using link metric TLVs contained in all HELLO 223 messages sent on OLSRv2 interfaces, and in all TC messages. 225 In addition to link and neighbor metric values for each link metric 226 type, router MPR (multipoint relay) and MPR selector status, and 227 advertised neighbor status, is maintained per supported neighbor 228 metric type for each symmetric 1-hop neighbor. Each router may 229 choose a different willingness to be a routing MPR for each link 230 metric type that it supports. 232 More so than OLSRv2, the use of multiple metric types across the 233 MANET must be managed, by administrative configuration or otherwise. 234 Similarly to other decisions that may be made using OLSRv2, a bad 235 collective choice will make the MANET anywhere from inefficient to 236 non-functional, so care will be needed in selecting supported link 237 metric types across the MANET. 239 5. Parameters 241 The parameters used in [RFC7181], including from its normative 242 references, are used in this specification with the following 243 changes. 245 Each OLSRv2 interface will support a number of link metric types, 246 corresponding to Type Extensions of the LINK_METRIC TLV defined in 247 [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers 248 that do not implement MT-OLSRv2, and used with that definition in 249 this specification, is replaced in routers implementing MT-OLSRv2 by 250 an interface parameter array IFACE_METRIC_TYPES and a router 251 parameter array ROUTER_METRIC_TYPES. Each element in these arrays is 252 a link metric type (i.e., a type extension used by the LINK_METRIC 253 TLV [RFC7181]). 255 The interface parameter array IFACE_METRIC_TYPES contains the link 256 metric types supported on that OLSRv2 interface. The router 257 parameter array ROUTER_METRIC_TYPES is the union of all of the 258 IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. 260 If in a given deployment there may be any routers that do not 261 implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include 262 LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate 263 with any routers that do not implement MT-OLSRv2. In that case, 264 ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE. 266 In addition, the router parameter WILL_ROUTING is extended to an 267 array of values, one each for each link metric type in the router 268 parameter list ROUTER_METRIC_TYPES. 270 6. Information Bases 272 The Information Bases specified in [RFC7181], which extend those 273 specified in in [RFC6130], are further extended in this 274 specification. With the exception of the Routing Set, the extensions 275 in this specification are the replacement of single values (boolean, 276 willingness, number of hops, or link-metric) from [RFC7181] with 277 elements representing multiple values (associative mappings from a 278 set of metric types to their corresponding values). The following 279 subsections detail these extensions. 281 Note that, as in [RFC7181], an implementation is free to organize its 282 internal data in any manner it chooses, it needs only to behave as if 283 it were organized as described in [RFC7181] and this specification. 285 6.1. Local Attached Network Set 287 Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of 288 hops]. 290 Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link 291 metric]. 293 6.2. Link Sets 295 Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link 296 metric]. 298 Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link 299 metric]. 301 The elements of L_in_metric MUST be set following the same rules that 302 apply to the setting of the single element L_in_metric in [RFC7181]. 304 6.3. 2-Hop Sets 306 Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 307 metric]. 309 Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 310 metric]. 312 6.4. Neighbor Set 314 Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 315 metric]. 317 Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 318 metric]. 320 Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> 321 willingness]. 323 Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> 324 boolean]. 326 Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> 327 boolean]. 329 Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> 330 boolean]. 332 6.5. Router Topology Set 334 Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link 335 metric]. 337 Note that some values of TR_metric may now take the value 338 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 339 corresponding link metric value from this mapping is used, Router 340 Topology Tuples whose corresponding value from TR_metric is 341 UNKNOWN_METRIC are ignored. 343 6.6. Routable Address Topology Set 345 Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link 346 metric]. 348 Note that some values of TA_metric may now take the value 349 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 350 corresponding link metric value from this mapping is used, Routable 351 Address Topology Tuples whose corresponding value from TA_metric is 352 UNKNOWN_METRIC are ignored. 354 6.7. Attached Network Set 356 Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of 357 hops]. 359 Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link 360 metric]. 362 Note that some values of AN_metric may now take the value 363 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 364 corresponding link metric value from this mapping is used, Attached 365 Network Tuples whose corresponding value from AN_metric is 366 UNKNOWN_METRIC are ignored. 368 6.8. Routing Sets 370 There is a separate Routing Set for each link metric type in 371 ROUTER_METRIC_TYPES. 373 7. TLVs 375 This specification makes the following additions and extensions to 376 the TLVs defined in [RFC7181]. 378 7.1. Message TLVs 380 One new Message TLV is defined in this specification, and one 381 existing Message TLV is extended by this specification. 383 7.1.1. MPR_TYPES TLV 385 The MPR_TYPES TLV is used in HELLO messages, and may be used in TC 386 messages. A message MUST NOT contain more than one MPR_TYPES TLV. 388 The presence of this TLV in a HELLO message is used to indicate that 389 the router supports MT-OLSRv2, in the same way that the presence of 390 the MPR_WILLING TLV is used to indicate that the router supports 391 OLSRv2, as specified in [RFC7181]. For this reason, the MPR_TYPES 392 TLV has been defined with the same Type as the MPR_WILLING TLV, but 393 with Type Extension == 1. (The different symbolic name is used for 394 convenience, any reference to a MPR_TYPES TLV means to this TLV, with 395 this Type and Type Extension.) 397 This TLV may take a Value field of any size. Each octet in its Value 398 field will contain a link metric type that is supported for the 399 OLSRv2 interface over which the HELLO message containing this TLV is 400 sent. These octets MAY be in any order, except that if there may be 401 any routers in the MANET not implementing MT-OLSRv2, then the first 402 octet MUST be LINK_METRIC_TYPE. 404 7.1.2. MPR_WILLING TLV 406 The MPR_WILLING TLV, which is used in HELLO messages, is specified in 407 [RFC7181], and extended in this specification as enabled by 408 [RFC7188]. 410 The interpretation of this TLV, specified by [RFC7181], and which 411 uses all of its single octet Value field, is unchanged. That 412 interpretation uses bits 0-3 of its Value field to specify its 413 willingness to be a flooding TLV, and bits 4-7 of its Value field to 414 be a routing TLV. Those latter bits are, when using this 415 specification, interpreted as its willingness to be a routing TLV 416 using the link metric type LINK_METRIC_TYPE. 418 The extended use of this message TLV, as defined by this 419 specification, defines additional 4 bit sub-fields of the Value 420 field, starting with bits 4-7 of the first octet and continuing with 421 bits 0-3 of the second octet, to represent willingness to be a 422 routing MPR using the link metric types specified in this OLSRv2 423 interface's IFACE_METRIC_TYPES parameter, ordered as reported in the 424 included MPR_TYPES Message TLV. (If there is no such TLV included, 425 then the router does not support MT-OLSRv2, and only the first octet 426 of the Value field will be used.) 428 If the number of link metric types in this OLSRv2 interface's 429 IFACE_METRIC_TYPES parameter is even, then there will be an unused 4 430 bit sub-field in bits 4-7 of the last octet of a full sized Value 431 field. These bits will not be used, they SHOULD all be cleared 432 ('0'). 434 If the Value field in an MPR_WILLING TLV is shorter than its full 435 length, then, as specified in [RFC7188], missing Value octets, i.e., 436 missing willingness values, are considered as zero, i.e., as 437 WILL_NEVER. This is the correct behavior. (In particular it means 438 that an OLSRv2 router that is not implementing MT-OLSRv2 will not act 439 as a routing MPR for any link metric that it does not recognize.) 441 7.2. Address Block TLVs 443 New Type Extensions are defined for the LINK_METRIC TLV defined in 444 [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, 445 both defined in [RFC7181], are extended, as enabled by [RFC7188]. 447 7.2.1. LINK_METRIC TLV 449 The LINK_METRIC TLV is used in HELLO messages and TC messages. This 450 TLV is unchanged from the definition in [RFC7181]. 452 Only a single Type Extension was specified by [RFC7181] (link metric 453 type) 0 as defined by administrative action. This specification 454 extends this range, it is suggested either to 0-7 or to 0-15. This 455 specification will work with any combination of Type Extensions both 456 within and without that range (assuming that the latter are defined 457 as specified in [RFC7181]). 459 7.2.2. MPR TLV 461 The MPR TLV is used in HELLO messages, and indicates that an address 462 with which it is associated is of a symmetric 1-hop neighbor that has 463 been selected as an MPR. 465 The Value field of this address block TLV is, in [RFC7181], defined 466 to be one octet long, with the values 1, 2 and 3 defined. [RFC7188] 467 redefines this Value field to be a bitfield where bit 7 (the lsb) 468 denotes flooding status, bit 6 denotes routing MPR status, and bits 469 5-0 are unallocated (respecting the semantics of the bits/values 1, 2 470 and 3 from [RFC7181]). 472 This specification, as enabled by [RFC7188], extends the MPR TLV to 473 have a variable-length Value field. For interoperability with a 474 router not implementing MT-OLSRv2, the two least significant bits of 475 the first octet in the Value field of this TLV MUST be the TLV Value 476 of the MPR TLV, generated according to [RFC7181]. 478 Subsequent bits (in increasing significance within an octet, then 479 continuing with the least significant bit in the next octet, if 480 required) in the TLV Value field indicate which link metric types, 481 for which the corresponding address is selected as a routing MPR, 482 link metric types (including the first) being indicated in the Value 483 field of an MPR_TYPES Message TLV. 485 7.2.3. GATEWAY TLV 487 The GATEWAY TLV is used in TC messages to indicate that a network 488 address is of an attached network. 490 The Value field of this address block TLV is, in [RFC7181] defined to 491 be one octet long, containing the number of hops to that attached 492 network. 494 This specification, as enabled by [RFC7181], allows the extension the 495 GATEWAY TLV to have a variable-length Value field when the number of 496 hops to each attached network is different for different link metric 497 types. For interoperability with a router not implementing MT- 498 OLSRv2, the first octet in the Value field of this TLV MUST be the 499 TLV Value of the GATEWAY TLV generated according to [RFC7181]. 501 Any subsequent octets in the TLV Value field indicate the number of 502 hops to the attached network for each other link metric type, link 503 metric types (including the first) being indicated in the Value field 504 of an MPR_TYPES Message TLV. 506 +---------+---------------------------------------------------------+ 507 | Type | Value | 508 +---------+---------------------------------------------------------+ 509 | GATEWAY | Number of hops to attached network for each link metric | 510 | | type. | 511 +---------+---------------------------------------------------------+ 513 Table 1: GATEWAY TLV definition 515 8. HELLO Messages 517 The following changes are made to the generation and processing of 518 HELLO messages compared to that described in [RFC7181] by routers 519 that implement MT-OLSRv2. 521 8.1. HELLO Message Generation 523 A generated HELLO message to be sent on an OLSRv2 interface is 524 extended by: 526 o Adding an MPR_TYPES TLV. The value octets will be the link metric 527 types in IFACE_METRIC_TYPES. 529 o Extending the MPR_WILLING TLV Value field to report the 530 willingness values from the WILL_ROUTING parameter list that 531 correspond to the link metric types in IFACE_METRIC_LIST, in the 532 same order as reported in the MPR_TYPES TLV, each value (also 533 including one representing WILL_FLOODING) occupying 4 bits. 535 o Including LINK_METRIC TLVs that report all values of L_in_metric, 536 L_out_metric, N_in_metric and N_out_metric that are not equal to 537 UNKNOWN_METRIC, with the TLV Type Extension being the link metric 538 type, and otherwise following the rules for such inclusions 539 specified in [OLSRv2]. 541 o Including MPR TLVs such that for each link metric type in 542 IFACE_METRIC_TYPES, and for the choice of flooding MPRs, these 543 MUST be an MPR set as specified for a single link metric type in 544 [RFC7181]. 546 8.2. HELLO Message Processing 548 On receipt of a HELLO message, a router implementing MT-OLSRv2 MUST, 549 in addition to the processing described in [RFC7181]: 551 1. Determine the list of link metric types supported by the sending 552 router on the relevant OLSRv2 interface, either from an MPR_TYPES 553 TLV or, if not present, the type LINK_METRIC_TYPE supported by a 554 router not implementing the extension described in this 555 specification. 557 2. For those link metric types supported by both routers, set the 558 appropriate L_out_metric, N_in_metric, N_out_metric, 559 N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and 560 N2_out_metric values as described for the single such elements in 561 [RFC7181]. 563 3. For any other metric types supported by the receiving router 564 only, set those elements to their default value: UNKNOWN_METRIC, 565 WILL_NEVER (not WILL_DEFAULT), or false. 567 9. TC Messages 569 The following changes are made to the generation and processing of TC 570 messages compared to that described in [RFC7181] by routers that 571 implement MT-OLSRv2. 573 9.1. TC Message Generation 575 A generated TC message is extended by: 577 o If any GATEWAY TLVs are included requiring more than one number of 578 hops value, then adding an MPR_TYPES TLV with Value octets being 579 the link metric types in ROUTER_METRIC_TYPES. 581 o Including LINK_METRIC TLVs that report all values of N_out_metric 582 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 583 being the link metric type, and otherwise following the rules for 584 such inclusions specified in [RFC7181]. 586 o When not all the same, including a number of hops per reported (in 587 an MPR_TYPES Message TLV) link metric type in the Value field of 588 each GATEWAY TLV included. 590 9.2. TC Message Processing 592 On receipt of a TC message, a router implementing this extension 593 MUST, in addition to the processing specified in [RFC7181]: 595 o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric 596 elements using the rules for setting the single elements of those 597 types specified in [RFC7181]. 599 o For any other metric types supported by the receiving router that 600 do not have an advertised outgoing neighbor metric of that type, 601 set the corresponding elements of TR_metric, TA_metric and 602 AN_metric to UNKNOWN_METRIC. (The corresponding element of 603 AN_dist may be set to any value.) 605 10. MPR Calculation 607 Routing MPRs are calculated for each link metric type in 608 ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 609 interfaces that do not support that link metric type are not 610 considered. The determined status (routing MPR or not routing MPR) 611 for each link metric type is recorded in the relevant element of 612 N_routing_mpr. 614 Each router may make its own decision as to whether or not to use a 615 link metric, or link metrics, for flooding MPR calculation, and if so 616 which and how. This decision MUST be made in a manner that ensures 617 that flooded messages will reach the same symmetric 2-hop neighbors 618 as would be the case for a router not supporting MT-OLSRv2. 620 Note that it is possible that a 2-Hop Tuple in the Information Base 621 for a given OLSRv2 interface does not support any of the link metric 622 types that are in the router's corresponding IFACE_METRIC_TYPES, but 623 nevertheless that 2-Hop Tuple MUST be considered when determining 624 flooding MPRs. 626 11. Routing Set Calculation 628 A Routing Set is calculated for each link metric type in 629 ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except 630 that where an element is now represented by a map, the value from the 631 map for the selected link metric type is used. Where this is a link 632 metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for 633 the calculation. 635 12. Management Considerations 637 MT-OLSRv2 may require greater management than unextended OLSRv2. In 638 particular MT-OLSRv2 requires the following management 639 considerations: 641 o Selecting which link metrics to support on each OLSRv2 interface 642 and implementing that decision. (Different interfaces may have 643 different physical and data link layer properties, and this may 644 inform the selection of link metrics to support, and their 645 values.) 647 o Ensuring that the MANET is sufficiently connected. Note that if 648 there is any possibility that there are any routers not 649 implementing MT-OLSRv2, then the MANET will be connected, to the 650 maximum extent possible, using the link metric type 651 LINK_METRIC_TYPE. 653 o Deciding which link metric, and hence which Routing Set to use, 654 for received packets, hence how to use the Routing Sets to 655 configure the network layer (IP). An obvious approach is to map 656 each DiffServ Code Point (DSCP) [RFC2474] to a single link metric. 657 (This may be a many to one mapping.) 659 o Note that there could be cases where a router that is not 660 implementing MT-OLSRv2 is the source or destination of an IP 661 packet that is mapped to a link metric that is not the link metric 662 LINK_METRIC_TYPE used by that router. 664 o If such a router is the source, then routing may work if the first 665 router implementing MT-OLSRv2 to receive the packet supports the 666 appropriate link metric type. At worst the packet will be 667 dropped, it will not loop. 669 o If such a router is the destination, then the packet will never 670 reach its destination, as the source will not have a suitable 671 routing table entry for the destination. Network management may 672 be required to ensure that the MANET still functions in these 673 cases. 675 13. IANA Considerations 677 This specification adds one new Message TLV, allocated as a new Type 678 Extension to an existing Message TLV, using a new name. It also 679 modifies the Value field of an existing Message TLV, and of an 680 existing Address Block TLV. Finally, this specification makes 681 additional allocations from the LINK_METRIC Address Block TLV Type 682 registry. 684 13.1. Expert Review: Evaluation Guidelines 686 For the registry where an Expert Review is required, the designated 687 expert SHOULD take the same general recommendations into 688 consideration as are specified by [RFC5444]. 690 13.2. Message TLV Types 692 This specification replaces Table 11 of [RFC7181]. That specified a 693 Message MPR Type described as MPR_WILLING, for which only Type 694 Extension 0 was defined. This specification reserves that name 695 MPR_WILLING for Type Extension 0, defines a new Type Extension 1, 696 with a new name MPR_TYPES, and leaves the remaining Type Extensions 697 of this TLV Type unnamed. It also changes the Value field 698 specification of the MPR_WILLING TLV. 700 Specifications of these TLVs are in Table 2. Each of these TLVs MUST 701 NOT be included more than once in a Message TLV Block. 703 +-------------+------+-----------+---------------------+------------+ 704 | Name | Type | Type | Description | Allocation | 705 | | | Extension | | Policy | 706 +-------------+------+-----------+---------------------+------------+ 707 | MPR_WILLING | 7 | 0 | Bits 0-3 specify | | 708 | | | | the originating | | 709 | | | | router's | | 710 | | | | willingness to act | | 711 | | | | as a flooding MPR. | | 712 | | | | Each following 4 | | 713 | | | | bit subfield (using | | 714 | | | | bits 0-3 of an | | 715 | | | | octet before bits | | 716 | | | | 4-7) specifies the | | 717 | | | | originating | | 718 | | | | router's | | 719 | | | | willingness to act | | 720 | | | | as a routing MPR | | 721 | | | | for a link metric, | | 722 | | | | either a single | | 723 | | | | such field (bits | | 724 | | | | 4-7) when no | | 725 | | | | MPR_TYPES Message | | 726 | | | | TLV is present, or | | 727 | | | | one subfield per | | 728 | | | | type reported in an | | 729 | | | | MPR_TYPES Message | | 730 | | | | TLV Value field (in | | 731 | | | | the same order). | | 732 | MPR_TYPES | 7 | 1 | The link metric | | 733 | | | | types supported on | | 734 | | | | this OLSRv2 | | 735 | | | | interface of this | | 736 | | | | router (one octet | | 737 | | | | each). | | 738 | Unnamed | 7 | 2-255 | Unassigned. | Expert | 739 | | | | | Review | 740 +-------------+------+-----------+---------------------+------------+ 742 Table 2: Message TLV Type assignment: MPR_WILLING and MPR_TYPES 744 13.3. Address Block TLV Types 746 Table 16 of [RFC7181] is replaced by Table 3. Note that the only 747 change is to the description of the Value field. 749 +---------+------+-----------+-------------------------+------------+ 750 | Name | Type | Type | Description | Allocation | 751 | | | extension | | Policy | 752 +---------+------+-----------+-------------------------+------------+ 753 | GATEWAY | 10 | 0 | Specifies that a given | | 754 | | | | network address is | | 755 | | | | reached via a gateway | | 756 | | | | on the originating | | 757 | | | | router. The number of | | 758 | | | | hops is indicated by | | 759 | | | | the Value field, either | | 760 | | | | using a single octet | | 761 | | | | (if no MPR_TYPES | | 762 | | | | Message TLV is present) | | 763 | | | | or one octet per type | | 764 | | | | reported in an | | 765 | | | | MPR_TYPES Message TLV | | 766 | | | | (in the same order). | | 767 | GATEWAY | 10 | 1-255 | | Expert | 768 | | | | | Review | 769 +---------+------+-----------+-------------------------+------------+ 771 Table 3: Address Block TLV Type assignment: GATEWAY 773 Table 13 of [RFC7181] is replaced by Table 4. Note that the only 774 change is to allocate 8 Type Extensions as assigned by administrative 775 action, in order to support administratively determined multi- 776 topologies. 778 +-------------+------+-----------+-------------------+--------------+ 779 | Name | Type | Type | Description | Allocation | 780 | | | Extension | | Policy | 781 +-------------+------+-----------+-------------------+--------------+ 782 | LINK_METRIC | 7 | 0-7 | Link metric | | 783 | | | | meaning assigned | | 784 | | | | by administrative | | 785 | | | | action. | | 786 | LINK_METRIC | 7 | 8-223 | Unassigned. | Expert | 787 | | | | | Review | 788 | LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental | 789 | | | | | Use | 790 +-------------+------+-----------+-------------------+--------------+ 792 Table 4: Address Block TLV Type assignment: LINK_METRIC 794 14. Security Considerations 796 This extension to OLSRv2 allows a router to support more than one 797 link metric type for each link advertised in HELLO and TC messages, 798 and for routers to support different sets of types. Link metric 799 values of additional types are reported by the inclusion of 800 additional TLVs in the messages sent by a router, which will report 801 known values of all supported types. 803 HELLO and TC message processing is then extended simply to record, 804 for each supported type, all of the received link metric values for 805 each link. Protocol internal processing (specifically MPR set and 806 shortest path calculations) then operate as specified in [RFC7181] 807 for each link metric type that the router supports. 809 Consequently the security considerations, including the security 810 architecture and the mandatory security mechanisms, from [RFC7181] 811 are directly applicable to MT-OLSRv2. 813 Furthermore, this extension does not introduce any additional 814 vulnerabilities over those of [RFC7181], because each link metric 815 type is used independently, and each one could have been the single 816 link metric type supported by an implementation of [RFC7181] 817 receiving the same information, as received information of an 818 unsupported type is ignored by all routers. 820 15. Acknowledgments 822 TBD. 824 16. References 826 16.1. Normative References 828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 829 Requirement Levels", BCP 14, RFC 2119, March 1997. 831 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 832 "Generalized MANET Packet/Message Format", RFC 5444, 833 February 2009. 835 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 836 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 837 RFC 6130, April 2011. 839 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 840 "The Optimized Link State Routing Protocol version 2", 841 RFC 7181, April 2014. 843 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 844 Protocol version 2 (OLSRv2) and MANET Neighborhood 845 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 846 April 2014. 848 16.2. Informative References 850 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 851 "Definition of the Differentiated Services Field (DS 852 Field) in the IPv4 and IPv6 Headers", RFC 2474, 853 December 1998. 855 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 856 (MANET): Routing Protocol Performance Issues and 857 Evaluation Considerations", RFC 2501, January 1999. 859 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 860 Routing Protocol", RFC 3626, October 2003. 862 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 863 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 864 RFC 4915, June 2007. 866 Authors' Addresses 868 Christopher Dearlove 869 BAE Systems Advanced Technology Centre 870 West Hanningfield Road 871 Great Baddow, Chelmsford 872 United Kingdom 874 Phone: +44 1245 242194 875 Email: chris.dearlove@baesystems.com 876 URI: http://www.baesystems.com/ 878 Thomas Heide Clausen 879 LIX, Ecole Polytechnique 881 Phone: +33 6 6058 9349 882 Email: T.Clausen@computer.org 883 URI: http://www.ThomasClausen.org/