Mobile Ad hoc Networking (MANET) C. Dearlove Internet-Draft BAE Systems ATC Intended status: Experimental T. Clausen Expires: January 13, 2014 LIX, Ecole Polytechnique July 12, 2013 Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) draft-dearlove-manet-olsrv2-multitopology-01 Abstract This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 13, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Dearlove & Clausen Expires January 13, 2014 [Page 1] Internet-Draft Multi-Topology OLSRv2 July 2013 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Local Attached Network Set . . . . . . . . . . . . . . . . 5 6.2. Link Sets . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3. 2-Hop Sets . . . . . . . . . . . . . . . . . . . . . . . . 6 6.4. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 6 6.5. Router Topology Set . . . . . . . . . . . . . . . . . . . 6 6.6. Routable Address Topology Set . . . . . . . . . . . . . . 7 6.7. Attached Network Set . . . . . . . . . . . . . . . . . . . 7 6.8. Routing Sets . . . . . . . . . . . . . . . . . . . . . . . 7 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 7 7.1.1. MPR_TYPES TLV . . . . . . . . . . . . . . . . . . . . 7 7.2. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 8 7.2.1. LINK_METRIC TLV . . . . . . . . . . . . . . . . . . . 8 7.2.2. MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 8 8. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 9 8.2. HELLO Message Processing . . . . . . . . . . . . . . . . . 10 9. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. TC Message Generation . . . . . . . . . . . . . . . . . . 10 9.2. TC Message Processing . . . . . . . . . . . . . . . . . . 11 10. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . . 11 11. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 11 12. Management Considerations . . . . . . . . . . . . . . . . . . 12 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 16.1. Normative References . . . . . . . . . . . . . . . . . . . 13 16.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Dearlove & Clausen Expires January 13, 2014 [Page 2] Internet-Draft Multi-Topology OLSRv2 July 2013 1. Introduction The Optimized Link State Routing Protocol, version 2 [OLSRv2] is a proactive link state routing protocol designed for use in mobile ad hoc networks (MANETs) [RFC2501]. One of the significant improvements of OLSRv2 over its Experimental precursor [RFC3626] is the ability of OLSRv2 to route over other than minimum hop routes, using a link metric. A limitation that remains in OLSRv2 is that it uses a single link metric type for all routes. However in some MANETs it would be desirable to be able to use alternative metrics for different packet routing. This specification describes an extension to OLSRv2, that is designed to permit this, while maintaining maximal interoperability with OLSRv2 routers not implementing this extension. The purpose of OLSRv2 can be described as to create and maintain a Routing Set, which contains all the necessary information to populate an IP routing table. In a similar way, the role of this extension can be described as to create and maintain multiple Routing Sets, one for each link metric type supported by the router maintaining the sets. 2. Terminology and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This specification uses the terminology of [RFC5444], [RFC6130] and [OLSRv2], which is to be interpreted as described in these specifications. Additionally, this specification uses the following terminology: Router - A MANET router that implements [OLSRv2]. MT-OLSRv2 - The protocol defined in this specification as an extension to [OLSRv2]. This specification introduces the notation map[range -> type] to represent an associative map from elements of the range, which in this specification is always a set of link metric types that the router supports (either IFACE_METRIC_TYPES or ROUTER_METRIC_TYPES, as defined in Section 5), to a type, which in this specification is always either boolean or metric-value (either a representable link Dearlove & Clausen Expires January 13, 2014 [Page 3] Internet-Draft Multi-Topology OLSRv2 July 2013 metric value, as described in [OLSRv2], or UNKNOWN_METRIC). 3. Applicability Statement The protocol described in this specification is applicable to a MANET for which OLSRv2 is otherwise applicable (see [OLSRv2]), but in which multiple topologies are maintained, each characterized by a different choice of link metric type. It is assumed, but outside the scope of this specification, that the network layer is able to choose which topology to use for each packet, for example using the DiffServ Code Point (DSCP) defined in [RFC2474]. 4. Protocol Overview and Functioning The purpose of this specification is to extend [OLSRv2] so as to enable a router to establish and maintain multiple routing topologies in a MANET, each topology associated with a link metric type. Routers in the MANET may each form part of some or all of these topologies, and each router will maintain a Routing Set for each topology that it forms part of, allowing separate routing of packets for each topology. Each router implementing this specification selects a set of link metric types for each OLSRv2 interface. If there may be any routers in the MANET that implement OLSRv2, but not OLSRv2-MT, then the link metric used by such routers must be included in those selected on all OLSRv2 interfaces that may be able to communicate with any routers that do not implement MT-OLSRv2. Otherwise routers may make independent selections. Each router then determines an incoming link metric for each link metric type selected for each OLSRv2 interface. These link metrics are distributed using link metric TLVs contained in all HELLO messages sent on OLSRv2 interfaces, and all TC messages. In addition to link and neighbor metric values for each link metric type, router MPR (multipoint relay) and MPR selector status, and advertised neighbor status, is maintained per supported neighbor metric type for each symmetric 1-hop neighbor. More so than OLSRv2, the use of multiple metric types across the MANET must be managed, by administrative configuration or otherwise. Similarly to other decisions that may be made using OLSRv2, a bad collective choice will make the MANET anywhere from inefficient to non-functional, so care will be needed in selecting supported link metric types across the MANET. Dearlove & Clausen Expires January 13, 2014 [Page 4] Internet-Draft Multi-Topology OLSRv2 July 2013 5. Parameters The parameters used in [OLSRv2], including from its normative references, are used in this specification with a single change. Each OLSRv2 interface will support a number of link metric types, corresponding to type extensions of the LINK_METRIC TLV defined in [OLSRv2]. The router parameter LINK_METRIC_TYPE, used by routers that do not implement MT-OLSRv2, and with that definition in this specification, is replaced in routers implementing MT-OLSRv2 by an interface parameter array IFACE_METRIC_TYPES and a router parameter array ROUTER_METRIC_TYPES. Each element in these arrays is a link metric type (i.e., a type extension used by the LINK_METRIC TLV [OLSRv2]). The interface parameter array IFACE_METRIC_TYPES contains the link metric types supported on that OLSRv2 interface. The router parameter array ROUTER_METRIC_TYPES is the union of all of the IFACE_METRIC_TYPES. Both arrays MUST be without repetitions. If in a given deployment there may be any routers that do not implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE if that OLSRv2 interface may be able to communicate with any routers that do not implement MT-OLSRv2. In that case, ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE. 6. Information Bases The Information Bases specified in [OLSRv2], which extend those specified in in [RFC6130], are used and extended in this specification. With the exception of the Routing Set, the extensions in this specification are the replacement of single values (boolean or link-metric) from [OLSRv2] with elements representing multiple values (associative maps from a set of metric types to their corresponding values). The following subsections detail these extensions. Note that, as in [OLSRv2], an implementation is free to organize its internal data in any manner it chooses, it needs only to behave as if it were organized as described in [OLSRv2] and this specification. 6.1. Local Attached Network Set Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link- metric]. Dearlove & Clausen Expires January 13, 2014 [Page 5] Internet-Draft Multi-Topology OLSRv2 July 2013 6.2. Link Sets Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link- metric]. Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link- metric]. The elements of L_in_metric MUST be set following the same rules that apply to the setting of the single element L_in_metric in [OLSRv2]. 6.3. 2-Hop Sets Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link- metric]. Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link- metric]. 6.4. Neighbor Set Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link- metric]. Each element N_out_metric becomes a map[ROUTER_METRIC_TYPES -> link- metric]. Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> boolean]. Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> boolean]. Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> boolean]. 6.5. Router Topology Set Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link- metric]. Note that some values of TR_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding value from this map is used, Router Topology Tuples whose corresponding value of TR_metric is UNKNOWN_METRIC are ignored. Dearlove & Clausen Expires January 13, 2014 [Page 6] Internet-Draft Multi-Topology OLSRv2 July 2013 6.6. Routable Address Topology Set Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link- metric]. Note that some values of TA_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding value from this map is used, Routable Address Topology Tuples whose corresponding value of TA_metric is UNKNOWN_METRIC are ignored. 6.7. Attached Network Set Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link- metric]. Note that some values of AN_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding value from this map is used, Attached Network Tuples whose corresponding value of AN_metric is UNKNOWN_METRIC are ignored. 6.8. Routing Sets There is a separate Routing Set for each link metric type in ROUTER_METRIC_TYPES. 7. TLVs This specification makes the following additions and extensions to the TLVs defined in [OLSRv2]. 7.1. Message TLVs A single new Message TLV is defined in this specification. 7.1.1. MPR_TYPES TLV A new allocation is made for an MPR_TYPES Message TLV. The presence of this TLV is used to indicate that the router supports MT-OLSRv2, in the same way that the presence of the MPR_WILLING TLV is used to indicate that the router supports OLSRv2, as specified in [OLSRv2]. For this reason, the MPR_TYPES TLV has been defined with the same Type as the MPR_WILLING TLV, but with Type Extension == 1. (The different symbolic name is used for convenience, any reference to a MPR_TYPES TLV means to this TLV, with this Type and Type Extension.) This TLV may take a value field of any size. Each octet in its value Dearlove & Clausen Expires January 13, 2014 [Page 7] Internet-Draft Multi-Topology OLSRv2 July 2013 field will contain a link metric type. These octets MAY be in any order, except that if there may be any routers in the MANET using not implementing the extension described in this specification, then the first octet MUST be LINK_METRIC_TYPE. 7.2. Address Block TLVs New Type Extensions are defined for the LINK_METRIC TLV defined in [OLSRv2]. Some adjustment may be required to the MPR TLV defined in [OLSRv2]. Two options are presented in section Section 7.2.2.1 of this version of this specification; the final version of this specification will pick one. 7.2.1. LINK_METRIC TLV This is unchanged from the definition in [OLSRv2]. However that specification defined a single type extension (link metric type) 0 as defined by administrative action. This specification extends this range, it is suggested either to 0-7 or to 0-15. This specification will work with any combination of type extensions both within and without that range (assuming that the latter are defined as specified in [OLSRv2]). 7.2.2. MPR TLV The value field of this Address Block TLV has the values 1, 2, and 3 specified in [OLSRv2], where 3 denotes both 1 and 2. [TLV-Extensions] redefines this field as a bitfield, where bit 7 (the lsb) denotes flooding status, bit 6 denotes routing MPR status, and bits 5-0 are unallocated (respecting the semantics of the bits/values 1, 2 and 3 from [OLSRv2]). Extending on this, bits 0-6 could be interpreted to denote routing MPR status for up to 7 link metric types. What these metric types are will be specified by the value field of an MPR_TYPES TLV, in the same order. There are however two problems with this approach: o A strict implementation of [OLSRv2] might reject any values other than 1, 2, or 3; the update proposed in [TLV-Extensions] resolves this, if adopted (and this specification is thus one motivation for [TLV-Extensions]). o Restricting the MPR TLV to have single octet values (as specified in [OLSRv2], and which a strict implementation of OLSRv2 might require) limits the number of link metric types that a router can handle to 7. This might be acceptable as a design choice. Alternatively the single value field of an MPR TLV may be allowed to be of variable size, of one or more octets. If adopted, this Dearlove & Clausen Expires January 13, 2014 [Page 8] Internet-Draft Multi-Topology OLSRv2 July 2013 modification to [OLSRv2] will be included in [TLV-Extensions]. 7.2.2.1. Options The following two options may thus be considered. Note that a single choice is to be made for the final specification. 1. An maximum of 7 link metric types used by any router, all carried in the MPR TLV with Type Extension 0, which is redefined accordingly but retaining a one octet single value length. This requires an OLSRv2 implementation (which does not include MT- OLSRv2) to consider only the first two bits of the value octet, as per [TLV-Extensions]. If [TLV-Extensions] is adopted, this option incurs no requirements on any existing OLSRv2 implementation. 2. An unlimited (up to 255) number of link metric types, all carried in the MPR TLV with Type Extension 0, which is redefined accordingly, but with a variable single value length. This requires an OLSRv2 implementation (which does not include MT- OLSRv2) to: * Consider only the first two bits of the value field, as per [TLV-Extensions]. If [TLV-Extensions] is adopted, this option incurs no requirements on any existing OLSRv2 implementation. * Accommodate a variable length single value field. Note that the adoption of [TLV-Extensions] makes option 1 immediately well-defined. Option 2 is not currently specifically addressed in [TLV-Extensions]. 8. HELLO Messages The following changes are made to the generation and processing of HELLO messages compared to that described in [OLSRv2] by routers that implement this extension. 8.1. HELLO Message Generation A generated HELLO message to be sent on an OLSRv2 interface is extended by: o Adding an MPR_TYPES TLV. The value octets will be the link metric types in IFACE_METRIC_TYPES. Dearlove & Clausen Expires January 13, 2014 [Page 9] Internet-Draft Multi-Topology OLSRv2 July 2013 o Including LINK_METRIC TLVs that report all values of L_in_metric, L_out_metric, N_in_metric and N_out_metric that are not equal to UNKNOWN_METRIC, with the TLV Type Extension being the link metric type, and otherwise following the rules for such inclusions specified in [OLSRv2]. o Including MPR TLVs such that for each link metric type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, these MUST cover at least one address of each 1-hop symmetric neighbor reported in the HELLO message, as described for a single link metric type in [OLSRv2]. 8.2. HELLO Message Processing On receipt of a HELLO message, a router implementing this extension MUST, in addition to the processing described in [OLSRv2]: 1. Determine the list of link metric types supported by the sending router on the relevant OLSRv2 interface, either from an MPR_TYPES TLV or, if not present, the type LINK_METRIC_TYPE supported by a router not implementing the extension described in this specification. 2. For those link metric types supported by both routers, set the appropriate L_out_metric, N_in_metric, N_out_metric, N_mpr_selector, N_advertised, N2_in_metric and N2_out_metric values as described for the single such elements in [OLSRv2]. 3. For any other metric types supported by the receiving router only, set those elements to their default value (UNKNOWN_METRIC or false). 9. TC Messages The following changes are made to the generation and processing of TC messages compared to that described in [OLSRv2] by routers that implement this extension. 9.1. TC Message Generation A generated TC message is extended by: o Including LINK_METRIC TLVs that report all values of N_out_metric that are not equal to UNKNOWN_METRIC, with the TLV Type Extension being the link metric type, and otherwise following the rules for such inclusions specified in [OLSRv2]. Dearlove & Clausen Expires January 13, 2014 [Page 10] Internet-Draft Multi-Topology OLSRv2 July 2013 9.2. TC Message Processing On receipt of a TC message, a router implementing this extension MUST, in addition to the processing specified in [OLSRv2]: o Set the appropriate TR_metric, TA_metric and AN_metric elements using the rules for setting the single elements of those types specified in [OLSRv2]. o For any other metric types supported by the receiving router that do not have an advertised outgoing neighbor metric of that type, set the corresponding elements of TR_metric, TA_metric and AN_metric to UNKNOWN_METRIC. 10. MPR Calculation Routing MPRs are calculated for each link metric type in ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 interfaces that does not support that link metric type are not considered. The determined status (routing MPR or not routing MPR) for each link metric type is recorded in the relevant element of N_routing_mpr. Each router may make its own decision as to whether or not to use a link metric, or link metrics, for flooding MPR calculation, and if so which and how. This decision MUST be made in a manner that ensures that flooded messages will reach the same symmetric 2-hop neighbors as would be the case for an OLSRv2 implementation, not including the extension described in this specification. Note that it is possible that a 2-Hop Tuple in the Information Base for a given OLSRv2 interface does not support any of the link metric types that are in the router's corresponding IFACE_METRIC_TYPES, but nevertheless that 2-Hop Tuple MUST be considered when determining flooding MPRs. 11. Routing Set Calculation A Routing Set is calculated for each supported link metric type. The calculation may be as for [OLSRv2], except that where an element is now represented by a map, the value from the map for the selected link metric type is used. Where this is a link metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for the calculation. Dearlove & Clausen Expires January 13, 2014 [Page 11] Internet-Draft Multi-Topology OLSRv2 July 2013 12. Management Considerations MT-OLSRv2 may require greater management than OLSRv2 without the extension described in this specification. In particular MT-OLSRv2 requires the following management considerations: o Selecting which link metrics to support on each OLSRv2 interface and implementing that decision. (Different interfaces may have different physical and data link layer properties, and this may inform the selection of link metrics to support, and their values.) o Ensuring that the MANET is sufficiently connected. Note that if there is any possibility that there are any routers not implementing the extension described in this specification, then the MANET will be connected, to the maximum extent possible, using the link metric type LINK_METRIC_TYPE. o Deciding which link metric, and hence which Routing Set to use, for received packets, hence how to use the Routing Sets to configure the network layer (IP). An obvious approach is to map each DiffServ Code Point (DSCP) [RFC2474] to a single link metric. (This may be a many to one mapping.) o Note that there could be cases where a router, not implementing the extension described in this specification, is the source or destination of an IP packet that is mapped to a link metric that is not the link metric LINK_METRIC_TYPE used by that router. If that router is the source, then routing may work if the first Multi-Topology OLSRv2 router to receive the packet supports the appropriate link metric type. At worst the packet will be dropped, it will not loop. If the router, not implementing the extension described in this specification, is the destination, then the packet will never reach its destination, as the source will not have a suitable routing table entry for the destination. Network management may be required to ensure that the MANET still functions in these cases. 13. IANA Considerations TBD. 14. Security Considerations TBD. Dearlove & Clausen Expires January 13, 2014 [Page 12] Internet-Draft Multi-Topology OLSRv2 July 2013 15. Acknowledgments TBD. 16. References 16.1. Normative References [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol version 2", work in progress draft-ietf-manet-olsrv2-19, March 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized MANET Packet/Message Format", RFC 5444, February 2009. [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. 16.2. Informative References [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003. [TLV-Extensions] Dearlove, C. and T. Clausen, "Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Disovery Protocol (NHDP) Extension TLVs", work in progress draft-dearlove-manet-olsrv2-tlv-extensions-00, July 2013. Dearlove & Clausen Expires January 13, 2014 [Page 13] Internet-Draft Multi-Topology OLSRv2 July 2013 Authors' Addresses Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom Phone: +44 1245 242194 Email: chris.dearlove@baesystems.com URI: http://www.baesystems.com/ Thomas Heide Clausen LIX, Ecole Polytechnique Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.ThomasClausen.org/ Dearlove & Clausen Expires January 13, 2014 [Page 14]