Internet DRAFT - draft-dearlove-manet-olsrv2-extensions

draft-dearlove-manet-olsrv2-extensions






Mobile Ad hoc Networking (MANET)                             C. Dearlove
Internet-Draft                                           BAE Systems ATC
Intended status: Standards Track                            July 8, 2013
Expires: January 9, 2014


 Routing MPR and Other Extensions for the Optimized Link State Routing
                      Protocol version 2 (OLSRv2)
               draft-dearlove-manet-olsrv2-extensions-00

Abstract

   This specification describes an extension to the Optimized Link State
   Routing Protocol version 2 (OLSRv2) to improve the selection of
   routing MPRs.  Other considerations for extending OLSRv2 and the
   MANET Neighborhood Discovery Protocol (NHDP) are also given.

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 9, 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
   described in the Simplified BSD License.



Dearlove                 Expires January 9, 2014                [Page 1]

Internet-Draft              OLSRv2 Extensions                  July 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  3
   4.  Routing MPR Selection  . . . . . . . . . . . . . . . . . . . .  4
   5.  Unknown TLV Values . . . . . . . . . . . . . . . . . . . . . .  5
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
     6.1.  Address Block TLVs . . . . . . . . . . . . . . . . . . . .  6
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10




































Dearlove                 Expires January 9, 2014                [Page 2]

Internet-Draft              OLSRv2 Extensions                  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].  This document discusses two areas
   in which that specification, and in the second case also the MANET
   Neighborhood Discovery Protocol (NHDP) [RFC6130], can be improved.
   These may at some future time be divided into two separate documents.

   One improvement included in OLSRv2, compared to its predecessor
   described in [RFC3626] is the use of link metrics, rather than
   minimum hop routing.  A rationale for how link metrics were included
   in OLSRv2 has been presented in [RFC6966-to-be] However, one aspect
   of the use of link metrics described in [RFC6966-to-be], the removal
   of some unnecessarily selected routing MPRs, was not included in
   [OLSRv2].  This specification modifies OLSRv2 to correct this
   oversight.  Note that an implementation using this removal is not
   strictly compliant with [OLSRv2], but is fully compatible with
   implementations not using this removal.  This specification defines
   an implementation using this removal as being compliant with the
   protocol OLSRv2, extending [OLSRv2].

   This specification also reduces the latitude of implementations of
   [OLSRv2] and [RFC6130] to consider some messages, which will not be
   created by implementations simply following those specifications, as
   a reason to consider the message as ill-formed, and thus as a reason
   to reject the message.  This gives greater latitude to the creation
   of extensions of these protocols, in particular extensions that will
   interoperate with unextended implementations of those protocols.
   Specifically it indicates how TLVs (Type-Length-Value elements)
   [RFC5444] with unexpected value fields should be handled.


2.  Terminology

   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].

   Additionally, this document uses the terminology of [RFC5444],
   [RFC6130] and [OLSRv2].


3.  Applicability Statement

   The two extensions described in this document are intended to modify
   the specification of the two protocols [OLSRv2] and (for the second



Dearlove                 Expires January 9, 2014                [Page 3]

Internet-Draft              OLSRv2 Extensions                  July 2013


   extension only) [RFC6130].  As such they are applicable to all
   implementations of these protocols, however the first extension is
   simply permissive, it allows an additional optimization, there is no
   necessity for any implementation to include it (although this is
   advised, it can, in some cases, create smaller and fewer messages and
   more efficient flooding, without ever having the opposite effect).

   [OLSRv2] defines the properties for the selection of routing MPRs
   (mulipoint relays) from among a router's symmetric 1-hop neighbors as
   properties that correspond first to that the selected MPRs consist of
   a set of symmetric 1-hop neighbors that cover all the symmetric 2-hop
   neighbors, and second that they do so retaining a minimum distance
   route (1-hop, if present, or 2-hop) to each symmetric 2-hop neighbor.
   The discussion in the latter part of Section 6.2 of [RFC6966-to-be]
   indicates that this requirement is over-prescriptive for routing MPR
   selection.  This update to [OLSRv2] permits a router to use the
   described optimization, while still being considered compliant.
   (Note that, whether considered compliant or not, a router that so
   behaves will operate successfully, including in a network with a
   mixture of routers that do and do not use this optimisation.)

   Both [RFC6130] and [OLSRv2] define a number of TLVs that have only
   some values used.  The second extension removes the latitude of an
   implementation to consider the use of such values as errors,
   permitting their use in extensions.  Some specific usage of these
   cases is defined, both cases that are defined as having no function
   (but which can make the creation of multivalue TLVs more efficient)
   and the interpretation of two TLV values (MPR and NBR_ADDR_TYPE) as
   bit fields, which may have a minor impact on some implementations'
   interpretation of such fields in received messages.


