idnits 2.17.1 draft-ietf-manet-olsrv2-multitopology-05.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 (Using the creation date from RFC7181, updated by this document, for RFC5378 checks: 2005-10-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 2015) is 3353 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) C. Dearlove 3 Internet-Draft BAE Systems ATC 4 Updates: 7181, 7188, XXXX T. Clausen 5 (if approved) LIX, Ecole Polytechnique 6 Intended status: Experimental February 20, 2015 7 Expires: August 24, 2015 9 Multi-Topology Extension for the Optimized Link State Routing Protocol 10 version 2 (OLSRv2) 11 draft-ietf-manet-olsrv2-multitopology-05 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 7181 by creating an interoperable 21 extension to it. This specification updates RFC 7188 and RFC XXXX by 22 modifying and extending TLV registries and descriptions. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 24, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Motivation and Experimentation . . . . . . . . . . . . . . 4 60 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 61 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 62 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 63 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 8 66 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 9 70 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 9 71 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 9 72 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 10 76 7.1.2. MPR_WILLING TLV . . . . . . . . . . . . . . . . . . . 10 77 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 11 78 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 11 79 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.2.3. GATEWAY TLV . . . . . . . . . . . . . . . . . . . . . 12 81 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 13 83 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 13 84 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 14 86 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 14 87 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 15 88 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 15 89 12. Management Considerations . . . . . . . . . . . . . . . . . . 15 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 17 92 13.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 17 93 13.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 18 94 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 95 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 96 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 16.1. Normative References . . . . . . . . . . . . . . . . . . . 20 98 16.2. Informative References . . . . . . . . . . . . . . . . . . 20 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Introduction 103 The Optimized Link State Routing Protocol, version 2 [RFC7181] 104 (OLSRv2) is a proactive link state routing protocol designed for use 105 in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant 106 improvements of OLSRv2 over its Experimental precursor [RFC3626] is 107 the ability of OLSRv2 to route over other than minimum hop routes, 108 using a link metric. 110 A limitation that remains in OLSRv2 is that it uses a single link 111 metric type for all routes. However in some MANETs it would be 112 desirable to be route packets using more than one link metric type. 113 This specification describes an extension to OLSRv2 that is designed 114 to permit this, while maintaining maximal interoperability with 115 OLSRv2 routers not implementing this extension. 117 The purpose of OLSRv2 can be described as to create and maintain a 118 Routing Set, which contains all the necessary information to populate 119 an IP routing table. In a similar way, the role of this extension 120 can be described as to create and maintain multiple Routing Sets, one 121 for each link metric type supported by the router maintaining the 122 sets. 124 1.1. Motivation and Experimentation 126 Multi-topology routing is a natural extension to a link state routing 127 protocol, as for example to OSPF (see [RFC4915]). However multi- 128 topology routing for OLSRv2 does not yet benefit from extensive 129 operational, or even experimental, experience. This specification is 130 published to facilitate collecting such experience, with the intent 131 that in a reasonable period of time after the acceptance of this 132 specification as an Experimental RFC (as soon as possible after 133 experimental evidence is collected), an OLSRv2 Multi-Topology Routing 134 Extension will be proposed for advancement onto Standards Track. 136 While general experiences with this protocol extension, including 137 interoperability of implementations, are encouraged, specific 138 information would be particularly appreciated on the following areas: 140 o Operation in a network that contains both routers implementing 141 this extension, and routers implementing only [RFC7181], in 142 particular are there any unexpected interactions that can break 143 the network? 145 o Operation in realistic deployments, and details thereof, including 146 in particular indicating how many concurrent topologies were 147 required. 149 A broader issue that applies to unextended [RFC7181] as well as this 150 extension (and potentially to other MANET routing protocols) is which 151 link metric types are useful in a MANET, and how to establish the 152 metrics to associate with a given link. While this issue is not only 153 related to this extension, the ability for an OLSRv2 network to 154 maintain different concurrent link metrics may facilitate both 155 experiments with different link metric types, ways to measure them, 156 etc. and may also allow experimentation with link metric types that 157 are not compromises to handle multiple traffic types. 159 2. Terminology and Notation 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 [RFC2119]. 166 This specification uses the terminology of [RFC5444], [RFC6130] and 167 [RFC7181], which is to be interpreted as described in those 168 specifications. 170 Additionally, this specification uses the following terminology: 172 Router - A MANET router that implements [RFC7181]. 174 MT-OLSRv2 - The protocol defined in this specification as an 175 extension to [RFC7181]. 177 This specification introduces the notation map[A -> B] to represent 178 an associative mapping. The domain of this mapping (A) is, in this 179 specification, always a set of link metric types that the router 180 supports: either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as 181 defined in Section 5. The codomain of this mapping (B) is a set of 182 all possible values of an appropriate type, in this specification 183 this type is always one of: 185 o boolean (true or false), 187 o willingness (a 4 bit unsigned integer from 0 to 15); 189 o number of hops (an 8 bit unsigned integer from 0 to 255), or 191 o link metric (either a representable link metric value, as 192 described in [RFC7181], or UNKNOWN_METRIC). 194 3. Applicability Statement 196 The protocol described in this specification is applicable to a MANET 197 for which OLSRv2 is otherwise applicable (see [RFC7181], Section 3), 198 but in which multiple topologies are maintained, each characterized 199 by a different choice of link metric type. It is assumed, but 200 outside the scope of this specification, that the network layer is 201 able to choose which topology to use for each packet, for example 202 using the DiffServ Code Point (DSCP) defined in [RFC2474]. This 203 selection of topology must be consistent, that is each router 204 receiving a packet must make the same choice of link metric type, in 205 order that each packet uses a single topology. This is necessary to 206 avoid the possibility of a packet "looping" in the network. 208 4. Protocol Overview and Functioning 210 The purpose of this specification is to extend [RFC7181] so as to 211 enable a router to establish and maintain multiple routing topologies 212 in a MANET, each topology associated with a link metric type. 213 Routers in the MANET may each form part of some or all of these 214 topologies, and each router will maintain a Routing Set for each 215 topology that it forms part of, allowing separate routing of packets 216 for each topology. 218 Each router implementing this specification selects a set of link 219 metric types for each of its OLSRv2 interfaces. If all routers in 220 the MANET implement MT-OLSRv2, then there are no restrictions on how 221 these sets of link metrics are selected. However there may be 222 deployments where routers that do not implement MT-OLSRv2 (non-MT- 223 OLSRv2 routers) are to participate in a MANET with MT-OLSRv2 routers. 224 In this case, the single link metric used by these non-MT-OLSRv2 225 routers must be included in the set of link metrics for each OLSRv2 226 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 227 interface of a non-MT-OLSRv2 router in the MANET. 229 Each router then determines an incoming link metric for each link 230 metric type selected for each of its OLSRv2 interfaces. These link 231 metrics are distributed using link metric TLVs contained in all HELLO 232 messages sent on OLSRv2 interfaces, and in all TC messages. Both 233 HELLO and TC messages generated by an MT-OLSRv2 router (other than 234 one using only the single metric type used by non-MT-OLSRv2 routers) 235 include an MPR_TYPES Message TLV that indicates that this is an MT- 236 OLSRv2 router and which metric types it supports (on the sending 237 OLSRv2 interface for a HELLO message). 239 In addition to link and neighbor metric values for each link metric 240 type, router MPR (multipoint relay) and MPR selector status, and 241 advertised neighbor status, is maintained per supported neighbor 242 metric type, for each symmetric 1-hop neighbor. Each router may 243 choose a different willingness to be a routing MPR for each link 244 metric type that it supports. 246 A network using MT-OLSRv2 will usually require greater management 247 than one using unmodified OLSRv2. In particular, the use of multiple 248 metric types across the MANET must be managed, by administrative 249 configuration or otherwise. As also for other decisions that may be 250 made when using OLSRv2, a bad collective choice of metric type use 251 will make the MANET anywhere from inefficient to non-functional, so 252 care will be needed in selecting supported link metric types across 253 the MANET. 255 5. Parameters 257 The parameters used in [RFC7181], including from its normative 258 references, are used in this specification with the following 259 changes. 261 Each OLSRv2 interface will support a number of link metric types, 262 corresponding to Type Extensions of the LINK_METRIC TLV defined in 263 [RFC7181]. The router parameter LINK_METRIC_TYPE, used by routers 264 that do not implement MT-OLSRv2, and used with that definition in 265 this specification, is replaced in routers implementing MT-OLSRv2 by 266 an interface parameter array IFACE_METRIC_TYPES and a router 267 parameter array ROUTER_METRIC_TYPES. Each element in these arrays is 268 a link metric type (i.e., a type extension used by the LINK_METRIC 269 TLV [RFC7181]). 271 The interface parameter array IFACE_METRIC_TYPES contains the link 272 metric types supported on that OLSRv2 interface. The router 273 parameter array ROUTER_METRIC_TYPES is the union of all of the 274 IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. 276 If in a given deployment there may be any routers that do not 277 implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST first include 278 LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate 279 with any routers that do not implement MT-OLSRv2. In that case, 280 ROUTER_METRIC_TYPES MUST also first include LINK_METRIC_TYPE. 282 In addition, the router parameter WILL_ROUTING is extended to an 283 array of values, one each for each link metric type in the router 284 parameter list ROUTER_METRIC_TYPES. 286 6. Information Bases 288 The Information Bases specified in [RFC7181], which extend those 289 specified in in [RFC6130], are further extended in this 290 specification. With the exception of the Routing Set, the extensions 291 in this specification are the replacement of single values (boolean, 292 willingness, number of hops, or link metric) from [RFC7181] with 293 elements representing multiple values (associative mappings from a 294 set of metric types to their corresponding values). The following 295 subsections detail these extensions. 297 Note that, as in [RFC7181], an implementation is free to organize its 298 internal data in any manner it chooses, it needs only to behave as if 299 it were organized as described in [RFC7181] and this specification. 301 6.1. Local Attached Network Set 303 Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of 304 hops]. 306 Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link 307 metric]. 309 6.2. Link Sets 311 Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link 312 metric]. 314 Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link 315 metric]. 317 The elements of L_in_metric MUST be set following the same rules that 318 apply to the setting of the single element L_in_metric in [RFC7181]. 320 6.3. 2-Hop Sets 322 Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 323 metric]. 325 Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 326 metric]. 328 6.4. Neighbor Set 330 Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link 331 metric]. 333 Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link 334 metric]. 336 Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> 337 willingness]. 339 Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> 340 boolean]. 342 Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> 343 boolean]. 345 Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> 346 boolean]. 348 6.5. Router Topology Set 350 Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link 351 metric]. 353 Note that some values of TR_metric may now take the value 354 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 355 corresponding link metric value from this mapping is used, Router 356 Topology Tuples whose corresponding value from TR_metric is 357 UNKNOWN_METRIC are ignored. 359 6.6. Routable Address Topology Set 361 Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link 362 metric]. 364 Note that some values of TA_metric may now take the value 365 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 366 corresponding link metric value from this mapping is used, Routable 367 Address Topology Tuples whose corresponding value from TA_metric is 368 UNKNOWN_METRIC are ignored. 370 6.7. Attached Network Set 372 Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of 373 hops]. 375 Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link 376 metric]. 378 Note that some values of AN_metric may now take the value 379 UNKNOWN_METRIC. When used to construct a Routing Set, where just the 380 corresponding link metric value from this mapping is used, Attached 381 Network Tuples whose corresponding value from AN_metric is 382 UNKNOWN_METRIC are ignored. 384 6.8. Routing Sets 386 There is a separate Routing Set for each link metric type in 387 ROUTER_METRIC_TYPES. 389 7. TLVs 391 This specification makes the following additions and extensions to 392 the TLVs defined in [RFC7181]. 394 7.1. Message TLVs 396 One new Message TLV is defined in this specification, and one 397 existing Message TLV is extended by this specification. 399 7.1.1. MPR_TYPES TLV 401 The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 402 interfaces and TC messages. A message MUST NOT contain more than one 403 MPR_TYPES TLV. 405 The presence of this TLV in a message is used to indicate that the 406 router supports MT-OLSRv2, in the same way that the presence of the 407 MPR_WILLING TLV is used to indicate that the router supports OLSRv2, 408 as specified in [RFC7181]. For this reason, the MPR_TYPES TLV has 409 been defined with the same Type as the MPR_WILLING TLV, but with Type 410 Extension = 1. 412 This TLV may take a Value field of any size. Each octet in its Value 413 field will contain a link metric type that is supported, either on 414 any OLSRv2 interface, when included in a TC message, or on the OLSRv2 415 interface on which an including HELLO message is sent. These octets 416 MAY be in any order, except that if there may be any routers in the 417 MANET not implementing MT-OLSRv2, then the first octet MUST be 418 LINK_METRIC_TYPE. 420 7.1.2. MPR_WILLING TLV 422 The MPR_WILLING TLV, which is used in HELLO messages, is specified in 423 [RFC7181], and extended in this specification as enabled by 424 [RFC7188]. 426 The interpretation of this TLV, specified by [RFC7181], and which 427 uses all of its single octet Value field, is unchanged. That 428 interpretation uses bits 0-3 of its Value field to specify its 429 willingness to be a flooding TLV, and bits 4-7 of its Value field to 430 be a routing TLV. Those latter bits are, when using this 431 specification, interpreted as its willingness to be a routing TLV 432 using the link metric type LINK_METRIC_TYPE. 434 The extended use of this message TLV, as defined by this 435 specification, defines additional 4 bit sub-fields of the Value 436 field, starting with bits 4-7 of the first octet and continuing with 437 bits 0-3 of the second octet, to represent willingness to be a 438 routing MPR using the link metric types specified in this OLSRv2 439 interface's IFACE_METRIC_TYPES parameter, ordered as reported in the 440 included MPR_TYPES Message TLV. Note that this means that the 441 willingness to be a routing MPR for the topology indicated by 442 the link metric type LINK_METRIC_TYPE will continue to occupy bits 443 4-7 of the first octet. (If there is no such TLV included, then the 444 router does not support MT-OLSRv2, and only the first octet of the 445 Value field will be used.) 447 If the number of link metric types in this OLSRv2 interface's 448 IFACE_METRIC_TYPES parameter is even, then there will be an unused 4 449 bit sub-field in bits 4-7 of the last octet of a full sized Value 450 field. These bits will not be used, they SHOULD all be cleared 451 ('0'). 453 If the Value field in an MPR_WILLING TLV is shorter than its full 454 length, then, as specified in [RFC7188], missing Value octets, i.e., 455 missing willingness values, are considered as zero, i.e., as 456 WILL_NEVER. This is the correct behavior. (In particular it means 457 that an OLSRv2 router that is not implementing MT-OLSRv2 will not act 458 as a routing MPR for any link metric that it does not recognize.) 460 7.2. Address Block TLVs 462 New Type Extensions are defined for the LINK_METRIC TLV defined in 463 [RFC7181], and the Value fields of the MPR TLV and the GATEWAY TLV, 464 both defined in [RFC7181], are extended, as enabled by [RFC7188]. 466 7.2.1. LINK_METRIC TLV 468 The LINK_METRIC TLV is used in HELLO messages and TC messages. This 469 TLV is unchanged from the definition in [RFC7181]. 471 Only a single Type Extension was specified by [RFC7181] (link metric 472 type) 0 as defined by administrative action. This specification 473 extends this range to 0-7. This specification will work with any 474 combination of Type Extensions both within and without that range 475 (assuming that the latter are defined as specified in [RFC7181]). 477 7.2.2. MPR TLV 479 The MPR TLV is used in HELLO messages, and indicates that an address 480 with which it is associated is of a symmetric 1-hop neighbor that has 481 been selected as an MPR. 483 The Value field of this address block TLV is, in [RFC7181], defined 484 to be one octet long, with the values 1, 2 and 3 defined. [RFC7188] 485 redefines this Value field to be a bitfield where bit 7 (the lsb) 486 denotes flooding status, bit 6 denotes routing MPR status, and bits 487 5-0 are unallocated (respecting the semantics of the bits/values 1, 2 488 and 3 from [RFC7181]). 490 This specification, as enabled by [RFC7188], extends the MPR TLV to 491 have a variable-length Value field. For interoperability with a 492 router not implementing MT-OLSRv2, the two least significant bits of 493 the first octet in the Value field of this TLV MUST be the TLV Value 494 of the MPR TLV, generated according to [RFC7181]. 496 Subsequent bits (in increasing significance within an octet, then 497 continuing with the least significant bit in the next octet, if 498 required) in the TLV Value field indicate which link metric types, 499 for which the corresponding address is selected as a routing MPR, 500 link metric types (including the first) being indicated in, and used 501 in the same order as, the Value field of an MPR_TYPES Message TLV, 502 excluding the link metric type LINK_METRIC_TYPE, which already 503 occupies the second bit. 505 7.2.3. GATEWAY TLV 507 The GATEWAY TLV is used in TC messages to indicate that a network 508 address is of an attached network. 510 The Value field of this address block TLV is, in [RFC7181] defined to 511 be one octet long, containing the number of hops to that attached 512 network. 514 This specification, as enabled by [RFC7181], allows the extension the 515 GATEWAY TLV to have a variable-length Value field when the number of 516 hops to each attached network is different for different link metric 517 types. For interoperability with a router not implementing MT- 518 OLSRv2, the first octet in the Value field of this TLV MUST be the 519 TLV Value of the GATEWAY TLV generated according to [RFC7181]. 521 Any subsequent octets in the TLV Value field indicate the number of 522 hops to the attached network for each other link metric type, link 523 metric types (including the first) being indicated in the Value field 524 of an MPR_TYPES Message TLV. 526 +---------+---------------------------------------------------------+ 527 | Type | Value | 528 +---------+---------------------------------------------------------+ 529 | GATEWAY | Number of hops to attached network for each link metric | 530 | | type. | 531 +---------+---------------------------------------------------------+ 533 Table 1: GATEWAY TLV definition 535 8. HELLO Messages 537 The following changes are made to the generation and processing of 538 HELLO messages compared to that described in [RFC7181] by routers 539 that implement MT-OLSRv2. 541 8.1. HELLO Message Generation 543 A generated HELLO message to be sent on an OLSRv2 interface (whose 544 IFACE_METRIC_TYPES parameter will be that used) is extended by: 546 o Adding an MPR_TYPES Message TLV. The Value octets will be the 547 link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted 548 if the only link metric type included would be LINK_METRIC_TYPE. 550 o Extending the MPR_WILLING Message TLV Value field to report the 551 willingness values from the WILL_ROUTING parameter list that 552 correspond to the link metric types in IFACE_METRIC_LIST, in the 553 same order as reported in the MPR_TYPES TLV, each value (also 554 including one representing WILL_FLOODING) occupying 4 bits. 556 o Including LINK_METRIC Address Block TLVs that report all values in 557 L_in_metric, L_out_metric, N_in_metric and N_out_metric elements 558 that are not equal to UNKNOWN_METRIC, with the TLV Type Extension 559 being the link metric type, and otherwise following the rules for 560 such inclusions specified in [RFC7181]. 562 o Including MPR Address Block TLVs such that for each link metric 563 type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, 564 the indicated addresses MUST be of the MPRs in an MPR set as 565 specified for a single link metric type in [RFC7181]. 567 8.2. HELLO Message Processing 569 On receipt of a HELLO message on an OLSRv2 interface, a router 570 implementing MT-OLSRv2 MUST, in addition to the processing described 571 in [RFC7181]: 573 1. Determine the list of link metric types supported by the sending 574 router on its corresponding OLSRv2 interface, either from an 575 MPR_TYPES Message TLV or, if not present, the single link metric 576 type LINK_METRIC_TYPE. 578 2. For those link metric types supported by both routers, set the 579 appropriate L_out_metric, N_in_metric, N_out_metric, 580 N_will_routing, N_mpr_selector, N_advertised, N2_in_metric and 581 N2_out_metric values as described for single such elements in 582 [RFC7181]. 584 3. For any other metric types supported by the receiving router only 585 (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set 586 the elements listed in the previous point to their default 587 values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or 588 false. 590 9. TC Messages 592 The following changes are made to the generation and processing of TC 593 messages compared to that described in [RFC7181] by routers that 594 implement MT-OLSRv2. 596 9.1. TC Message Generation 598 A generated TC message is extended by: 600 o Adding an MPR_TYPES TLV. The value octets will be the link metric 601 types in ROUTER_METRIC_TYPES. This MAY be omitted if the only 602 link metric type included would be LINK_METRIC_TYPE. 604 o Including LINK_METRIC TLVs that report all values of N_out_metric 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 When not all the same, including a number of hops per reported (in 610 an MPR_TYPES Message TLV) link metric type in the Value field of 611 each GATEWAY TLV included, in the same order as reported in the 612 MPR_TYPES TLV. 614 9.2. TC Message Processing 616 On receipt of a TC message, a router implementing this extension 617 MUST, in addition to the processing specified in [RFC7181]: 619 o Set the appropriate TR_metric, TA_metric, AN_dist and AN_metric 620 elements using the rules for setting the single elements of those 621 types specified in [RFC7181]. 623 o For any other metric types supported by the receiving router that 624 do not have an advertised outgoing neighbor metric of that type, 625 set the corresponding elements of TR_metric, TA_metric and 626 AN_metric to UNKNOWN_METRIC. (The corresponding element of 627 AN_dist may be set to any value.) 629 10. MPR Calculation 631 Routing MPRs are calculated for each link metric type in 632 ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 633 interfaces that do not support that link metric type are not 634 considered. The determined status (routing MPR or not routing MPR) 635 for each link metric type is recorded in the relevant element of 636 N_routing_mpr. 638 Each router may make its own decision as to whether or not to use a 639 link metric, or link metrics, for flooding MPR calculation, and if so 640 which and how. This decision MUST be made in a manner that ensures 641 that flooded messages will reach the same symmetric 2-hop neighbors 642 as would be the case for a router not supporting MT-OLSRv2. 644 Note that it is possible that a 2-Hop Tuple in the Information Base 645 for a given OLSRv2 interface does not support any of the link metric 646 types that are in the router's corresponding IFACE_METRIC_TYPES, but 647 nevertheless that 2-Hop Tuple MUST be considered when determining 648 flooding MPRs. 650 11. Routing Set Calculation 652 A Routing Set is calculated for each link metric type in 653 ROUTER_METRIC_TYPES. The calculation may be as for [RFC7181], except 654 that where an element is now represented by a map, the value from the 655 map for the selected link metric type is used. Where this is a link 656 metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for 657 the calculation. 659 12. Management Considerations 661 MT-OLSRv2 may require greater management than unextended OLSRv2. In 662 particular MT-OLSRv2 requires the following management 663 considerations: 665 o Selecting which link metrics to support on each OLSRv2 interface 666 and implementing that decision. (Different interfaces may have 667 different physical and data link layer properties, and this may 668 inform the selection of link metrics to support, and their 669 values.) 671 o Ensuring that the MANET is sufficiently connected. Note that if 672 there is any possibility that there are any routers not 673 implementing MT-OLSRv2, then the MANET will be connected, to the 674 maximum extent possible, using the link metric type 675 LINK_METRIC_TYPE. 677 o Deciding which link metric, and hence which Routing Set to use, 678 for received packets, hence how to use the Routing Sets to 679 configure the network layer (IP). All routers must make the same 680 decision for the same packet. An obvious approach is to map each 681 DiffServ Code Point (DSCP) [RFC2474] to a single link metric. 682 (This may be a many to one mapping.) 684 o Note that there could be cases where a router that is not 685 implementing MT-OLSRv2 is the source or destination of an IP 686 packet that is mapped to a link metric that is not the link metric 687 LINK_METRIC_TYPE used by that router. 689 * If such a router is the source, then routing may work if the 690 first router implementing MT-OLSRv2 to receive the packet 691 supports the appropriate link metric type. At worst the packet 692 will be dropped, it will not loop. 694 * If such a router is the destination, then the packet will never 695 reach its destination, as the source will not have a suitable 696 routing table entry for the destination. Network management 697 may be required to ensure that the MANET still functions in 698 these cases. 700 13. IANA Considerations 702 This specification adds one new Message TLV, allocated as a new Type 703 Extension to an existing Message TLV, using a new name. It also 704 modifies the Value field of an existing Message TLV, and of an 705 existing Address Block TLV. Finally, this specification makes 706 additional allocations from the LINK_METRIC Address Block TLV Type 707 registry. 709 This specification assumes that the TLV renaming specified in 710 [tlv-naming] has been carried out. 712 13.1. Expert Review: Evaluation Guidelines 714 For the registry where an Expert Review is required, the designated 715 expert SHOULD take the same general recommendations into 716 consideration as are specified by [RFC5444] and [tlv-naming]. 718 13.2. Message TLV Types 720 This specification modifies the Message TLV Type 7, replacing Table 4 721 of [tlv-naming] by Table 2, changing the description of the Type 722 Extension MPR_WILLING and adding the Type Extension TLV_TYPES. Each 723 of these TLVs MUST NOT be included more than once in a Message TLV 724 Block. 726 +-----------+-------------+-------------------------+---------------+ 727 | Type | Name | Description | Reference | 728 | Extension | | | | 729 +-----------+-------------+-------------------------+---------------+ 730 | 0 | MPR_WILLING | First (most | [RFC7181] | 731 | | | significant) half octet | [tlv-naming] | 732 | | | of Value field | This | 733 | | | specifies the | specification | 734 | | | originating router's | | 735 | | | willingness to act as a | | 736 | | | flooding MPR; | | 737 | | | subsequent half octets | | 738 | | | specify the originating | | 739 | | | router's willingness to | | 740 | | | act as a routing MPR, | | 741 | | | either for the link | | 742 | | | metric types reported | | 743 | | | in an MPR_TYPES TLV (in | | 744 | | | the same order), or (if | | 745 | | | no MPR_TYPES TLV is | | 746 | | | present) for the single | | 747 | | | administratively agreed | | 748 | | | link metric type | | 749 | 1 | MPR_TYPES | The link metric types | This | 750 | | | supported on this | specification | 751 | | | OLSRv2 interface of | | 752 | | | this router (one octet | | 753 | | | each). | | 754 | 2-223 | | Unassigned | | 755 | 224-255 | | Reserved for | [RFC7181] | 756 | | | Experimental Use | | 757 +-----------+-------------+-------------------------+---------------+ 759 Table 2: Type 7 Message TLV Type Extensions 761 13.3. Address Block TLV Types 763 Table 7 of [RFC7188] is replaced by Table 3. 765 +-------+-------+----------+----------------------------------------+ 766 | Bit | Value | Name | Description | 767 +-------+-------+----------+----------------------------------------+ 768 | First | First | Flooding | If set then the neighbor with that | 769 | octet | octet | | network address has been selected as | 770 | bit 7 | 0x01 | | flooding MPR | 771 | From | From | Routing | If set then the neighbor with that | 772 | first | first | | network address has been selected as | 773 | octet | octet | | routing MPR, either for the link | 774 | bit 6 | 0x02 | | metric types reported in an MPR_TYPES | 775 | | | | TLV (in the same order), or (if no | 776 | | | | MPR_TYPES TLV is present) then (first | 777 | | | | octet bit 6, value 0x02) for the | 778 | | | | single administratively agreed link | 779 | | | | metric type | 780 +-------+-------+----------+----------------------------------------+ 782 Table 3: MPR TLV Bit Values 784 Table 14 of [tlv-naming] is replaced by Table 4. The only changes 785 are to the Description and the References for the GATEWAY TLV. 787 +-----------+---------+-----------------------------+---------------+ 788 | Type | Name | Description | References | 789 | Extension | | | | 790 +-----------+---------+-----------------------------+---------------+ 791 | 0 | GATEWAY | Specifies that a given | [RFC7181] | 792 | | | network address is reached | This | 793 | | | via a gateway on the | specification | 794 | | | originating router. The | | 795 | | | number of hops is indicated | | 796 | | | by the Value field, one | | 797 | | | octet per link metric type | | 798 | | | reported in an MPR_TYPES | | 799 | | | Message TLV (in the same | | 800 | | | order) or (if no MPR_TYPES | | 801 | | | Message TLV is present) | | 802 | | | using a single octet | | 803 | 1-223 | | Unassigned | | 804 | 224-255 | | Reserved for Experimental | [tlv-naming] | 805 | | | Use | | 806 +-----------+---------+-----------------------------+---------------+ 808 Table 4: Type 10 Address Block TLV Type Extensions 810 Table 13 of [RFC7181] is replaced by Table 5. The only change is to 811 allocate 8 Type Extensions as assigned by administrative action, in 812 order to support administratively determined multi-topologies. 814 +-------------+------+-----------+-------------------+--------------+ 815 | Name | Type | Type | Description | Allocation | 816 | | | Extension | | Policy | 817 +-------------+------+-----------+-------------------+--------------+ 818 | LINK_METRIC | 7 | 0-7 | Link metric | | 819 | | | | meaning assigned | | 820 | | | | by administrative | | 821 | | | | action. | | 822 | LINK_METRIC | 7 | 8-223 | Unassigned. | Expert | 823 | | | | | Review | 824 | LINK_METRIC | 7 | 224-255 | Unassigned. | Experimental | 825 | | | | | Use | 826 +-------------+------+-----------+-------------------+--------------+ 828 Table 5: Address Block TLV Type assignment: LINK_METRIC 830 14. Security Considerations 832 This extension to OLSRv2 allows a router to support more than one 833 link metric type for each link advertised in HELLO and TC messages, 834 and for routers to support different sets of types. Link metric 835 values of additional types are reported by the inclusion of 836 additional TLVs in the messages sent by a router, which will report 837 known values of all supported types. 839 HELLO and TC message processing is then extended simply to record, 840 for each supported type, all of the received link metric values for 841 each link. Protocol internal processing (specifically MPR set and 842 shortest path calculations) then operate as specified in [RFC7181] 843 for each link metric type that the router supports. 845 Consequently the security considerations, including the security 846 architecture and the mandatory security mechanisms, from [RFC7181] 847 are directly applicable to MT-OLSRv2. 849 Furthermore, this extension does not introduce any additional 850 vulnerabilities over those of [RFC7181], because each link metric 851 type is used independently, and each one could have been the single 852 link metric type supported by an implementation of [RFC7181] 853 receiving the same information, as received information of an 854 unsupported type is ignored by all routers. 856 15. Acknowledgments 858 The authors would like to thank (in alphabetical order): Juliusz 859 Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems) 860 and Henning Rogge (FGAN) for discussions and suggestions. 862 16. References 864 16.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 870 "Generalized MANET Packet/Message Format", RFC 5444, 871 February 2009. 873 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 874 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 875 RFC 6130, April 2011. 877 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 878 "The Optimized Link State Routing Protocol version 2", 879 RFC 7181, April 2014. 881 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 882 Protocol version 2 (OLSRv2) and MANET Neighborhood 883 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 884 April 2014. 886 [tlv-naming] 887 Dearlove, C. and T. Clausen, "TLV Naming in the MANET 888 Generalized Packet/Message Format", Work In 889 Progress draft-ietf-manet-tlv-naming-00.txt, January 2015. 891 16.2. Informative References 893 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 894 "Definition of the Differentiated Services Field (DS 895 Field) in the IPv4 and IPv6 Headers", RFC 2474, 896 December 1998. 898 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 899 (MANET): Routing Protocol Performance Issues and 900 Evaluation Considerations", RFC 2501, January 1999. 902 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 903 Routing Protocol", RFC 3626, October 2003. 905 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 906 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 907 RFC 4915, June 2007. 909 Authors' Addresses 911 Christopher Dearlove 912 BAE Systems Advanced Technology Centre 913 West Hanningfield Road 914 Great Baddow, Chelmsford 915 United Kingdom 917 Phone: +44 1245 242194 918 Email: chris.dearlove@baesystems.com 919 URI: http://www.baesystems.com/ 921 Thomas Heide Clausen 922 LIX, Ecole Polytechnique 924 Phone: +33 6 6058 9349 925 Email: T.Clausen@computer.org 926 URI: http://www.ThomasClausen.org/