idnits 2.17.1 draft-ietf-manet-olsrv2-multitopology-06.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 (July 6, 2015) is 3215 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 ATC 4 Updates: 7188, [tlv-naming] T. Clausen 5 (if approved) LIX, Ecole Polytechnique 6 Intended status: Experimental July 6, 2015 7 Expires: January 7, 2016 9 Multi-Topology Extension for the Optimized Link State Routing Protocol 10 version 2 (OLSRv2) 11 draft-ietf-manet-olsrv2-multitopology-06 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 RFC 7188 and [tlv-naming] 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 January 7, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 8 65 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 9 69 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 9 70 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 10 71 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 10 72 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 13 80 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 81 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 13 82 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 14 83 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 15 85 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 15 86 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 15 87 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 16 88 12. Management Considerations . . . . . . . . . . . . . . . . . . 16 89 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 17 91 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 17 92 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 18 93 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 16.1. Normative References . . . . . . . . . . . . . . . . . . . 21 97 16.2. Informative References . . . . . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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 While general experiences with this protocol extension, including 135 interoperability of implementations, are encouraged, specific 136 information would be particularly appreciated on the following areas: 138 o Operation in a network that contains both routers implementing 139 this extension, and routers implementing only [RFC7181], in 140 particular are there any unexpected interactions that can break 141 the network? 143 o Operation in realistic deployments, and details thereof, including 144 in particular indicating how many concurrent topologies were 145 required. 147 A broader issue that applies to unextended [RFC7181] as well as this 148 extension (and potentially to other MANET routing protocols) is which 149 link metric types are useful in a MANET, and how to establish the 150 metrics to associate with a given link. While this issue is not only 151 related to this extension, the ability for an OLSRv2 network to 152 maintain different concurrent link metrics may facilitate both 153 experiments with different link metric types, ways to measure them, 154 etc. and may also allow experimentation with link metric types that 155 are not compromises to handle multiple traffic types. 157 2. Terminology and Notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 [RFC2119]. 164 This specification uses the terminology of [RFC5444], [RFC6130] and 165 [RFC7181], which is to be interpreted as described in those 166 specifications. 168 Additionally, this specification uses the following terminology: 170 Router - A MANET router that implements [RFC7181]. 172 MT-OLSRv2 - The protocol defined in this specification as an 173 extension to [RFC7181]. 175 This specification introduces the notation map[A -> B] to represent 176 an associative mapping. The domain of this mapping (A) is, in this 177 specification, always a set of link metric types that the router 178 supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as 179 defined in Section 5. The codomain of this mapping (B) is a set of 180 all possible values of an appropriate type, in this specification 181 this type is always one of: 183 o boolean (true or false), 185 o willingness (a 4 bit unsigned integer from 0 to 15); 187 o number of hops (an 8 bit unsigned integer from 0 to 255), or 189 o link metric (either a representable link metric value, as 190 described in [RFC7181], or UNKNOWN_METRIC). 192 3. Applicability Statement 194 The protocol described in this specification is applicable to a MANET 195 for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), 196 but in which multiple topologies are maintained, each characterized 197 by a different choice of link metric type. It is assumed, but 198 outside the scope of this specification, that the network layer is 199 able to choose which topology to use for each packet, for example 200 using the DiffServ Code Point (DSCP) defined in [RFC2474]. This 201 selection of topology MUST be consistent, that is each router 202 receiving a packet must make the same choice of link metric type, in 203 order that each packet uses a single topology. This is necessary to 204 avoid the possibility of a packet "looping" in the network. 206 4. Protocol Overview and Functioning 208 The purpose of this specification is to extend [RFC7181] so as to 209 enable a router to establish and maintain multiple routing topologies 210 in a MANET, each topology associated with a link metric type. 211 Routers in the MANET may each form part of some or all of these 212 topologies, and each router will maintain a Routing Set for each 213 topology that it forms part of, allowing separate routing of packets 214 for each topology. 216 MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be 217 created containing both routers that implement MT-OLSRv2 (MT-OLSRv2 218 routers) and routers that do not implement MT-OLSRv2, and may be 219 unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be 220 created that are known to contain only MT-OLSRv2 routers. In both 221 cases, but especially the former, management may be required to 222 ensure that the MANET will function as required, and does not, for 223 example, unnecessarily fragment. (Such issues already arise in an 224 OLSRv2-based MANET using multiple interfaces.) 226 Each router implementing this specification selects a set of link 227 metric types for each of its OLSRv2 interfaces. If all routers in 228 the MANET implement MT-OLSRv2, then there are no restrictions within 229 this specification on how these sets of link metrics are selected. 230 (However the issues described in the preceding paragraph still 231 apply.) However in MANETs containing non-MT-OLSRv2 routers, the 232 single link metric used by these non-MT-OLSRv2 routers must be 233 included in the set of link metrics for each OLSRv2 interface of an 234 MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non- 235 MT-OLSRv2 router in the MANET. 237 Each router then determines an incoming link metric for each link 238 metric type selected for each of its OLSRv2 interfaces. These link 239 metrics are distributed using link metric TLVs contained in all HELLO 240 messages sent on OLSRv2 interfaces, and in all TC messages. Both 241 HELLO and TC messages generated by an MT-OLSRv2 router (other than 242 one using only the single metric type used by non-MT-OLSRv2 routers) 243 include an MPR_TYPES Message TLV that indicates that this is an MT- 244 OLSRv2 router and which metric types it supports (on the sending 245 OLSRv2 interface for a HELLO message). 247 In addition to link and neighbor metric values for each link metric 248 type, router MPR (multipoint relay) and MPR selector status, and 249 advertised neighbor status, is maintained per supported neighbor 250 metric type, for each symmetric 1-hop neighbor. Each router may 251 choose a different willingness to be a routing MPR for each link 252 metric type that it supports. 254 A network using MT-OLSRv2 will usually require greater management 255 than one using unmodified OLSRv2. In particular, the use of multiple 256 metric types across the MANET must be managed, by administrative 257 configuration or otherwise. As also for other decisions that may be 258 made when using OLSRv2, a bad collective choice of metric type use 259 will make the MANET anywhere from inefficient to non-functional, so 260 care will be needed in selecting supported link metric types across 261 the MANET. 263 The meanings of link metric types are at the discretion of the MANET 264 operator, they could be be used, for example, to represent packets of 265 different types, packets in streams of different rates, or packets 266 with different trust requirements. Note that packets will generally 267 not be delivered to routers that do not support that link metric 268 type, and the MANET, and the packets sent in it, will need to be 269 managed accordingly (especially if containing any non-MT-OLSRv2 270 routers). 272 5. Parameters 274 The parameters used in [RFC7181], including from its normative 275 references, are used in this specification with the following 276 changes. 278 Each OLSRv2 interface will support a number of link metric types, 279 corresponding to Type Extensions of the LINK_METRIC TLV defined in 280 [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers 281 that do not implement MT-OLSRv2, and used with that definition in 282 this specification, is replaced in routers implementing MT-OLSRv2 by 283 an interface parameter array IFACE_METRIC_TYPES and a router 284 parameter array ROUTER_METRIC_TYPES. Each element in these arrays is 285 a link metric type (i.e., a type extension used by the LINK_METRIC 286 TLV [RFC7181]). 288 The interface parameter array IFACE_METRIC_TYPES contains the link 289 metric types supported on that OLSRv2 interface. The router 290 parameter array ROUTER_METRIC_TYPES is the union of all of the 291 IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. 293 If in a given deployment there may be any routers that do not 294 implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST first include 295 LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate 296 with any routers that do not implement MT-OLSRv2. In that case, 297 ROUTER_METRIC_TYPES MUST also first include LINK_METRIC_TYPE. 299 In addition, the router parameter WILL_ROUTING is extended to an 300 array of values, one each for each link metric type in the router 301 parameter list ROUTER_METRIC_TYPES. 303 6. Information Bases 305 The Information Bases specified in [RFC7181], which extend those 306 specified in in [RFC6130], are further extended in this 307 specification. With the exception of the Routing Set, the extensions 308 in this specification are the replacement of single values (boolean, 309 willingness, number of hops, or link metric) from [RFC7181] with 310 elements representing multiple values (associative mappings from a 311 set of metric types to their corresponding values). The following 312 subsections detail these extensions. 314 Note that, as in [RFC7181], an implementation is free to organize its 315 internal data in any manner it chooses, it needs only to behave as if 316 it were organized as described in [RFC7181] and this specification. 318 6.1. Local Attached Network Set 320 Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of 321 hops]. 323 Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link 324 metric]. 326 6.2. Link Sets 328 Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link 329 metric]. 331 Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link 332 metric]. 334 The elements of L_in_metric MUST be set following the same rules that 335 apply to the setting of the single element L_in_metric in [RFC7181]. 337 6.3. 2-Hop Sets 339 Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 340 metric]. 342 Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 343 metric]. 345 6.4. Neighbor Set 347 Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 348 metric]. 350 Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 351 metric]. 353 Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> 354 willingness]. 356 Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> 357 boolean]. 359 Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> 360 boolean]. 362 Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> 363 boolean]. 365 6.5. Router Topology Set 367 Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link 368 metric]. 370 Note that some values of TR_metric may now take the value 371 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 372 corresponding link metric value from this mapping is used, Router 373 Topology Tuples whose corresponding value from TR_metric is 374 UNKNOWN_METRIC are ignored. 376 6.6. Routable Address Topology Set 378 Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link 379 metric]. 381 Note that some values of TA_metric may now take the value 382 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 383 corresponding link metric value from this mapping is used, Routable 384 Address Topology Tuples whose corresponding value from TA_metric is 385 UNKNOWN_METRIC are ignored. 387 6.7. Attached Network Set 389 Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of 390 hops]. 392 Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link 393 metric]. 395 Note that some values of AN_metric may now take the value 396 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 397 corresponding link metric value from this mapping is used, Attached 398 Network Tuples whose corresponding value from AN_metric is 399 UNKNOWN_METRIC are ignored. 401 6.8. Routing Sets 403 There is a separate Routing Set for each link metric type in 404 ROUTER_METRIC_TYPES. 406 7. TLVs 408 This specification makes the following additions and extensions to 409 the TLVs defined in [RFC7181]. 411 7.1. Message TLVs 413 One new Message TLV is defined in this specification, and one 414 existing Message TLV is extended by this specification. 416 7.1.1. MPR_TYPES TLV 418 The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 419 interfaces and TC messages. A message MUST NOT contain more than one 420 MPR_TYPES TLV. 422 The presence of this TLV in a message is used to indicate that the 423 router supports MT-OLSRv2, in the same way that the presence of the 424 MPR_WILLING TLV is used to indicate that the router supports OLSRv2, 425 as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has 426 been defined with the same Type as the MPR_WILLING TLV, but with Type 427 Extension = 1. 429 This TLV may take a Value field of any size. Each octet in its Value 430 field will contain a link metric type that is supported, either on 431 any OLSRv2 interface, when included in a TC message, or on the OLSRv2 432 interface on which an including HELLO message is sent. These octets 433 MAY be in any order, except that if there may be any routers in the 434 MANET not implementing MT-OLSRv2, then the first octet MUST be 435 LINK_METRIC_TYPE. 437 7.1.2. MPR_WILLING TLV 439 The MPR_WILLING TLV, which is used in HELLO messages, is specified in 440 [RFC7181], and extended in this specification as enabled by 441 [RFC7188]. 443 The interpretation of this TLV, specified by [RFC7181], and which 444 uses all of its single octet Value field, is unchanged. That 445 interpretation uses bits 0-3 of its Value field to specify its 446 willingness to be a flooding TLV, and bits 4-7 of its Value field to 447 be a routing TLV. Those latter bits are, when using this 448 specification, interpreted as its willingness to be a routing TLV 449 using the link metric type LINK_METRIC_TYPE. 451 The extended use of this message TLV, as defined by this 452 specification, defines additional 4 bit sub-fields of the Value 453 field, starting with bits 4-7 of the first octet and continuing with 454 bits 0-3 of the second octet, to represent willingness to be a 455 routing MPR using the link metric types specified in this OLSRv2 456 interface's IFACE_METRIC_TYPES parameter, ordered as reported in the 457 included MPR_TYPES Message TLV. Note that this means that the link 458 metric type LINK_METRIC_TYPE will continue to occupy bits 4-7 of the 459 first octet. (If there is no such TLV included, then the router does 460 not support MT-OLSRv2, and only the first octet of the Value field 461 will be used.) 463 If the number of link metric types in this OLSRv2 interface's 464 IFACE_METRIC_TYPES parameter is even, then there will be an unused 4 465 bit sub-field in bits 4-7 of the last octet of a full sized Value 466 field. These bits will not be used, they SHOULD all be cleared 467 ('0'). 469 If the Value field in an MPR_WILLING TLV is shorter than its full 470 length, then, as specified in [RFC7188], missing Value octets, i.e., 471 missing willingness values, are considered as zero, i.e., as 472 WILL_NEVER. This is the correct behavior. (In particular it means 473 that an OLSRv2 router that is not implementing MT-OLSRv2 will not act 474 as a routing MPR for any link metric that it does not recognize.) 476 7.2. Address Block TLVs 478 New Type Extensions are defined for the LINK_METRIC TLV defined in 479 [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, 480 both defined in [RFC7181], are extended, as enabled by [RFC7188]. 482 7.2.1. LINK_METRIC TLV 484 The LINK_METRIC TLV is used in HELLO messages and TC messages. This 485 TLV is unchanged from the definition in [RFC7181]. 487 Only a single Type Extension was specified by [RFC7181] (link metric 488 type) 0 as defined by administrative action. This specification 489 extends this range to 0-7. This specification will work with any 490 combination of Type Extensions both within and without that range 491 (assuming that the latter are defined as specified in [RFC7181]). 493 7.2.2. MPR TLV 495 The MPR TLV is used in HELLO messages, and indicates that an address 496 with which it is associated is of a symmetric 1-hop neighbor that has 497 been selected as an MPR. 499 The Value field of this address block TLV is, in [RFC7181], defined 500 to be one octet long, with the values 1, 2 and 3 defined. [RFC7188] 501 redefines this Value field to be a bitfield where bit 7 (the lsb) 502 denotes flooding status, bit 6 denotes routing MPR status, and bits 503 5-0 are unallocated (respecting the semantics of the bits/values 1, 2 504 and 3 from [RFC7181]). 506 This specification, as enabled by [RFC7188], extends the MPR TLV to 507 have a variable-length Value field. For interoperability with a 508 router not implementing MT-OLSRv2, the two least significant bits of 509 the first octet in the Value field of this TLV MUST be the TLV Value 510 of the MPR TLV, generated according to [RFC7181]. 512 Subsequent bits (in increasing significance within an octet, then 513 continuing with the least significant bit in the next octet, if 514 required) in the TLV Value field indicate which link metric types, 515 for which the corresponding address is selected as a routing MPR, 516 link metric types (including the first) being indicated in, and used 517 in the same order as, the Value field of an MPR_TYPES Message TLV, 518 excluding the link metric type LINK_METRIC_TYPE, which already 519 occupies the second bit. 521 7.2.3. GATEWAY TLV 523 The GATEWAY TLV is used in TC messages to indicate that a network 524 address is of an attached network. 526 The Value field of this address block TLV is, in [RFC7181] defined to 527 be one octet long, containing the number of hops to that attached 528 network. 530 This specification, as enabled by [RFC7181], allows the extension the 531 GATEWAY TLV to have a variable-length Value field when the number of 532 hops to each attached network is different for different link metric 533 types. For interoperability with a router not implementing MT- 534 OLSRv2, the first octet in the Value field of this TLV MUST be the 535 TLV Value of the GATEWAY TLV generated according to [RFC7181]. 537 Any subsequent octets in the TLV Value field indicate the number of 538 hops to the attached network for each other link metric type, link 539 metric types (including the first) being indicated in the Value field 540 of an MPR_TYPES Message TLV. 542 +---------+---------------------------------------------------------+ 543 | Type | Value | 544 +---------+---------------------------------------------------------+ 545 | GATEWAY | Number of hops to attached network for each link metric | 546 | | type. | 547 +---------+---------------------------------------------------------+ 549 Table 1: GATEWAY TLV definition 551 8. HELLO Messages 553 The following changes are made to the generation and processing of 554 HELLO messages compared to that described in [RFC7181] by routers 555 that implement MT-OLSRv2. 557 8.1. HELLO Message Generation 559 A generated HELLO message to be sent on an OLSRv2 interface (whose 560 IFACE_METRIC_TYPES parameter will be that used) is extended by: 562 o Adding an MPR_TYPES Message TLV. The Value octets will be the 563 link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted 564 if the only link metric type included would be LINK_METRIC_TYPE. 566 o Extending the MPR_WILLING Message TLV Value field to report the 567 willingness values from the WILL_ROUTING parameter list that 568 correspond to the link metric types in IFACE_METRIC_LIST, in the 569 same order as reported in the MPR_TYPES TLV, each value (also 570 including one representing WILL_FLOODING) occupying 4 bits. 572 o Including LINK_METRIC Address Block TLVs that report all values in 573 L_in_metric, L_out_metric, N_in_metric and N_out_metric elements 574 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 575 being the link metric type, and otherwise following the rules for 576 such inclusions specified in [RFC7181]. 578 o Including MPR Address Block TLVs such that for each link metric 579 type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, 580 the indicated addresses MUST be of the MPRs in an MPR set as 581 specified for a single link metric type in [RFC7181]. 583 8.2. HELLO Message Processing 585 On receipt of a HELLO message on an OLSRv2 interface, a router 586 implementing MT-OLSRv2 MUST, in addition to the processing described 587 in [RFC7181]: 589 1. Determine the list of link metric types supported by the sending 590 router on its corresponding OLSRv2 interface, either from an 591 MPR_TYPES Message TLV or, if not present, the single link metric 592 type LINK_METRIC_TYPE. 594 2. For those link metric types supported by both routers, set the 595 appropriate L_out_metric, N_in_metric, N_out_metric, 596 N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and 597 N2_out_metric values as described for single such elements in 598 [RFC7181]. 600 3. For any other metric types supported by the receiving router only 601 (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set 602 the elements listed in the previous point to their default 603 values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or 604 false. 606 9. TC Messages 608 The following changes are made to the generation and processing of TC 609 messages compared to that described in [RFC7181] by routers that 610 implement MT-OLSRv2. 612 9.1. TC Message Generation 614 A generated TC message is extended by: 616 o Adding an MPR_TYPES TLV. The value octets will be the link metric 617 types in ROUTER_METRIC_TYPES. This MAY be omitted if the only 618 link metric type included would be LINK_METRIC_TYPE. 620 o Including LINK_METRIC TLVs that report all values of N_out_metric 621 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 622 being the link metric type, and otherwise following the rules for 623 such inclusions specified in [RFC7181]. 625 o When not all the same, including a number of hops per reported (in 626 an MPR_TYPES Message TLV) link metric type in the Value field of 627 each GATEWAY TLV included, in the same order as reported in the 628 MPR_TYPES TLV. 630 9.2. TC Message Processing 632 On receipt of a TC message, a router implementing this extension 633 MUST, in addition to the processing specified in [RFC7181]: 635 o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric 636 elements using the rules for setting the single elements of those 637 types specified in [RFC7181]. 639 o For any other metric types supported by the receiving router that 640 do not have an advertised outgoing neighbor metric of that type, 641 set the corresponding elements of TR_metric, TA_metric and 642 AN_metric to UNKNOWN_METRIC. (The corresponding element of 643 AN_dist may be set to any value.) 645 10. MPR Calculation 647 Routing MPRs are calculated for each link metric type in 648 ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 649 interfaces that do not support that link metric type are not 650 considered. The determined status (routing MPR or not routing MPR) 651 for each link metric type is recorded in the relevant element of 652 N_routing_mpr. 654 Each router may make its own decision as to whether or not to use a 655 link metric, or link metrics, for flooding MPR calculation, and if so 656 which and how. This decision MUST be made in a manner that ensures 657 that flooded messages will reach the same symmetric 2-hop neighbors 658 as would be the case for a router not supporting MT-OLSRv2. 660 Note that it is possible that a 2-Hop Tuple in the Information Base 661 for a given OLSRv2 interface does not support any of the link metric 662 types that are in the router's corresponding IFACE_METRIC_TYPES, but 663 nevertheless that 2-Hop Tuple MUST be considered when determining 664 flooding MPRs. 666 11. Routing Set Calculation 668 A Routing Set is calculated for each link metric type in 669 ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except 670 that where an element is now represented by a map, the value from the 671 map for the selected link metric type is used. Where this is a link 672 metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for 673 the calculation. 675 12. Management Considerations 677 MT-OLSRv2 may require greater management than unextended OLSRv2. In 678 particular a MANET using MT-OLSRv2 requires the following management 679 considerations: 681 o Deciding which link metric, and hence which Routing Set to use, 682 for received packets, hence how to use the Routing Sets to 683 configure the network layer (IP). All routers MUST make the same 684 decision for the same packet. An obvious approach is to map each 685 DiffServ Code Point (DSCP) [RFC2474] to a single link metric. 686 (This may be a many to one mapping.) 688 o Selecting which link metrics to support on each OLSRv2 interface 689 and implementing that decision. (Different interfaces may have 690 different physical and data link layer properties, and this may 691 inform the selection of link metrics to support, and their 692 values.) If the MANET may contain non-MT-OLSRv2 routers, which is 693 also subject to management, then the rules for link metric 694 assignment to OLSRv2 interfaces in this specification for that 695 case MUST be followed. 697 o Ensuring that the MANET is sufficiently connected, by ensuring 698 that, for example, sufficiently many routers implement each metric 699 type required (this being easier in, for example, a denser 700 network). Note that if there is any possibility that there are 701 any routers not implementing MT-OLSRv2, then the MANET will be 702 connected, to the maximum extent possible, using the link metric 703 type LINK_METRIC_TYPE, but this will only serve to deliver packets 704 that use that link metric type. 706 o Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets 707 that will be routed by a topology that they are not part of. 708 However if they were to do so then such packets will be routed 709 until either they reach their destination, or they reach an MT- 710 OLSRv2 router. In the latter case the packet will then either be 711 dropped (if that MT-OLSRv2 router is not part of that topology, or 712 is not aware of the destination within that topology) or will be 713 routed by that topology to the destination. Such a packet will 714 not loop. 716 o If a packet is created for a destination that is not part of the 717 corresponding topology then it may or may not be delivered (if the 718 originating router is a non-MT-OLSRv2 router) or will not be 719 transmitted (if the originating router is an MT-OLSRv2 router). 720 Routers SHOULD be managed so that this does not occur. 722 13. IANA Considerations 724 This specification adds one new Message TLV, allocated as a new Type 725 Extension to an existing Message TLV, using a new name. It also 726 modifies the Value field of an existing Message TLV, and of an 727 existing Address Block TLV. Finally, this specification makes 728 additional allocations from the LINK_METRIC Address Block TLV Type 729 registry. 731 This specification assumes that the TLV renaming specified in 732 [tlv-naming] has been carried out. 734 13.1. Expert Review: Evaluation Guidelines 736 For the registry where an Expert Review is required, the designated 737 expert SHOULD take the same general recommendations into 738 consideration as are specified by [RFC5444] and [tlv-naming]. 740 13.2. Message TLV Types 742 This specification modifies the Message TLV Type 7, replacing Table 4 743 of [tlv-naming] by Table 2, changing the description of the Type 744 Extension MPR_WILLING and adding the Type Extension TLV_TYPES. Each 745 of these TLVs MUST NOT be included more than once in a Message TLV 746 Block. 748 +-----------+-------------+-------------------------+---------------+ 749 | Type | Name | Description | Reference | 750 | Extension | | | | 751 +-----------+-------------+-------------------------+---------------+ 752 | 0 | MPR_WILLING | First (most | [RFC7181] | 753 | | | significant) half octet | [tlv-naming] | 754 | | | of Value field | This | 755 | | | specifies the | specification | 756 | | | originating router's | | 757 | | | willingness to act as a | | 758 | | | flooding MPR; | | 759 | | | subsequent half octets | | 760 | | | specify the originating | | 761 | | | router's willingness to | | 762 | | | act as a routing MPR, | | 763 | | | either for the link | | 764 | | | metric types reported | | 765 | | | in an MPR_TYPES TLV (in | | 766 | | | the same order), or (if | | 767 | | | no MPR_TYPES TLV is | | 768 | | | present) for the single | | 769 | | | administratively agreed | | 770 | | | link metric type | | 771 | 1 | MPR_TYPES | The link metric types | This | 772 | | | supported on this | specification | 773 | | | OLSRv2 interface of | | 774 | | | this router (one octet | | 775 | | | each). | | 776 | 2-223 | | Unassigned | | 777 | 224-255 | | Reserved for | [RFC7181] | 778 | | | Experimental Use | | 779 +-----------+-------------+-------------------------+---------------+ 781 Table 2: Type 7 Message TLV Type Extensions 783 13.3. Address Block TLV Types 785 Table 7 of [RFC7188] is replaced by Table 3. 787 +-------+-------+----------+----------------------------------------+ 788 | Bit | Value | Name | Description | 789 +-------+-------+----------+----------------------------------------+ 790 | First | First | Flooding | If set then the neighbor with that | 791 | octet | octet | | network address has been selected as | 792 | bit 7 | 0x01 | | flooding MPR | 793 | From | From | Routing | If set then the neighbor with that | 794 | first | first | | network address has been selected as | 795 | octet | octet | | routing MPR, either for the link | 796 | bit 6 | 0x02 | | metric types reported in an MPR_TYPES | 797 | | | | TLV (in the same order), or (if no | 798 | | | | MPR_TYPES TLV is present) then (first | 799 | | | | octet bit 6, value 0x02) for the | 800 | | | | single administratively agreed link | 801 | | | | metric type | 802 +-------+-------+----------+----------------------------------------+ 804 Table 3: MPR TLV Bit Values 806 Table 14 of [tlv-naming] is replaced by Table 4. The only changes 807 are to the Description and the References for the GATEWAY TLV. 809 +-----------+---------+-----------------------------+---------------+ 810 | Type | Name | Description | References | 811 | Extension | | | | 812 +-----------+---------+-----------------------------+---------------+ 813 | 0 | GATEWAY | Specifies that a given | [RFC7181] | 814 | | | network address is reached | This | 815 | | | via a gateway on the | specification | 816 | | | originating router. The | | 817 | | | number of hops is indicated | | 818 | | | by the Value field, one | | 819 | | | octet per link metric type | | 820 | | | reported in an MPR_TYPES | | 821 | | | Message TLV (in the same | | 822 | | | order) or (if no MPR_TYPES | | 823 | | | Message TLV is present) | | 824 | | | using a single octet | | 825 | 1-223 | | Unassigned | | 826 | 224-255 | | Reserved for Experimental | [tlv-naming] | 827 | | | Use | | 828 +-----------+---------+-----------------------------+---------------+ 830 Table 4: Type 10 Address Block TLV Type Extensions 832 Table 13 of [RFC7181] is replaced by Table 5. The only change is to 833 allocate 8 Type Extensions as assigned by administrative action, in 834 order to support administratively determined multi-topologies. 836 +-------------+------+-----------+-------------------+--------------+ 837 | Name | Type | Type | Description | Allocation | 838 | | | Extension | | Policy | 839 +-------------+------+-----------+-------------------+--------------+ 840 | LINK_METRIC | 7 | 0-7 | Link metric | | 841 | | | | meaning assigned | | 842 | | | | by administrative | | 843 | | | | action. | | 844 | LINK_METRIC | 7 | 8-223 | Unassigned. | Expert | 845 | | | | | Review | 846 | LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental | 847 | | | | | Use | 848 +-------------+------+-----------+-------------------+--------------+ 850 Table 5: Address Block TLV Type assignment: LINK_METRIC 852 14. Security Considerations 854 This extension to OLSRv2 allows a router to support more than one 855 link metric type for each link advertised in HELLO and TC messages, 856 and for routers to support different sets of types. Link metric 857 values of additional types are reported by the inclusion of 858 additional TLVs in the messages sent by a router, which will report 859 known values of all supported types. 861 HELLO and TC message processing is then extended simply to record, 862 for each supported type, all of the received link metric values for 863 each link. Protocol internal processing (specifically MPR set and 864 shortest path calculations) then operate as specified in [RFC7181] 865 for each link metric type that the router supports. 867 Consequently the security considerations, including the security 868 architecture and the mandatory security mechanisms, from [RFC7181] 869 are directly applicable to MT-OLSRv2. 871 Furthermore, this extension does not introduce any additional 872 vulnerabilities over those of [RFC7181], because each link metric 873 type is used independently, and each one could have been the single 874 link metric type supported by an implementation of [RFC7181] 875 receiving the same information, as received information of an 876 unsupported type is ignored by all routers. 878 15. Acknowledgments 880 The authors would like to thank (in alphabetical order): Juliusz 881 Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems) 882 and Henning Rogge (FGAN) for discussions and suggestions. 884 16. References 886 16.1. Normative References 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, March 1997. 891 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 892 "Generalized MANET Packet/Message Format", RFC 5444, 893 February 2009. 895 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 896 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 897 RFC 6130, April 2011. 899 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 900 "The Optimized Link State Routing Protocol version 2", 901 RFC 7181, April 2014. 903 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 904 Protocol version 2 (OLSRv2) and MANET Neighborhood 905 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 906 April 2014. 908 [tlv-naming] 909 Dearlove, C. and T. Clausen, "TLV Naming in the MANET 910 Generalized Packet/Message Format", Work In 911 Progress draft-ietf-manet-tlv-naming-00.txt, January 2015. 913 16.2. Informative References 915 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 916 "Definition of the Differentiated Services Field (DS 917 Field) in the IPv4 and IPv6 Headers", RFC 2474, 918 December 1998. 920 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 921 (MANET): Routing Protocol Performance Issues and 922 Evaluation Considerations", RFC 2501, January 1999. 924 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 925 Routing Protocol", RFC 3626, October 2003. 927 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 928 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 929 RFC 4915, June 2007. 931 Authors' Addresses 933 Christopher Dearlove 934 BAE Systems Advanced Technology Centre 935 West Hanningfield Road 936 Great Baddow, Chelmsford 937 United Kingdom 939 Phone: +44 1245 242194 940 Email: chris.dearlove@baesystems.com 941 URI: http://www.baesystems.com/ 943 Thomas Heide Clausen 944 LIX, Ecole Polytechnique 946 Phone: +33 6 6058 9349 947 Email: T.Clausen@computer.org 948 URI: http://www.ThomasClausen.org/