4.  Routing MPR Selection

   A set of routing MPRs created as specified in [OLSRv2] MAY be
   optimized in the following manner.  Note that this uses the notation
   of Section 18.3 of [OLSRv2]:

   1.  If there is a sequence x_0, ..., x_n of elements of N1 such that:

       *  x_0 is a routing MPR,

       *  x_1, ... , x_n have corresponding elements y_1, ..., y_n of
          N2, and

       *  d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m =
          1, ... , n,




Dearlove                 Expires January 9, 2014                [Page 4]

Internet-Draft              OLSRv2 Extensions                  July 2013


       then x_1 to x_n may be removed from the set of routing MPRs, if
       selected.

   Note that "corresponding elements" in N1 and N2 means that these
   elements represent the same router.  All of this information is
   available from information gathered by NHDP ([RFC6130]).

   It is RECOMMENDED that all OLSRv2 routers use this optimization.


5.  Unknown TLV Values

   NHDP [RFC6130] and OLSRv2 [OLSRv2] define a number of TLVs within the
   framework of [RFC5444].  A number of these TLVs specify the meaning
   of only some possible values that may occur in the value field of a
   TLV.  For example the LINK_METRIC TLV defined in [RFC6130] specified
   a meaning only for the values 0 (LOST), 1 (symmetric) AND 2 (HEARD).

   These protocols also specify that, in addition to well-defined
   reasons, an implementation of these protoocls MAY reject a message as
   ill-formed for other reasons.  The primary reason for that is to
   enable the implementation of extensions such as [NHDP-OLSRv2-sec].
   It could however be interpreted as allowing rejection of a message
   because a TLV value is unknown.  This specification removes that
   latitude, and states that an implementation MUST NOT reject a message
   because it contains such a TLV.  Instead any unknown value MUST be
   treated, by an unextended implementation of NHSP or OLSRv2 as if the
   TLV were not present.  (That may, in some cases, be a reason to
   reject the message, and that remains permitted.)

   Such unknown TLV values may be defined in a later specification, and
   thus, where appropriate, fixed specifications of values in [RFC6130]
   and [OLSRv2] have been re-defined in this specification as defined by
   extensible registries, see Section 6.  An extra entry has been added
   to relevant registries, to represent a value that is to permanently
   indicate no information.  The utility of this lies in considering
   multi-value TLVs, as defined in [RFC5444].

   [RFC5444] defines a multi-value TLV that may be used to assign
   information, such as link status, to more than one address in an
   Address Block.  Multi-value TLVs often represent an efficient (in
   terms of message size) way to convey the indicated information.
   However only consecutively recorded addresses may be covered by a
   multivalue TLV.  If conveying only one or two pieces of information,
   it is possible to order address so as to efficiently use multivalue
   TLVs, but if conveying more, then this is no longer possible.  In
   that case more than one TLV may be needed for a single type of
   information.  With the definition of a TLV value to mean "no



Dearlove                 Expires January 9, 2014                [Page 5]

