idnits 2.17.1 draft-ietf-manet-olsrv2-multitopology-07.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 (September 28, 2015) is 3132 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Applied Intelligence 4 Updates: 7188, 7631 Laboratories 5 (if approved) T. Clausen 6 Intended status: Experimental LIX, Ecole Polytechnique 7 Expires: March 31, 2016 September 28, 2015 9 Multi-Topology Extension for the Optimized Link State Routing Protocol 10 version 2 (OLSRv2) 11 draft-ietf-manet-olsrv2-multitopology-07 13 Abstract 15 This specification describes an extension to the Optimized Link State 16 Routing Protocol version 2 (OLSRv2) to support multiple routing 17 topologies, while retaining interoperability with OLSRv2 routers that 18 do not implement this extension. 20 This specification updates RFCs 7188 and 7631 by modifying and 21 extending TLV registries and descriptions. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 31, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Motivation and Experimentation . . . . . . . . . . . . . . 4 59 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 60 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 61 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 62 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 9 64 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 9 65 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 10 69 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 10 70 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 10 71 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 11 75 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 11 76 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 12 77 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 12 78 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 13 80 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 81 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 14 82 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 14 83 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 15 85 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 16 86 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 16 87 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 16 88 12. Management Considerations . . . . . . . . . . . . . . . . . . 17 89 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18 91 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 18 92 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 19 93 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 94 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 16.1. Normative References . . . . . . . . . . . . . . . . . . . 22 97 16.2. Informative References . . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 The Optimized Link State Routing Protocol, version 2 [RFC7181] 103 (OLSRv2) is a proactive link state routing protocol designed for use 104 in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant 105 improvements of OLSRv2 over its Experimental precursor [RFC3626] is 106 the ability of OLSRv2 to route over other than minimum hop routes, 107 using a link metric. 109 A limitation that remains in OLSRv2 is that it uses a single link 110 metric type for all routes. However in some MANETs it would be 111 desirable to be able to route packets using more than one link metric 112 type. This specification describes an extension to OLSRv2 that is 113 designed to permit this, while maintaining maximal interoperability 114 with OLSRv2 routers not implementing this extension. 116 The purpose of OLSRv2 can be described as to create and maintain a 117 Routing Set, which contains all the necessary information to populate 118 an IP routing table. In a similar way, the role of this extension 119 can be described as to create and maintain multiple Routing Sets, one 120 for each link metric type supported by the router maintaining the 121 sets. 123 1.1. Motivation and Experimentation 125 Multi-topology routing is a natural extension to a link state routing 126 protocol, as for example to OSPF (see [RFC4915]). However multi- 127 topology routing for OLSRv2 does not yet benefit from extensive 128 operational, or even experimental, experience. This specification is 129 published to facilitate collecting such experience, with the intent 130 that once suitable experimental evidence has been collected, an 131 OLSRv2 Multi-Topology Routing Extension will be proposed for 132 advancement onto Standards Track. 134 Any experiments using this protocol extension are encouraged. 135 Reports from such experiments planned with pre-specified objectives 136 and scenarios (including link, position and mobility information) are 137 particularly encouraged. Results from such experiments, documenting 138 the following, are of particular importance: 140 o Operation in networks that contain both routers implementing this 141 extension, and routers implementing only [RFC7181], in particular 142 are there any unexpected interactions that can break the network? 144 o Operation in networks with dynamic topologies, both due to 145 mobility and due to link metric changes for reasons other than 146 mobility. 148 o Operation in realistic deployments, and details thereof, including 149 in particular indicating how many concurrent topologies were 150 required. 152 o Behavior of routing sets, including measures of successful route 153 establishment. 155 In addition, reports from experiments covering the following are also 156 of value: 158 o Which link metric types were useful, and how the metrics to 159 associate with a given link were established. 161 o How packet types were associated with link metric types (whether 162 using DiffServ on an alternative mechanism). 164 o Any data link layer issues, and any cross-layer issues, including 165 whether NHDP link quality was used, and how. 167 o Transport and higher layer issues observed, if any. 169 o Resource requirements observed from running the protocol, 170 including processing, storage, and bandwidth. 172 o Network performance, including packet delivery results. 174 o Any other implementation issues. 176 The first bullet in the latter list applies to unextended [RFC7181] 177 as well as this extension, and potentially to other MANET routing 178 protocols. This may also allow experimentation with link metric 179 types that are not compromises to handle multiple traffic types. 181 2. Terminology and Notation 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in 186 [RFC2119]. 188 This specification uses the terminology of [RFC5444], [RFC6130] and 189 [RFC7181], which is to be interpreted as described in those 190 specifications. 192 Additionally, this specification uses the following terminology: 194 Router - A MANET router that implements [RFC7181]. 196 MT-OLSRv2 - The protocol defined in this specification as an 197 extension to [RFC7181]. 199 This specification introduces the notation map[A -> B] to represent 200 an associative mapping. The domain of this mapping (A) is, in this 201 specification, always a set of link metric types that the router 202 supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as 203 defined in Section 5. The codomain of this mapping (B) is a set of 204 all possible values of an appropriate type, in this specification 205 this type is always one of: 207 o boolean (true or false), 209 o willingness (a 4 bit unsigned integer from 0 to 15); 211 o number of hops (an 8 bit unsigned integer from 0 to 255), or 213 o link metric (either a representable link metric value, as 214 described in [RFC7181], or UNKNOWN_METRIC). 216 3. Applicability Statement 218 The protocol described in this specification is applicable to a MANET 219 for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), 220 but in which multiple topologies are maintained, each characterized 221 by a different choice of link metric type. It is assumed, but 222 outside the scope of this specification, that the network layer is 223 able to choose which topology to use for each packet, for example 224 using the DiffServ Code Point (DSCP) defined in [RFC2474]. This 225 selection of topology MUST be consistent, that is each router 226 receiving a packet must make the same choice of link metric type, in 227 order that each packet uses a single topology. This is necessary to 228 avoid the possibility of a packet "looping" in the network. 230 4. Protocol Overview and Functioning 232 The purpose of this specification is to extend OLSRv2 [RFC7181] so as 233 to enable a router to establish and maintain multiple routing 234 topologies in a MANET, each topology associated with a link metric 235 type. Routers in the MANET may each form part of some or all of 236 these topologies, and each router will maintain a Routing Set for 237 each topology that it forms part of, allowing separate routing of 238 packets for each topology. 240 MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be 241 created containing both routers that implement MT-OLSRv2 (MT-OLSRv2 242 routers) and routers that do not implement MT-OLSRv2, and may be 243 unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be 244 created that are known to contain only MT-OLSRv2 routers. In both 245 cases, but especially the former, management may be required to 246 ensure that the MANET will function as required, and does not, for 247 example, unnecessarily fragment. (Such issues already arise in an 248 OLSRv2-based MANET using multiple interfaces.) 250 OLSRv2 is an extension of NHDP [RFC6130]. However the extension in 251 this specification does not modify NHDP, it only modifies Protocol 252 Sets that are specific to OLSRv2, or elements in Protocol Tuples that 253 were added by OLSRv2 and which are not included in nor used by NHDP. 254 In addition it does not use or modify the link quality mechanism in 255 [RFC6130]. 257 Each router implementing this specification selects a set of link 258 metric types for each of its OLSRv2 interfaces. If all routers in 259 the MANET implement MT-OLSRv2, then there are no restrictions within 260 this specification on how these sets of link metrics are selected. 261 (However the issues described in the preceding paragraph still 262 apply.) However in MANETs containing non-MT-OLSRv2 routers, the 263 single link metric used by these non-MT-OLSRv2 routers must be 264 included in the set of link metrics for each OLSRv2 interface of an 265 MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non- 266 MT-OLSRv2 router in the MANET. 268 Each router then determines an incoming link metric for each link 269 metric type selected for each of its OLSRv2 interfaces. These link 270 metrics are distributed using link metric TLVs contained in all HELLO 271 messages sent on OLSRv2 interfaces, and in all TC messages. Both 272 HELLO and TC messages generated by an MT-OLSRv2 router (other than 273 one using only the single metric type used by non-MT-OLSRv2 routers) 274 include an MPR_TYPES Message TLV that indicates that this is an MT- 275 OLSRv2 router and which metric types it supports (on the sending 276 OLSRv2 interface for a HELLO message). 278 In addition to link and neighbor metric values for each link metric 279 type, router MPR (multipoint relay) and MPR selector status, and 280 advertised neighbor status, is maintained per supported neighbor 281 metric type, for each symmetric 1-hop neighbor. Each router may 282 choose a different willingness to be a routing MPR for each link 283 metric type that it supports. 285 A network using MT-OLSRv2 will usually require greater management 286 than one using unmodified OLSRv2. In particular, the use of multiple 287 metric types across the MANET must be managed, by administrative 288 configuration or otherwise. As also for other decisions that may be 289 made when using OLSRv2, a bad collective choice of metric type use 290 will make the MANET anywhere from inefficient to non-functional, so 291 care will be needed in selecting supported link metric types across 292 the MANET. 294 The meanings of link metric types are at the discretion of the MANET 295 operator, they could be used, for example, to represent packets of 296 different types, packets in streams of different rates, or packets 297 with different trust requirements. Note that packets will generally 298 not be delivered to routers that do not support that link metric 299 type, and the MANET, and the packets sent in it, will need to be 300 managed accordingly (especially if containing any non-MT-OLSRv2 301 routers). 303 5. Parameters 305 The parameters used in [RFC7181], including from its normative 306 references, are used in this specification with the following 307 changes. 309 Each OLSRv2 interface will support a number of link metric types, 310 corresponding to Type Extensions of the LINK_METRIC TLV defined in 311 [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers 312 that do not implement MT-OLSRv2, and used with that definition in 313 this specification, is replaced in routers implementing MT-OLSRv2 by 314 an interface parameter array IFACE_METRIC_TYPES and a router 315 parameter array ROUTER_METRIC_TYPES. Each element in these arrays is 316 a link metric type (i.e., a type extension used by the LINK_METRIC 317 TLV [RFC7181]). 319 The interface parameter array IFACE_METRIC_TYPES contains the link 320 metric types supported on that OLSRv2 interface. The router 321 parameter array ROUTER_METRIC_TYPES is the union of all of the 322 IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. 324 If in a given deployment there may be any routers that do not 325 implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST first include 326 LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate 327 with any routers that do not implement MT-OLSRv2. In that case, 328 ROUTER_METRIC_TYPES MUST also first include LINK_METRIC_TYPE. 330 In addition, the router parameter WILL_ROUTING is extended to an 331 array of values, one each for each link metric type in the router 332 parameter list ROUTER_METRIC_TYPES. 334 6. Information Bases 336 The Information Bases specified in [RFC7181], which extend those 337 specified in in [RFC6130], are further extended in this 338 specification. With the exception of the Routing Set, the extensions 339 in this specification are the replacement of single values (boolean, 340 willingness, number of hops, or link metric) from [RFC7181] with 341 elements representing multiple values (associative mappings from a 342 set of metric types to their corresponding values). The following 343 subsections detail these extensions. 345 Note that, as in [RFC7181], an implementation is free to organize its 346 internal data in any manner it chooses, it needs only to behave as if 347 it were organized as described in [RFC7181] and this specification. 349 6.1. Local Attached Network Set 351 Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of 352 hops]. 354 Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link 355 metric]. 357 6.2. Link Sets 359 Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link 360 metric]. 362 Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link 363 metric]. 365 The elements of L_in_metric MUST be set following the same rules that 366 apply to the setting of the single element L_in_metric in [RFC7181]. 368 6.3. 2-Hop Sets 370 Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 371 metric]. 373 Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 374 metric]. 376 6.4. Neighbor Set 378 Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 379 metric]. 381 Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 382 metric]. 384 Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> 385 willingness]. 387 Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> 388 boolean]. 390 Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> 391 boolean]. 393 Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> 394 boolean]. 396 6.5. Router Topology Set 398 Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link 399 metric]. 401 Note that some values of TR_metric may now take the value 402 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 403 corresponding link metric value from this mapping is used, Router 404 Topology Tuples whose corresponding value from TR_metric is 405 UNKNOWN_METRIC are ignored. 407 6.6. Routable Address Topology Set 409 Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link 410 metric]. 412 Note that some values of TA_metric may now take the value 413 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 414 corresponding link metric value from this mapping is used, Routable 415 Address Topology Tuples whose corresponding value from TA_metric is 416 UNKNOWN_METRIC are ignored. 418 6.7. Attached Network Set 420 Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of 421 hops]. 423 Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link 424 metric]. 426 Note that some values of AN_metric may now take the value 427 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 428 corresponding link metric value from this mapping is used, Attached 429 Network Tuples whose corresponding value from AN_metric is 430 UNKNOWN_METRIC are ignored. 432 6.8. Routing Sets 434 There is a separate Routing Set for each link metric type in 435 ROUTER_METRIC_TYPES. 437 7. TLVs 439 This specification makes the following additions and extensions to 440 the TLVs defined in [RFC7181]. 442 7.1. Message TLVs 444 One new Message TLV is defined in this specification, and one 445 existing Message TLV is extended by this specification. 447 7.1.1. MPR_TYPES TLV 449 The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 450 interfaces and TC messages. A message MUST NOT contain more than one 451 MPR_TYPES TLV. 453 The presence of this TLV in a message is used to indicate that the 454 router supports MT-OLSRv2, in the same way that the presence of the 455 MPR_WILLING TLV is used to indicate that the router supports OLSRv2, 456 as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has 457 been defined with the same Type as the MPR_WILLING TLV, but with Type 458 Extension = 1. 460 This TLV may take a Value field of any size. Each octet in its Value 461 field will contain a link metric type that is supported, either on 462 any OLSRv2 interface, when included in a TC message, or on the OLSRv2 463 interface on which an including HELLO message is sent. These octets 464 MAY be in any order, except that if there may be any routers in the 465 MANET not implementing MT-OLSRv2, then the first octet MUST be 466 LINK_METRIC_TYPE. 468 7.1.2. MPR_WILLING TLV 470 The MPR_WILLING TLV, which is used in HELLO messages, is specified in 471 [RFC7181], and extended in this specification as enabled by 472 [RFC7188]. 474 The interpretation of this TLV, specified by [RFC7181], and which 475 uses all of its single octet Value field, is unchanged. That 476 interpretation uses bits 0-3 of its Value field to specify its 477 willingness to be a flooding TLV, and bits 4-7 of its Value field to 478 be a routing TLV. Those latter bits are, when using this 479 specification, interpreted as its willingness to be a routing TLV 480 using the link metric type LINK_METRIC_TYPE. 482 The extended use of this message TLV, as defined by this 483 specification, defines additional 4 bit sub-fields of the Value 484 field, starting with bits 4-7 of the first octet and continuing with 485 bits 0-3 of the second octet, to represent willingness to be a 486 routing MPR using the link metric types specified in this OLSRv2 487 interface's IFACE_METRIC_TYPES parameter, ordered as reported in the 488 included MPR_TYPES Message TLV. Note that this means that the link 489 metric type LINK_METRIC_TYPE will continue to occupy bits 4-7 of the 490 first octet. (If there is no such TLV included, then the router does 491 not support MT-OLSRv2, and only the first octet of the Value field 492 will be used.) 494 If the number of link metric types in this OLSRv2 interface's 495 IFACE_METRIC_TYPES parameter is even, then there will be an unused 4 496 bit sub-field in bits 4-7 of the last octet of a full sized Value 497 field. These bits will not be used, they SHOULD all be cleared 498 ('0'). 500 If the Value field in an MPR_WILLING TLV is shorter than its full 501 length, then, as specified in [RFC7188], missing Value octets, i.e., 502 missing willingness values, are considered as zero, i.e., as 503 WILL_NEVER. This is the correct behavior. (In particular it means 504 that an OLSRv2 router that is not implementing MT-OLSRv2 will not act 505 as a routing MPR for any link metric that it does not recognize.) 507 7.2. Address Block TLVs 509 New Type Extensions are defined for the LINK_METRIC TLV defined in 510 [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, 511 both defined in [RFC7181], are extended, as enabled by [RFC7188]. 513 7.2.1. LINK_METRIC TLV 515 The LINK_METRIC TLV is used in HELLO messages and TC messages. This 516 TLV is unchanged from the definition in [RFC7181]. 518 Only a single Type Extension was specified by [RFC7181] (link metric 519 type) 0 as defined by administrative action. This specification 520 extends this range to 0-7. This specification will work with any 521 combination of Type Extensions both within and without that range 522 (assuming that the latter are defined as specified in [RFC7181]). 524 7.2.2. MPR TLV 526 The MPR TLV is used in HELLO messages, and indicates that an address 527 with which it is associated is of a symmetric 1-hop neighbor that has 528 been selected as an MPR. 530 The Value field of this address block TLV is, in [RFC7181], defined 531 to be one octet long, with the values 1, 2 and 3 defined. [RFC7188] 532 redefines this Value field to be a bitfield where bit 7 (the lsb) 533 denotes flooding status, bit 6 denotes routing MPR status, and bits 534 5-0 are unallocated (respecting the semantics of the bits/values 1, 2 535 and 3 from [RFC7181]). 537 This specification, as enabled by [RFC7188], extends the MPR TLV to 538 have a variable-length Value field. For interoperability with a 539 router not implementing MT-OLSRv2, the two least significant bits of 540 the first octet in the Value field of this TLV MUST be the TLV Value 541 of the MPR TLV, generated according to [RFC7181]. 543 Subsequent bits (in increasing significance within an octet, then 544 continuing with the least significant bit in the next octet, if 545 required) in the TLV Value field indicate which link metric types, 546 for which the corresponding address is selected as a routing MPR, 547 link metric types (including the first) being indicated in, and used 548 in the same order as, the Value field of an MPR_TYPES Message TLV, 549 excluding the link metric type LINK_METRIC_TYPE, which already 550 occupies the second bit. 552 7.2.3. GATEWAY TLV 554 The GATEWAY TLV is used in TC messages to indicate that a network 555 address is of an attached network. 557 The Value field of this address block TLV is, in [RFC7181] defined to 558 be one octet long, containing the number of hops to that attached 559 network. 561 This specification, as enabled by [RFC7181], allows the extension the 562 GATEWAY TLV to have a variable-length Value field when the number of 563 hops to each attached network is different for different link metric 564 types. For interoperability with a router not implementing MT- 565 OLSRv2, the first octet in the Value field of this TLV MUST be the 566 TLV Value of the GATEWAY TLV generated according to [RFC7181]. 568 Any subsequent octets in the TLV Value field indicate the number of 569 hops to the attached network for each other link metric type, link 570 metric types (including the first) being indicated in the Value field 571 of an MPR_TYPES Message TLV. 573 +---------+---------------------------------------------------------+ 574 | Type | Value | 575 +---------+---------------------------------------------------------+ 576 | GATEWAY | Number of hops to attached network for each link metric | 577 | | type. | 578 +---------+---------------------------------------------------------+ 580 Table 1: GATEWAY TLV definition 582 8. HELLO Messages 584 The following changes are made to the generation and processing of 585 HELLO messages compared to that described in [RFC7181] by routers 586 that implement MT-OLSRv2. 588 8.1. HELLO Message Generation 590 A generated HELLO message to be sent on an OLSRv2 interface (whose 591 IFACE_METRIC_TYPES parameter will be that used) is extended by: 593 o Adding an MPR_TYPES Message TLV. The Value octets will be the 594 link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted 595 if the only link metric type included would be LINK_METRIC_TYPE. 597 o Extending the MPR_WILLING Message TLV Value field to report the 598 willingness values from the WILL_ROUTING parameter list that 599 correspond to the link metric types in IFACE_METRIC_LIST, in the 600 same order as reported in the MPR_TYPES TLV, each value (also 601 including one representing WILL_FLOODING) occupying 4 bits. 603 o Including LINK_METRIC Address Block TLVs that report all values in 604 L_in_metric, L_out_metric, N_in_metric and N_out_metric elements 605 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 606 being the link metric type, and otherwise following the rules for 607 such inclusions specified in [RFC7181]. 609 o Including MPR Address Block TLVs such that for each link metric 610 type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, 611 the indicated addresses MUST be of the MPRs in an MPR set as 612 specified for a single link metric type in [RFC7181]. 614 8.2. HELLO Message Processing 616 On receipt of a HELLO message on an OLSRv2 interface, a router 617 implementing MT-OLSRv2 MUST, in addition to the processing described 618 in [RFC7181]: 620 1. If in this deployment there may be any routers that do not 621 implement MT-OLSRv2, the HELLO message contains an MPR_TYPES 622 Message TLV, and the first link metric type that it reports is 623 not LINK_METRIC_TYPE, then the HELLO message MUST be silently 624 discarded. 626 2. Determine the list of link metric types supported by the sending 627 router on its corresponding OLSRv2 interface, either from an 628 MPR_TYPES Message TLV or, if not present, the single link metric 629 type LINK_METRIC_TYPE. 631 3. For those link metric types supported by both routers, set the 632 appropriate L_out_metric, N_in_metric, N_out_metric, 633 N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and 634 N2_out_metric values as described for single such elements in 635 [RFC7181]. 637 4. For any other metric types supported by the receiving router only 638 (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set 639 the elements listed in the previous point to their default 640 values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or 641 false. 643 9. TC Messages 645 The following changes are made to the generation and processing of TC 646 messages compared to that described in [RFC7181] by routers that 647 implement MT-OLSRv2. 649 9.1. TC Message Generation 651 A generated TC message is extended by: 653 o Adding an MPR_TYPES TLV. The value octets will be the link metric 654 types in ROUTER_METRIC_TYPES. This MAY be omitted if the only 655 link metric type included would be LINK_METRIC_TYPE. 657 o Including LINK_METRIC TLVs that report all values of N_out_metric 658 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 659 being the link metric type, and otherwise following the rules for 660 such inclusions specified in [RFC7181]. 662 o When not all the same, including a number of hops per reported (in 663 an MPR_TYPES Message TLV) link metric type in the Value field of 664 each GATEWAY TLV included, in the same order as reported in the 665 MPR_TYPES TLV. 667 9.2. TC Message Processing 669 On receipt of a TC message, a router implementing this extension 670 MUST, in addition to the processing specified in [RFC7181]: 672 o If in this deployment there may be any routers that do not 673 implement MT-OLSRv2, the TC message contains an MPR_TYPES Message 674 TLV, and the first link metric type that it reports is not 675 LINK_METRIC_TYPE, then the TC message MUST be silently discarded. 677 o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric 678 elements using the rules for setting the single elements of those 679 types specified in [RFC7181]. 681 o For any other metric types supported by the receiving router that 682 do not have an advertised outgoing neighbor metric of that type, 683 set the corresponding elements of TR_metric, TA_metric and 684 AN_metric to UNKNOWN_METRIC. (The corresponding element of 685 AN_dist may be set to any value.) 687 10. MPR Calculation 689 Routing MPRs are calculated for each link metric type in 690 ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 691 interfaces that do not support that link metric type are not 692 considered. The determined status (routing MPR or not routing MPR) 693 for each link metric type is recorded in the relevant element of 694 N_routing_mpr. 696 Each router may make its own decision as to whether or not to use a 697 link metric, or link metrics, for flooding MPR calculation, and if so 698 which and how. This decision MUST be made in a manner that ensures 699 that flooded messages will reach the same symmetric 2-hop neighbors 700 as would be the case for a router not supporting MT-OLSRv2. 702 Note that it is possible that a 2-Hop Tuple in the Information Base 703 for a given OLSRv2 interface does not support any of the link metric 704 types that are in the router's corresponding IFACE_METRIC_TYPES, but 705 nevertheless that 2-Hop Tuple MUST be considered when determining 706 flooding MPRs. 708 11. Routing Set Calculation 710 A Routing Set is calculated for each link metric type in 711 ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except 712 that where an element is now represented by a map, the value from the 713 map for the selected link metric type is used. Where this is a link 714 metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for 715 the calculation. 717 12. Management Considerations 719 MT-OLSRv2 may require greater management than unextended OLSRv2. In 720 particular a MANET using MT-OLSRv2 requires the following management 721 considerations: 723 o Deciding which link metric, and hence which Routing Set to use, 724 for received packets, hence how to use the Routing Sets to 725 configure the network layer (IP). All routers MUST make the same 726 decision for the same packet. An obvious approach is to map each 727 DiffServ Code Point (DSCP) [RFC2474] to a single link metric. 728 (This may be a many to one mapping.) 730 o Selecting which link metrics to support on each OLSRv2 interface 731 and implementing that decision. (Different interfaces may have 732 different physical and data link layer properties, and this may 733 inform the selection of link metrics to support, and their 734 values.) If the MANET may contain non-MT-OLSRv2 routers, which is 735 also subject to management, then the rules for link metric 736 assignment to OLSRv2 interfaces in this specification for that 737 case MUST be followed. 739 o Ensuring that the MANET is sufficiently connected, by ensuring 740 that, for example, sufficiently many routers implement each metric 741 type required (this being easier in, for example, a denser 742 network). Note that if there is any possibility that there are 743 any routers not implementing MT-OLSRv2, then the MANET will be 744 connected, to the maximum extent possible, using the link metric 745 type LINK_METRIC_TYPE, but this will only serve to deliver packets 746 that use that link metric type. 748 o Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets 749 that will be routed by a topology that they are not part of. 750 However if they were to do so then such packets will be routed 751 until either they reach their destination, or they reach an MT- 752 OLSRv2 router. In the latter case the packet will then either be 753 dropped (if that MT-OLSRv2 router is not part of that topology, or 754 is not aware of the destination within that topology) or will be 755 routed by that topology to the destination. Such a packet will 756 not loop. 758 o If a packet is created for a destination that is not part of the 759 corresponding topology then it may or may not be delivered (if the 760 originating router is a non-MT-OLSRv2 router) or will not be 761 transmitted (if the originating router is an MT-OLSRv2 router). 762 Routers SHOULD be managed so that this does not occur. 764 13. IANA Considerations 766 This specification adds one new Message TLV, allocated as a new Type 767 Extension to an existing Message TLV, using a new name. It also 768 modifies the Value field of an existing Message TLV, and of an 769 existing Address Block TLV. Finally, this specification makes 770 additional allocations from the LINK_METRIC Address Block TLV Type 771 registry. 773 13.1. Expert Review: Evaluation Guidelines 775 For the registry where an Expert Review is required, the designated 776 expert SHOULD take the same general recommendations into 777 consideration as are specified by [RFC5444] and [RFC7631]. 779 13.2. Message TLV Types 781 This specification modifies the Message TLV Type 7, replacing Table 4 782 of [RFC7631] by Table 2, changing the description of the Type 783 Extension MPR_WILLING and adding the Type Extension TLV_TYPES. Each 784 of these TLVs MUST NOT be included more than once in a Message TLV 785 Block. 787 +-----------+-------------+-------------------------+---------------+ 788 | Type | Name | Description | Reference | 789 | Extension | | | | 790 +-----------+-------------+-------------------------+---------------+ 791 | 0 | MPR_WILLING | First (most | [RFC7181] | 792 | | | significant) half octet | [RFC7631] | 793 | | | of Value field | This | 794 | | | specifies the | specification | 795 | | | originating router's | | 796 | | | willingness to act as a | | 797 | | | flooding MPR; | | 798 | | | subsequent half octets | | 799 | | | specify the originating | | 800 | | | router's willingness to | | 801 | | | act as a routing MPR, | | 802 | | | either for the link | | 803 | | | metric types reported | | 804 | | | in an MPR_TYPES TLV (in | | 805 | | | the same order), or (if | | 806 | | | no MPR_TYPES TLV is | | 807 | | | present) for the single | | 808 | | | administratively agreed | | 809 | | | link metric type | | 810 | 1 | MPR_TYPES | The link metric types | This | 811 | | | supported on this | specification | 812 | | | OLSRv2 interface of | | 813 | | | this router (one octet | | 814 | | | each). | | 815 | 2-223 | | Unassigned | | 816 | 224-255 | | Reserved for | [RFC7181] | 817 | | | Experimental Use | | 818 +-----------+-------------+-------------------------+---------------+ 820 Table 2: Type 7 Message TLV Type Extensions 822 13.3. Address Block TLV Types 824 Table 7 of [RFC7188] is replaced by Table 3. 826 +-------+-------+----------+----------------------------------------+ 827 | Bit | Value | Name | Description | 828 +-------+-------+----------+----------------------------------------+ 829 | First | First | Flooding | If set then the neighbor with that | 830 | octet | octet | | network address has been selected as | 831 | bit 7 | 0x01 | | flooding MPR | 832 | From | From | Routing | If set then the neighbor with that | 833 | first | first | | network address has been selected as | 834 | octet | octet | | routing MPR, either for the link | 835 | bit 6 | 0x02 | | metric types reported in an MPR_TYPES | 836 | | | | TLV (in the same order), or (if no | 837 | | | | MPR_TYPES TLV is present) then (first | 838 | | | | octet bit 6, value 0x02) for the | 839 | | | | single administratively agreed link | 840 | | | | metric type | 841 +-------+-------+----------+----------------------------------------+ 843 Table 3: MPR TLV Bit Values 845 Table 14 of [RFC7631] is replaced by Table 4. The only changes are 846 to the Description and the References for the GATEWAY TLV. 848 +-----------+---------+-----------------------------+---------------+ 849 | Type | Name | Description | References | 850 | Extension | | | | 851 +-----------+---------+-----------------------------+---------------+ 852 | 0 | GATEWAY | Specifies that a given | [RFC7181] | 853 | | | network address is reached | This | 854 | | | via a gateway on the | specification | 855 | | | originating router. The | | 856 | | | number of hops is indicated | | 857 | | | by the Value field, one | | 858 | | | octet per link metric type | | 859 | | | reported in an MPR_TYPES | | 860 | | | Message TLV (in the same | | 861 | | | order) or (if no MPR_TYPES | | 862 | | | Message TLV is present) | | 863 | | | using a single octet | | 864 | 1-223 | | Unassigned | | 865 | 224-255 | | Reserved for Experimental | [RFC7631] | 866 | | | Use | | 867 +-----------+---------+-----------------------------+---------------+ 869 Table 4: Type 10 Address Block TLV Type Extensions 871 Table 13 of [RFC7181] is replaced by Table 5. The only change is to 872 allocate 8 Type Extensions as assigned by administrative action, in 873 order to support administratively determined multi-topologies. 875 +-------------+------+-----------+-------------------+--------------+ 876 | Name | Type | Type | Description | Allocation | 877 | | | Extension | | Policy | 878 +-------------+------+-----------+-------------------+--------------+ 879 | LINK_METRIC | 7 | 0-7 | Link metric | | 880 | | | | meaning assigned | | 881 | | | | by administrative | | 882 | | | | action. | | 883 | LINK_METRIC | 7 | 8-223 | Unassigned. | Expert | 884 | | | | | Review | 885 | LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental | 886 | | | | | Use | 887 +-------------+------+-----------+-------------------+--------------+ 889 Table 5: Address Block TLV Type assignment: LINK_METRIC 891 14. Security Considerations 893 This extension to OLSRv2 allows a router to support more than one 894 link metric type for each link advertised in HELLO and TC messages, 895 and for routers to support different sets of types. Link metric 896 values of additional types are reported by the inclusion of 897 additional TLVs in the messages sent by a router, which will report 898 known values of all supported types. 900 HELLO and TC message processing is then extended simply to record, 901 for each supported type, all of the received link metric values for 902 each link. Protocol internal processing (specifically MPR set and 903 shortest path calculations) then operate as specified in [RFC7181] 904 for each link metric type that the router supports. 906 Consequently the security considerations, including the security 907 architecture and the mandatory security mechanisms, from [RFC7181] 908 are directly applicable to MT-OLSRv2. 910 Furthermore, this extension does not introduce any additional 911 vulnerabilities over those of [RFC7181], because each link metric 912 type is used independently, and each one could have been the single 913 link metric type supported by an implementation of [RFC7181] 914 receiving the same information, as received information of an 915 unsupported type is ignored by all routers. 917 15. Acknowledgments 919 The authors would like to thank (in alphabetical order): Juliusz 920 Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems), 921 Susan Hares (Huawei) and Henning Rogge (FGAN) for discussions and 922 suggestions. 924 16. References 926 16.1. Normative References 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, March 1997. 931 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 932 "Generalized MANET Packet/Message Format", RFC 5444, 933 February 2009. 935 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 936 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 937 RFC 6130, April 2011. 939 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 940 "The Optimized Link State Routing Protocol version 2", 941 RFC 7181, April 2014. 943 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 944 Protocol version 2 (OLSRv2) and MANET Neighborhood 945 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 946 April 2014. 948 [RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET 949 Generalized Packet/Message Format", RFC 7631, 950 January 2015. 952 16.2. Informative References 954 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 955 "Definition of the Differentiated Services Field (DS 956 Field) in the IPv4 and IPv6 Headers", RFC 2474, 957 December 1998. 959 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 960 (MANET): Routing Protocol Performance Issues and 961 Evaluation Considerations", RFC 2501, January 1999. 963 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 964 Routing Protocol", RFC 3626, October 2003. 966 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 967 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 968 RFC 4915, June 2007. 970 Authors' Addresses 972 Christopher Dearlove 973 BAE Systems Applied Intelligence Laboratories 974 West Hanningfield Road 975 Great Baddow, Chelmsford 976 United Kingdom 978 Phone: +44 1245 242194 979 Email: chris.dearlove@baesystems.com 980 URI: http://www.baesystems.com/ 982 Thomas Heide Clausen 983 LIX, Ecole Polytechnique 985 Phone: +33 6 6058 9349 986 Email: T.Clausen@computer.org 987 URI: http://www.ThomasClausen.org/