Internet-Draft              OLSRv2 Extensions                  July 2013


   information", greater use of multivalue TLs is possible, allowing
   both more efficient messages and simpler implementations.  (An
   implementation must still be able to recognise whatever pattern of
   TLVs the sender chooses to use.)

   It should be stressed that this is not a change to [RFC6130] or
   [OLSRv2], except with regard to not allowing this to be a reason for
   rejection of a message.  These protocols are specified in terms such
   as "if an address is associated with a value of LOST by a LINK_STATUS
   TLV".  Association with an unknown value (or a value newly defined to
   mean no link status information) has no effect on such a
   specification.

   Specific cases that are affected are described in Section 6.  In
   three cases (LOCAL_IF, LINK_STATUS, OTHER_NEIGHB) there is no impact
   on [RFC6130] or [OLSRv2].  In two cases (MPR, NBR_ADDR_TYPE) the
   value is now to be interpreted as a bit field.  As the existing
   definitions of values 1, 2, and 3 behaved in that manner, it is
   likely that this will involve no change, but any test of (for
   example) Value = 1 or Value = 3 MUST be converted to a test of (for
   example) Value bitand 1 = 1, where "bitand" denaotes a bitwise and
   operation.

   Not reported, because unchanged, is the LINK_METRIC TLV.  However it
   should be noted that any (two octet) value with all four most
   significant bits clear (0) is a case that conveys no information
   about the network address (and which will, at least as far as this
   TLV is concerned, be not used by OLSRv2).  It is RECOMMENDED that
   when using such a value deliberately that the remaining twelve bits
   be either all clear (0) or all set (1).  However any received pattern
   of bits MUST be so interpreted.


6.  IANA Considerations

   Note: Values defined as "Unallocated: Expert Review" mean that these
   values may be allocated according to the expert review guidelines
   specified in [RFC6130] and [OLSRv2].  In two cases a constraint on
   how future allocation is specified.

6.1.  Address Block TLVs

   IANA is requested to create a registry associated with the Address
   Block TLV with name LOCAL_IF (Type = 2, Type Extension = 0) defined
   in [RFC6130], specifying the meaning of its single values.  This
   replaces the Description column in Table 6 in [RFC6130] by a
   reference to this table.




Dearlove                 Expires January 9, 2014                [Page 6]

Internet-Draft              OLSRv2 Extensions                  July 2013


   +---------+-------------+-------------------------------------------+
   |  Value  |     Name    |                Description                |
   +---------+-------------+-------------------------------------------+
   |    0    |   THIS_IF   |   The network address is associated with  |
   |         |             |    this local interface of the sending    |
   |         |             |                   router                  |
   |    1    |   OTHER_IF  |   The network address is associated with  |
   |         |             |   another local interface of the sending  |
   |         |             |                   router                  |
   |  2-223  |             |         Unallocated: Expert Review        |
   | 224-254 |             |              Experimental Use             |
   |   255   | UNSPECIFIED | No information about this network address |
   |         |             |                is provided                |
   +---------+-------------+-------------------------------------------+

                       Table 1: LOCAL_IF TLV Values

   IANA are reqested to create a registry associated with the Address
   Block TLV with name LINK_STATUS (Type = 3, Type Extension = 0)
   defined in [RFC6130], specifying the meaning of its single values.
   This replaces the Description column in Table 7 in [RFC6130] by a
   reference to this table.

   +---------+-------------+-------------------------------------------+
   |  Value  |     Name    |                Description                |
   +---------+-------------+-------------------------------------------+
   |    0    |     LOST    |    The link on this interface from the    |
   |         |             | router with that network address has been |
   |         |             |                    lost                   |
   |    1    |  SYMMETRIC  |    The link on this interface from the    |
   |         |             |  router with that network address has the |
   |         |             |            status of symmetric            |
   |    2    |    HEARD    |    The link on this interface from the    |
   |         |             |  router with that network address has the |
   |         |             |              status of heard              |
   |  3-223  |             |         Unallocated: Expert Review        |
   | 224-254 |             |              Experimental Use             |
   |   255   | UNSPECIFIED | No information about this network address |
   |         |             |                is provided                |
   +---------+-------------+-------------------------------------------+

                      Table 2: LINK_STATUS TLV Values

   IANA are reqested to create a registry associated with the Address
   Block TLV with name OTHER_NEIGHB (Type = 4, Type Extension = 0)
   defined in [RFC6130], specifying the meaning of its single values.
   This replaces the Description column in Table 8 in [RFC6130] by a
   reference to this table.



Dearlove                 Expires January 9, 2014                [Page 7]

Internet-Draft              OLSRv2 Extensions                  July 2013


   +---------+-------------+-------------------------------------------+
   |  Value  |     Name    |                Description                |
   +---------+-------------+-------------------------------------------+
   |    0    |     LOST    |    The neighbour relationship with the    |
   |         |             | router with that network address has been |
   |         |             |                    lost                   |
   |    1    |  SYMMETRIC  |    The neighbour relationship with the    |
   |         |             |    router with that network address is    |
   |         |             |                 symmetric                 |
   |  2-223  |             |         Unallocated: Expert Review        |
   | 224-254 |             |              Experimental Use             |
   |   255   | UNSPECIFIED | No information about this network address |
   |         |             |                is provided                |
   +---------+-------------+-------------------------------------------+

                     Table 3: OTHER_NEIGHB TLV Values

   IANA are reqested to create a registry associated with the Address
   Block TLV with name MPR (Type = 8, Type Extension = 0) defined in
   [OLSRv2], specifying the meaning of its single values in terms of the
   values of each bit of the value, from bit 0 (most significant) to bit
   7 (least significant).  If multiple bits are set then each applies.
   This replaces the Description column in Table 14 in [OLSRv2] by a
   reference to this table.

   +-------+-------+----------+----------------------------------------+
   | Value | Value |   Name   |               Description              |
   |  Bit  |       |          |                                        |
   +-------+-------+----------+----------------------------------------+
   |   7   |   1   | FLOODING |     The neighbour with that network    |
   |       |       |          |  address has been selected as flooding |
   |       |       |          |                   MPR                  |
   |   6   |   2   |  ROUTING |     The neighbour with that network    |
   |       |       |          |  address has been selected as flooding |
   |       |       |          |                   MPR                  |
   |  0-5  |       |          |       Unallocated: Expert Review       |
   +-------+-------+----------+----------------------------------------+

                        Table 4: MPR TLV Bit Values

   The combination FLOODING + ROUTING (Value = 3) is given the name
   FLOOD_ROUTE in [OLSRv2].  All future allocated bits MUST use the
   unset bit (0) to indicates no information, so that the case Value = 0
   will always indicate that no information about this network address
   is provided.

   IANA are reqested to create a registry associated with the Address
   Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0)



Dearlove                 Expires January 9, 2014                [Page 8]

Internet-Draft              OLSRv2 Extensions                  July 2013


   defined in [OLSRv2], specifying the meaning of its single values in
   terms of the values of each bit of the value, from bit 0 (most
   significant) to bit 7 (least significant).  If multiple bits are set
   then each applies.  This replaces the Description column in Table 15
   in [OLSRv2] by a reference to this table.

   +-------+-------+------------+--------------------------------------+
   | Value | Value |    Name    |              Description             |
   |  Bit  |       |            |                                      |
   +-------+-------+------------+--------------------------------------+
   |   7   |   1   | ORIGINATOR | The network address is an originator |
   |       |       |            |       address reachable via the      |
   |       |       |            |          originating router          |
   |   6   |   2   |  ROUTABLE  |   The network address is a routable  |
   |       |       |            |       address reachable via the      |
   |       |       |            |          originating router          |
   |  0-5  |       |            |      Unallocated: Expert Review      |
   +-------+-------+------------+--------------------------------------+

                   Table 5: NBR_ADDR_TYPE TLV Bit Values

   The combination ORIGINATOR + ROUTABLE (Value = 3) is given the name
   ROUTABLE_ORIG in [OLSRv2].  All future allocated bits MUST use the
   unset bit (0) to indicates no information, so that the case Value = 0
   will always indicate that no information about this network address
   is provided.


7.  Security Considerations

   TBD.


8.  Acknowledgments

   TBD.


9.  References

9.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.



Dearlove                 Expires January 9, 2014                [Page 9]

Internet-Draft              OLSRv2 Extensions                  July 2013


   [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.

9.2.  Informative References

   [NHDP-OLSRv2-sec]
              Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for Control Messages in NHDP and OLSRv2", work
              in progress draft-ietf-manet-nhdp-olsrv2-sec-03,
              July 2013.

   [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.

   [RFC6966-to-be]
              Clausen, T., Dearlove, C., and P. Jacquet, "Rationale for
              the Use of Link Metrics in the Optimized Link State
              Routing Protocol Version 2 (OLSRv2)", RFC 6966, TBD 2013.


Author's Address

   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/











Dearlove                 Expires January 9, 2014               [Page 10]