tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7181

 
 
 

The Optimized Link State Routing Protocol Version 2

Part 5 of 5, p. 84 to 115
Prev RFC Part

 


prevText      Top      Up      ToC       Page 84 
23.  Security Considerations

   As a proactive routing protocol, OLSRv2 is a potential target for
   various attacks.  This section presents the envisioned security
   architecture for OLSRv2 and gives guidelines on how to provide
   integrity, confidentiality, and integration into external routing
   domains.  Separately specified mandatory security mechanisms are
   summarized, and some observations on key management are given.

23.1.  Security Architecture

   OLSRv2 integrates into the architecture specified in Appendix A of
   [RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter
   by using and extending its messages and Information Bases.

   As part of this architecture, OLSRv2 and NHDP [RFC6130] recognize
   that there may be external reasons for rejecting messages that would
   be considered "badly formed" or "insecure", e.g., if an Integrity
   Check Value (ICV) included in a message by an external mechanism
   cannot be verified.  This architecture allows options as to whether
   and how to implement security features, reflecting the situation that
   MANET routing protocol deployment domains have varying security
   requirements, ranging from "practically unbreakable" to "virtually
   none".  This approach allows MANET routing protocol specifications to
   remain generic, with extensions to them and/or extensions to the

Top      Up      ToC       Page 85 
   multiplexing and demultiplexing process described in Appendix A of
   [RFC5444], providing security mechanisms appropriate to a given
   deployment domain.

   The following sections provide guidelines on how to provide
   integrity, confidentiality, and integration with external routing
   domains in such extensions.

23.2.  Integrity

   Each router injects topological information into the network by
   transmitting HELLO messages and, for some routers, also TC messages.
   If some routers for some reason (malice or malfunction) inject
   invalid control traffic, network integrity may be compromised.
   Therefore, message, or packet, authentication is strongly advised.

   Different such situations may occur, for example:

   1.  A router generates TC messages, advertising links to non-neighbor
       routers;

   2.  A router generates TC messages, pretending to be another router;

   3.  A router generates HELLO messages, advertising non-neighbor
       routers;

   4.  A router generates HELLO messages, pretending to be another
       router;

   5.  A router forwards altered control messages;

   6.  A router does not forward control messages;

   7.  A router does not select multipoint relays correctly;

   8.  A router forwards broadcast control messages unaltered but does
       not forward unicast data traffic;

   9.  A router "replays" previously recorded control traffic from
       another router.

   Authentication of the originator router for control messages (for
   situations 2, 4, and 5) and of the individual links announced in the
   control messages (for situations 1 and 3) may be used as a
   countermeasure.  However, to prevent routers from repeating old (and
   correctly authenticated) information (situation 9), additional
   information is required (e.g., a timestamp or sequence number),
   allowing a router to positively identify such replayed messages.

Top      Up      ToC       Page 86 
   In general, ICVs (e.g., digital signatures) and other required
   security information can be transmitted within the HELLO and TC
   messages or within a packet header using the TLV mechanism.  Either
   option permits different levels of protection to coexist in the same
   network, if desired.

   An important consideration is that all control messages (HELLO
   messages and TC messages) are transmitted to all routers in the 1-hop
   neighborhood and some control messages (TC messages) are flooded to
   all routers in the network.  This is done in a packet that is
   transmitted to all routers in the 1-hop neighborhood, the current set
   of which may not be known.  Thus, a control message or packet used by
   this protocol is always contained in a transmission destined for
   multiple destinations, and it is important that the authentication
   mechanism employed permits any receiving router to validate the
   authenticity of a message or packet.

   [RFC7182] specifies a common exchange format for cryptographic
   information in the form of Packet TLVs, Message TLVs, and Address
   Block TLVs, as specified in [RFC5444].  These may be used (and
   shared) among MANET routing protocol security extensions.  In
   particular, [RFC7182] specifies the format of TLVs for containing
   Integrity Check Values (ICVs), i.e., signatures, for providing
   integrity, as well as TLVs for containing temporal information for
   preventing replay attacks.  [RFC7182] specifies registries for using
   different ciphers and formats of temporal information.  When using
   ICV TLVs in an OLSRv2 deployment, failure to verify an included ICV
   mandates rejection of an incoming message or packet as "invalid",
   according to Section 12.1 of [RFC6130] and according to
   Section 16.3.1 of this specification when using the multiplexing and
   demultiplexing process described in Appendix A of [RFC5444].

   [RFC7182] specifies how to insert ICVs into generated messages, how
   to verify incoming messages, and to reject "insecure" messages (i.e.,
   messages without an ICV or with an ICV that cannot be verified).
   Different MANET deployments may, as a result of the purpose for which
   they are used and the possibility and nature of their configuration,
   require different ICV algorithms and timestamps or multiple keys, and
   thus, a security extension may use any of the different options
   provided in [RFC7182].

23.3.  Confidentiality

   OLSRv2 periodically MPR floods topological information to all routers
   in the network.  Hence, if used in an unprotected network, in
   particular, an unprotected wireless network, the network topology is
   revealed to anyone who successfully listens to the control messages.
   This information may serve an attacker to acquire details about the

Top      Up      ToC       Page 87 
   topology and therefore to initiate more effective attacks against
   routers in the routing domain, e.g., by spoofing addresses of routers
   in the network and attracting traffic for these addresses.  Note that
   this is independent of the data traffic and purely protects the
   control traffic, i.e., information about the network topology.

   In situations where the confidentiality of the network topology is of
   importance, regular cryptographic techniques, such as use of OLSRv2
   multicast control packets encrypted using IPsec (e.g., with a shared
   secret key), can be applied to ensure that control traffic can be
   read and interpreted by only those authorized to do so.
   Alternatively, a security extension may specify a mechanism to
   provide confidentiality for control messages and/or packets.
   However, unless the information about the network topology itself is
   confidential, integrity of control messages (as specified in
   Section 23.2) is sufficient to admit only trusted routers (i.e.,
   routers with valid credentials) to the network.

23.4.  Interaction with External Routing Domains

   This protocol provides a basic mechanism for injecting external
   routing information into this protocol's routing domain.  Routing
   information can also be extracted from this protocol's Information
   Bases, in particular the Routing Set, and injected into an external
   routing domain, if the routing protocol governing that routing domain
   permits this.

   When operating routers connecting a routing domain using this
   protocol to an external routing domain, care MUST be taken not to
   allow potentially insecure and untrustworthy information to be
   injected from this routing domain to an external routing domain.
   Care MUST also be taken to validate the correctness of information
   prior to it being injected, so as to avoid polluting routing tables
   with invalid information.

   A recommended way of extending connectivity from an external routing
   domain to this routing domain, which is routed using this protocol,
   is to assign an IP prefix (under the authority of the routers/
   gateways connecting this routing domain with the external routing
   domain) exclusively to this routing domain and to configure the
   gateways to advertise routes for that IP prefix into the external
   routing domain.

23.5.  Mandatory Security Mechanisms

   A conformant implementation of OLSRv2 MUST, at minimum, implement the
   security mechanisms specified in [RFC7183], providing integrity and
   replay protection of OLSRv2 control messages, including of HELLO

Top      Up      ToC       Page 88 
   messages specified by [RFC6130] and used by OLSRv2, by inclusion of a
   timestamp TLV and an Integrity Check Value (ICV) TLV.  This ICV TLV
   uses a SHA-256-based HMAC and one or more manually managed shared
   secret keys.  The timestamp TLV is based on Portable Operating System
   Interface (POSIX) time, assuming router time synchronization.

   The baseline use case, for which this security mechanism provides
   adequate integrity protection without rekeying, is for short-lived
   (for example, up to a couple of months) OLSRv2 deployments.

   Any deployment of OLSRv2 SHOULD use the security mechanism specified
   in [RFC7183] but MAY use another mechanism if more appropriate in an
   OLSRv2 deployment.  For example, for longer-term OLSRv2 deployments,
   alternative security mechanisms (e.g., rekeying) SHOULD be
   considered.

23.6.  Key Management

   This specification, as well as [RFC7183], does not mandate automated
   key management (AKM) as part of the security architecture for OLSRv2.
   While some use cases for OLSRv2 may require AKM, the baseline
   assumption is that many use cases do not, for the reasons detailed
   below.

   Bootstrapping a key is hard in a radio network, where it is, in
   general, not possible to determine from where a received signal was
   transmitted or if two transmissions come from the same or from
   different sources.

   The widespread use of radio networks and mobile phone networks works
   under the assumptions that (i) secret information is embedded in
   mobile phones at manufacture, and (ii) a centralized database of this
   is accessible during the network lifetime.

   As a primary use case of a MANET is to provide connectivity without
   centralized entities and with minimal management, a solution such as
   described in the previous paragraph is not feasible.  In many
   instances, a cryptographic authority may not be present in the MANET
   at all, since such a cryptographic authority would be too vulnerable.
   Due to the potentially dynamic topology of a MANET, a cryptographic
   authority may also become unreachable (to some or all of the MANET
   routers) without prior warning.

   [BCP107] provides guidelines for cryptographic key management.
   Specifically, Section 2.1 sets forth requirements for when AKM is
   required, and Section 2.2 sets forth conditions under which manual
   key management is acceptable.

Top      Up      ToC       Page 89 
   Section 2.1 of [BCP107] stipulates that "Automated key management
   MUST be used if any of [a set of given] conditions hold".  These
   conditions are listed below, and arguments for each are provided in
   regard to their applicability for the baseline use case of OLSRv2.

   o  A party will have to manage n^2 static keys, where n may become
      large.

      The baseline use case of OLSRv2 uses only one or a small set of
      manually managed shared secrets in the whole MANET.

   o  Any stream cipher (such as RC4 [RFC6229][RC4], AES-CTR
      [RFC3610][NIST-SP-800-38A], or AES-CCM [RFC3686][NIST-SP-800-38C])
      is used.

      A stream cipher is not envisioned for use to generate ICVs for
      OLSRv2 control messages.

   o  An initialization vector (IV) might be reused, especially an
      implicit IV.  Note that random or pseudo-random explicit IVs are
      not a problem unless the probability of repetition is high.

      An IV is not envisioned for use to generate ICVs for OLSRv2
      control messages.

   o  Large amounts of data might need to be encrypted in a short time,
      causing frequent change of the short-term session key.

      Integrity Check Values (ICVs) are required only for OLSRv2 control
      messages, which are low-volume messages.

   o  Long-term session keys are used by more than two parties.
      Multicast is a necessary exception, but multicast key management
      standards are emerging in order to avoid this in the future.
      Sharing long-term session keys should generally be discouraged.

      OLSRv2 control messages are all sent using link-local multicast.

   o  The likely operational environment is one where personnel (or
      device) turnover is frequent, causing frequent change of the
      short-term session key.

      This is not an intended deployment of OLSRv2.  For longer-term
      OLSRv2 deployments, alternative security mechanisms (e.g.,
      including rekeying) SHOULD be considered.

Top      Up      ToC       Page 90 
   Section 2.2 of [BCP107] stipulates that "Manual key management may be
   a reasonable approach in any of [a given set of] situations".  These
   situations are listed below, and arguments for each are provided in
   regard to their applicability for the baseline use case of OLSRv2.

   o  The environment has very limited available bandwidth or very high
      round-trip times.  Public key systems tend to require long
      messages and lots of computation; symmetric key alternatives, such
      as Kerberos, often require several round trips and interaction
      with third parties.

      As previously noted, there may not be the required infrastructure
      (cryptographic authority) present (or, if present, may not be
      reachable) in the MANET.  Bandwidth in a MANET is commonly
      limited, both by being a radio environment and by the need for any
      signaling to consume a minimal proportion thereof, and round trip
      times may also be significant.

   o  The information being protected has low value.

      This depends on the OLSRv2 use case, but the information being
      protected is OLSRv2 control traffic, which is of at least moderate
      value; thus, this case does not apply.

   o  The total volume of traffic over the entire lifetime of the long-
      term session key will be very low.

      Integrity Check Values (ICVs) are required only for OLSRv2 control
      messages, which are low-volume messages.

   o  The scale of each deployment is very limited.

      A typical use case for OLSRv2 may involve only tens of devices --
      with even the largest use cases for OLSRv2 being small by Internet
      standards.

24.  IANA Considerations

   This specification defines one Message Type, which has been allocated
   from the "Message Types" registry of [RFC5444], two Message TLV
   Types, which have been allocated from the "Message TLV Types"
   registry of [RFC5444], and four Address Block TLV Types, which have
   been allocated from the "Address Block TLV Types" registry of
   [RFC5444].

Top      Up      ToC       Page 91 
24.1.  Expert Review: Evaluation Guidelines

   For the registries where an Expert Review is required, the designated
   expert SHOULD take the same general recommendations into
   consideration as are specified by [RFC5444].

24.2.  Message Types

   This specification defines one Message Type, allocated from the 0-223
   range of the "Message Types" namespace defined in [RFC5444], as
   specified in Table 8.

          +------+----------------------------------------------+
          | Type | Description                                  |
          +------+----------------------------------------------+
          |  1   | TC : Topology Control (MANET-wide signaling) |
          +------+----------------------------------------------+

                     Table 8: Message Type Assignment

24.3.  Message-Type-Specific TLV Type Registries

   IANA has created a registry for Message-Type-specific Message TLVs
   for TC messages, in accordance with Section 6.2.1 of [RFC5444] and
   with initial assignments and allocation policies as specified in
   Table 9.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               | 128-223 | Unassigned  | Expert Review     |
               +---------+-------------+-------------------+

            Table 9: TC Message-Type-Specific Message TLV Types

   IANA has created a registry for Message-Type-specific Address Block
   TLVs for TC messages, in accordance with Section 6.2.1 of [RFC5444]
   and with initial assignments and allocation policies as specified in
   Table 10.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               | 128-223 | Unassigned  | Expert Review     |
               +---------+-------------+-------------------+

        Table 10: TC Message-Type-Specific Address Block TLV Types

Top      Up      ToC       Page 92 
24.4.  Message TLV Types

   This specification defines two Message TLV Types, which have been
   allocated from the "Message TLV Types" namespace defined in
   [RFC5444].  IANA has made allocations in the 0-127 range for these
   types.  Two new Type Extension registries have been created with
   assignments as specified in Table 11 and Table 12.  Specifications of
   these TLVs are in Section 13.3.1.  Each of these TLVs MUST NOT be
   included more than once in a Message TLV Block.

   +-------------+------+-----------+---------------------+------------+
   |     Name    | Type |    Type   | Description         | Allocation |
   |             |      | Extension |                     | Policy     |
   +-------------+------+-----------+---------------------+------------+
   | MPR_WILLING |  7   |     0     | Bits 0-3 specify    |            |
   |             |      |           | the originating     |            |
   |             |      |           | router's            |            |
   |             |      |           | willingness to act  |            |
   |             |      |           | as a flooding MPR;  |            |
   |             |      |           | bits 4-7 specify    |            |
   |             |      |           | the originating     |            |
   |             |      |           | router's            |            |
   |             |      |           | willingness to act  |            |
   |             |      |           | as a routing MPR.   |            |
   | MPR_WILLING |  7   |   1-255   | Unassigned.         | Expert     |
   |             |      |           |                     | Review     |
   +-------------+------+-----------+---------------------+------------+

            Table 11: Message TLV Type Assignment: MPR_WILLING

Top      Up      ToC       Page 93 
   +--------------+------+-----------+--------------------+------------+
   |     Name     | Type |    Type   | Description        | Allocation |
   |              |      | Extension |                    | Policy     |
   +--------------+------+-----------+--------------------+------------+
   | CONT_SEQ_NUM |  8   |     0     | COMPLETE:          |            |
   |              |      |           | Specifies a        |            |
   |              |      |           | content sequence   |            |
   |              |      |           | number for this    |            |
   |              |      |           | complete message.  |            |
   | CONT_SEQ_NUM |  8   |     1     | INCOMPLETE:        |            |
   |              |      |           | Specifies a        |            |
   |              |      |           | content sequence   |            |
   |              |      |           | number for this    |            |
   |              |      |           | incomplete         |            |
   |              |      |           | message.           |            |
   | CONT_SEQ_NUM |  8   |   2-255   | Unassigned.        | Expert     |
   |              |      |           |                    | Review     |
   +--------------+------+-----------+--------------------+------------+

            Table 12: Message TLV Type Assignment: CONT_SEQ_NUM

   Type extensions indicated as Expert Review SHOULD be allocated as
   described in [RFC5444], based on Expert Review as defined in
   [RFC5226].

24.5.  Address Block TLV Types

   This specification defines four Address Block TLV Types, which have
   been allocated from the "Address Block TLV Types" namespace defined
   in [RFC5444].  IANA has made allocations in the 8-127 range for these
   types.  Four new Type Extension registries have been created with
   assignments as specified in Tables 13, 14, 15, and 16.
   Specifications of these TLVs are in Section 13.3.2.

   The registration procedure for the "LINK_METRIC Address Block TLV
   Type Extensions" registry is Expert Review.

   +-------------+------+-----------+----------------------------------+
   |     Name    | Type |    Type   | Description                      |
   |             |      | Extension |                                  |
   +-------------+------+-----------+----------------------------------+
   | LINK_METRIC |  7   |     0     | Link metric meaning assigned by  |
   |             |      |           | administrative action.           |
   | LINK_METRIC |  7   |   1-223   | Unassigned.                      |
   | LINK_METRIC |  7   |  224-255  | Reserved for Experimental Use    |
   +-------------+------+-----------+----------------------------------+

         Table 13: Address Block TLV Type Assignment: LINK_METRIC

Top      Up      ToC       Page 94 
   All LINK_METRIC TLVs, whatever their type extension, MUST use their
   value field to encode the kind and value (in the interval
   MINIMUM_METRIC to MAXIMUM_METRIC, inclusive) of a link metric as
   specified in Sections 6 and 13.3.2.  An assignment of a LINK_METRIC
   TLV type extension MUST specify the physical meaning of the link
   metric and the mapping of that physical meaning to the representable
   values in the indicated interval.

   +------+------+-----------+----------------------------+------------+
   | Name | Type |    Type   | Description                | Allocation |
   |      |      | Extension |                            | Policy     |
   +------+------+-----------+----------------------------+------------+
   | MPR  |  8   |     0     | Specifies that a given     |            |
   |      |      |           | network address is of a    |            |
   |      |      |           | router selected as a       |            |
   |      |      |           | flooding MPR (FLOODING =   |            |
   |      |      |           | 1), that a given network   |            |
   |      |      |           | address is of a router     |            |
   |      |      |           | selected as a routing MPR  |            |
   |      |      |           | (ROUTING = 2), or both     |            |
   |      |      |           | (FLOOD_ROUTE = 3).         |            |
   | MPR  |  8   |   1-255   | Unassigned.                | Expert     |
   |      |      |           |                            | Review     |
   +------+------+-----------+----------------------------+------------+

             Table 14: Address Block TLV Type Assignment: MPR

Top      Up      ToC       Page 95 
   +---------------+------+-----------+-------------------+------------+
   |      Name     | Type |    Type   | Description       | Allocation |
   |               |      | Extension |                   | Policy     |
   +---------------+------+-----------+-------------------+------------+
   | NBR_ADDR_TYPE |  9   |     0     | Specifies that a  |            |
   |               |      |           | given network     |            |
   |               |      |           | address is of a   |            |
   |               |      |           | neighbor reached  |            |
   |               |      |           | via the           |            |
   |               |      |           | originating       |            |
   |               |      |           | router, if it is  |            |
   |               |      |           | an originator     |            |
   |               |      |           | address           |            |
   |               |      |           | (ORIGINATOR = 1), |            |
   |               |      |           | is a routable     |            |
   |               |      |           | address (ROUTABLE |            |
   |               |      |           | = 2), or if it is |            |
   |               |      |           | both              |            |
   |               |      |           | (ROUTABLE_ORIG =  |            |
   |               |      |           | 3).               |            |
   | NBR_ADDR_TYPE |  9   |   1-255   | Unassigned.       | Expert     |
   |               |      |           |                   | Review     |
   +---------------+------+-----------+-------------------+------------+

        Table 15: Address Block TLV Type Assignment: NBR_ADDR_TYPE

   +---------+------+-----------+-------------------------+------------+
   |   Name  | Type |    Type   | Description             | Allocation |
   |         |      | extension |                         | Policy     |
   +---------+------+-----------+-------------------------+------------+
   | GATEWAY |  10  |     0     | Specifies that a given  |            |
   |         |      |           | network address is      |            |
   |         |      |           | reached via a gateway   |            |
   |         |      |           | on the originating      |            |
   |         |      |           | router, with value      |            |
   |         |      |           | equal to the number of  |            |
   |         |      |           | hops.                   |            |
   | GATEWAY |  10  |   1-255   |                         | Expert     |
   |         |      |           |                         | Review     |
   +---------+------+-----------+-------------------------+------------+

           Table 16: Address Block TLV Type Assignment: GATEWAY

   Type extensions indicated as Expert Review SHOULD be allocated as
   described in [RFC5444], based on Expert Review as defined in
   [RFC5226].

Top      Up      ToC       Page 96 
24.6.  NBR_ADDR_TYPE and MPR Values

   Note: This section does not require any IANA action, as the required
   information is included in the descriptions of the MPR and
   NBR_ADDR_TYPE Address Block TLVs allocated in Section 24.5.  This
   information is recorded here for clarity and for use elsewhere in
   this specification.

   The Values that the MPR Address Block TLV can use are as follows:

   o  FLOODING := 1;

   o  ROUTING := 2;

   o  FLOOD_ROUTE := 3.

   The Values that the NBR_ADDR_TYPE Address Block TLV can use are
   follows:

   o  ORIGINATOR := 1;

   o  ROUTABLE := 2;

   o  ROUTABLE_ORIG := 3.

25.  Contributors

   This specification is the result of the joint efforts of the
   following contributors, listed alphabetically.

   o  Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>

   o  Emmanuel Baccelli, INRIA , France, <Emmanuel.Baccelli@inria.fr>

   o  Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>

   o  Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>

   o  Christopher Dearlove, BAE Systems, UK,
      <chris.dearlove@baesystems.com>

   o  Ulrich Herberg, Fujitsu Laboratories of America, USA,
      <ulrich@herberg.name>

   o  Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>

   o  Philippe Jacquet, Alcatel Lucent Bell Labs, France,
      <philippe.jacquet@alcatel-lucent.fr>

Top      Up      ToC       Page 97 
   o  Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>

   o  Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp>

   o  Ryuji Wakikawa, Toyota, Japan, <ryuji@sfc.wide.ad.jp>

26.  Acknowledgments

   The authors would like to acknowledge the team behind OLSRv1, as
   listed in RFC 3626, including Anis Laouiti (INT), Pascale Minet
   (INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah
   University), and Laurent Viennot (INRIA) for their contributions.

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews, and comments on the
   specification and its components (listed alphabetically): Khaldoun Al
   Agha (LRI), Teco Boot (Infinity Networks), Ross Callon (Juniper),
   Song-Yean Cho (Samsung), Alan Cullen (BAE Systems), Louise Lamont
   (CRC), Li Li (CRC), Joseph Macker (NRL), Richard Ogier (SRI), Charles
   E. Perkins (Futurewei), Henning Rogge (Frauenhofer FKIE), and the
   entire IETF MANET Working Group.

   Finally, the authors would like to express their gratitude to the
   Area Directors for providing valuable review comments during the IESG
   evaluation, in particular (listed alphabetically) Benoit Claise,
   Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Martin
   Stiemerling.

27.  References

27.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5148]   Clausen, T., Dearlove, C., and B. Adamson, "Jitter
               Considerations in Mobile Ad Hoc Networks (MANETs)", RFC
               5148, February 2008.

   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
               May 2008.

   [RFC5444]   Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
               "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
               Format", RFC 5444, February 2009.

Top      Up      ToC       Page 98 
   [RFC5497]   Clausen, T. and C. Dearlove, "Representing Multi-Value
               Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March
               2009.

   [RFC5498]   Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
               (MANET) Protocols", RFC 5498, March 2009.

   [RFC6130]   Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
               Network (MANET) Neighborhood Discovery Protocol (NHDP)",
               RFC 6130, April 2011.

   [RFC7182]   Herberg, U., Clausen, T., and C. Dearlove, "Integrity
               Check Value and Timestamp TLV Definitions for Mobile Ad
               Hoc Networks (MANETs)", RFC 7182, April 2014.

   [RFC7183]   Herberg, U., Dearlove, C., and T. Clausen, "Integrity
               Protection for the Neighborhood Discovery Protocol (NHDP)
               and Optimized Link State Routing Protocol Version 2
               (OLSRv2)", RFC 7183, April 2014.

27.2.  Informative References

   [BCP107]    Bellovin, S. and R. Housley, "Guidelines for
               Cryptographic Key Management", BCP 107, RFC 4107, June
               2005.

   [FSLS]      Santivanez, C., Ramanathan, R., and I. Stavrakakis,
               "Making Link-State Routing Scale for Ad Hoc Networks",
               MobiHoc '01, Proceedings of the 2nd ACM International
               Symposium on Mobile Ad Hoc Networking & Computing, 2001.

   [FSR]       Pei, G., Gerla, M., and T. Chen, "Fisheye State Routing
               in Mobile Ad Hoc Networks", ICDCS Workshop on Wireless
               Networks and Mobile Computing, 2000.

   [HIPERLAN]  ETSI, "Radio Equipment and Systems (RES); HIgh
               PErformance Radio Local Area Network (HIPERLAN) Type 1;
               Functional Specification", ETSI 300-652, June 1996.

   [HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. Rivierre,
               "Increasing Reliability in Cable-Free Radio LANs: Low
               Level Forwarding in HIPERLAN", Wireless Personal
               Communications, Volume 4, Issue 1, 1997.

   [MPR]       Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
               relaying: An efficient technique for flooding in mobile
               wireless Networks", INRIA, No. 3898, March 2000.

Top      Up      ToC       Page 99 
   [McCabe]    McCabe, A., Dearlove, C., Fredin, M., and L. Axelsson,
               "Scalability modelling of ad hoc routing protocols - a
               comparison of OLSR and DSR", Scandinavian Wireless Adhoc
               Networks '04, 2004.

   [NIST-SP-800-38A]
               National Institute of Standards and Technology,
               "Recommendation for Block Cipher Modes of Operation:
               Methods and Techniques", Special Publication 800-38A,
               December 2001.

   [NIST-SP-800-38C]
               National Institute of Standards and Technology,
               "Recommendation for Block Cipher Modes of Operation: The
               CCM Mode for Authentication and Confidentiality", Special
               Publication 800-38C, May 2004.

   [RC4]       Schneier, B., "Applied Cryptography: Protocols,
               Algorithms, and Source Code in C", Second Edition, John
               Wiley and Sons, New York, 1996.

   [RFC2501]   Corson, M. and J. Macker, "Mobile Ad hoc Networking
               (MANET): Routing Protocol Performance Issues and
               Evaluation Considerations", RFC 2501, January 1999.

   [RFC3610]   Whiting, D., Housley, R., and N. Ferguson, "Counter with
               CBC-MAC (CCM)", RFC 3610, September 2003.

   [RFC3626]   Clausen, T. and P. Jacquet, "Optimized Link State Routing
               Protocol (OLSR)", RFC 3626, October 2003.

   [RFC3686]   Housley, R., "Using Advanced Encryption Standard (AES)
               Counter Mode With IPsec Encapsulating Security Payload
               (ESP)", RFC 3686, January 2004.

   [RFC6229]   Strombergson, J. and S. Josefsson, "Test Vectors for the
               Stream Cipher RC4", RFC 6229, May 2011.

Top      Up      ToC       Page 100 
Appendix A.  Constraints

   Updates to the Local Information Base, the Neighborhood Information
   Base, or the Topology Information Base MUST ensure that all
   constraints specified in this appendix are maintained, as well as
   those specified in [RFC6130].  This is the case for the processing,
   specified in this document.  Any protocol extension or outside
   process, which updates the Neighborhood Information Base or the
   Topology Information Base, MUST also ensure that these constraints
   are maintained.

   In each Originator Tuple:

   o  O_orig_addr MUST NOT equal any other O_orig_addr.

   o  O_orig_addr MUST NOT equal this router's originator address.

   In each Local Attached Network Tuple:

   o  AL_net_addr MUST NOT equal any other AL_net_addr.

   o  AL_net_addr MUST NOT equal or be a sub-range of any network
      address in the I_local_iface_addr_list of any Local Interface
      Tuple.

   o  AL_net_addr MUST NOT equal this router's originator address or
      equal the O_orig_addr in any Originator Tuple.

   o  AL_dist MUST NOT be less than zero.

   In each Link Tuple:

   o  L_neighbor_iface_addr_list MUST NOT contain any network address
      that AL_net_addr of any Local Attached Network Tuple equals or is
      a sub-range of.

   o  If L_in_metric != UNKNOWN_METRIC, then L_in_metric MUST be
      representable in the defined compressed form.

   o  If L_out_metric != UNKNOWN_METRIC, then L_out_metric MUST be
      representable in the defined compressed form.

   o  If L_mpr_selector = true, then L_status = SYMMETRIC.

Top      Up      ToC       Page 101 
   In each Neighbor Tuple:

   o  N_orig_addr MUST NOT be changed to unknown.

   o  N_orig_addr MUST NOT equal this router's originator address or
      equal O_orig_addr in any Originator Tuple.

   o  N_orig_addr MUST NOT equal the AL_net_addr in any Local Attached
      Network Tuple.

   o  If N_orig_addr != unknown, then N_orig_addr MUST NOT equal the
      N_orig_addr in any other Neighbor Tuple.

   o  N_neighbor_addr_list MUST NOT contain any network address that
      includes this router's originator address, the O_orig_addr in any
      Originator Tuple, or equal or have as a sub-range the AL_net_addr
      in any Local Attached Network Tuple.

   o  If N_orig_addr = unknown, then N_will_flooding = WILL_NEVER,
      N_will_routing = WILL_NEVER, N_flooding_mpr = false, N_routing_mpr
      = false, N_mpr_selector = false, and N_advertised = false.

   o  N_in_metric MUST equal the minimum value of the L_in_metric values
      of all corresponding Link Tuples with L_status = SYMMETRIC and
      L_in_metric != UNKNOWN_METRIC, if any; otherwise, N_in_metric =
      UNKNOWN_METRIC.

   o  N_out_metric MUST equal the minimum value of the L_out_metric
      values of all corresponding Link Tuples with L_status = SYMMETRIC
      and L_out_metric != UNKNOWN_METRIC, if any; otherwise,
      N_out_metric = UNKNOWN_METRIC.

   o  N_will_flooding and N_will_routing MUST be in the range from
      WILL_NEVER to WILL_ALWAYS, inclusive.

   o  If N_flooding_mpr = true, then N_symmetric MUST be true,
      N_out_metric MUST NOT equal UNKNOWN_METRIC, and N_will_flooding
      MUST NOT equal WILL_NEVER.

   o  If N_routing_mpr = true, then N_symmetric MUST be true,
      N_in_metric MUST NOT equal UNKNOWN_METRIC, and N_will_routing MUST
      NOT equal WILL_NEVER.

   o  If N_symmetric = true and N_flooding_mpr = false, then
      N_will_flooding MUST NOT equal WILL_ALWAYS.

   o  If N_symmetric = true and N_routing_mpr = false, then
      N_will_routing MUST NOT equal WILL_ALWAYS.

Top      Up      ToC       Page 102 
   o  If N_mpr_selector = true, then N_advertised MUST be true.

   o  If N_advertised = true, then N_symmetric MUST be true and
      N_out_metric MUST NOT equal UNKNOWN_METRIC.

   In each Lost Neighbor Tuple:

   o  NL_neighbor_addr MUST NOT include this router's originator
      address, the O_orig_addr in any Originator Tuple, or equal or have
      as a sub-range the AL_net_addr in any Local Attached Network
      Tuple.

   In each 2-Hop Tuple:

   o  N2_2hop_addr MUST NOT equal this router's originator address,
      equal the O_orig_addr in any Originator Tuple, or equal or have as
      a sub-range the AL_net_addr in any Local Attached Network Tuple.

   o  If N2_in_metric != UNKNOWN_METRIC, then N2_in_metric MUST be
      representable in the defined compressed form.

   o  If N2_out_metric != UNKNOWN_METRIC, then N2_out_metric MUST be
      representable in the defined compressed form.

   In each Advertising Remote Router Tuple:

   o  AR_orig_addr MUST NOT be in any network address in the
      I_local_iface_addr_list in any Local Interface Tuple or be in the
      IR_local_iface_addr in any Removed Interface Address Tuple.

   o  AR_orig_addr MUST NOT equal this router's originator address or
      equal the O_orig_addr in any Originator Tuple.

   o  AR_orig_addr MUST NOT be in the AL_net_addr in any Local Attached
      Network Tuple.

   o  AR_orig_addr MUST NOT equal the AR_orig_addr in any other
      Advertising Remote Router Tuple.

   In each Router Topology Tuple:

   o  There MUST be an Advertising Remote Router Tuple with AR_orig_addr
      = TR_from_orig_addr.

   o  TR_to_orig_addr MUST NOT be in any network address in the
      I_local_iface_addr_list in any Local Interface Tuple or be in the
      IR_local_iface_addr in any Removed Interface Address Tuple.

Top      Up      ToC       Page 103 
   o  TR_to_orig_addr MUST NOT equal this router's originator address or
      equal the O_orig_addr in any Originator Tuple.

   o  TR_to_orig_addr MUST NOT be in the AL_net_addr in any Local
      Attached Network Tuple.

   o  The ordered pair (TR_from_orig_addr, TR_to_orig_addr) MUST NOT
      equal the corresponding pair for any other Router Topology Tuple.

   o  TR_seq_number MUST NOT be greater than AR_seq_number in the
      Advertising Remote Router Tuple with AR_orig_addr =
      TR_from_orig_addr.

   o  TR_metric MUST be representable in the defined compressed form.

   In each Routable Address Topology Tuple:

   o  There MUST be an Advertising Remote Router Tuple with AR_orig_addr
      = TA_from_orig_addr.

   o  TA_dest_addr MUST be routable.

   o  TA_dest_addr MUST NOT overlap any network address in the
      I_local_iface_addr_list in any Local Interface Tuple or overlap
      the IR_local_iface_addr in any Removed Interface Address Tuple.

   o  TA_dest_addr MUST NOT include this router's originator address or
      include the O_orig_addr in any Originator Tuple.

   o  TA_dest_addr MUST NOT equal or have as a sub-range the AL_net_addr
      in any Local Attached Network Tuple.

   o  The ordered pair (TA_from_orig_addr, TA_dest_addr) MUST NOT equal
      the corresponding pair for any other Attached Network Tuple.

   o  TA_seq_number MUST NOT be greater than AR_seq_number in the
      Advertising Remote Router Tuple with AR_orig_addr =
      TA_from_orig_addr.

   o  TA_metric MUST be representable in the defined compressed form.

   In each Attached Network Tuple:

   o  There MUST be an Advertising Remote Router Tuple with AR_orig_addr
      = AN_orig_addr.

Top      Up      ToC       Page 104 
   o  AN_net_addr MUST NOT equal or be a sub-range of any network
      address in the I_local_iface_addr_list in any Local Interface
      Tuple or equal or be a sub-range of the IR_local_iface_addr in any
      Removed Interface Address Tuple.

   o  AN_net_addr MUST NOT equal this router's originator address or
      equal the O_orig_addr in any Originator Tuple.

   o  The ordered pair (AN_orig_addr, AN_net_addr) MUST NOT equal the
      corresponding pair for any other Attached Network Tuple.

   o  AN_seq_number MUST NOT be greater than AR_seq_number in the
      Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.

   o  AN_dist MUST NOT be less than zero.

   o  AN_metric MUST be representable in the defined compressed form.

Appendix B.  Example Algorithm for Calculating MPRs

   The following specifies an algorithm that MAY be used to select an
   MPR Set given a Neighbor Graph, as defined in Section 18.2 and
   Section 18.3.

   This algorithm selects an MPR Set M that is a subset of the set N1
   that is part of the Neighbor Graph.  This algorithm assumes that a
   subset I of N1 is pre-selected as MPRs, i.e., that M will contain I.

B.1.  Additional Notation

   The following additional notation, in addition to that in
   Section 18.2, will be used by this algorithm:

   N:
      A subset of N2, consisting of those elements y in N2 such that
      either d1(y) is not defined, or there is at least one x in N1 such
      that d(x,y) is defined and d(x,y) < d1(y).

   D(x):
      For an element x in N1, the number of elements y in N for which
      d(x,y) is defined and has minimal value among the d(z,y) for all z
      in N1.

   R(x,M):
      For an element x in N1, the number of elements y in N for which
      d(x,y) is defined has minimal value among the d(z,y) for all z in
      N1 and no such minimal values have z in M.  (Note that, denoting
      the empty set by 0, D(x) = R(x,0).)

Top      Up      ToC       Page 105 
B.2.  MPR Selection Algorithm

   To create the MPR Set M, starting with M := I:

   1.  Add all elements x in N1 that have W(x) = WILL_ALWAYS to M.

   2.  For each element y in N for which there is only one element x in
       N1 such that d2(x,y) is defined, add that element x to M.

   3.  While there exists any element x in N1 with R(x,M) > 0:

       1.  Select an element x in N1 with R(x,M) > 0 in the following
           order of priority, and then add to M:

           +  greatest W(x), THEN

           +  greatest R(x,M), THEN

           +  greatest D(x), THEN

           +  any choice, which MAY be based on other criteria (for
              example, a router MAY choose to prefer a neighbor as an
              MPR if that neighbor has already selected the router as an
              MPR of the same type, MAY prefer a neighbor based on
              information freshness, or MAY prefer a neighbor based on
              length of time previously selected as an MPR) or MAY be
              random.

   4.  OPTIONAL: consider each element x in M, but not in I, in turn and
       if x can be removed from M while still leaving it satisfying the
       definition of an MPR Set, then remove that element x from M.
       Elements MAY be considered in any order, e.g., in order of
       increasing W(x).

Appendix C.  Example Algorithm for Calculating the Routing Set

   The following procedure is given as an example for calculating the
   Routing Set using a variation of Dijkstra's algorithm.  First, all
   Routing Tuples are removed, and then, using the selections and
   definitions in Appendix C.1, the procedures in the following sections
   (each considered a "stage" of the processing) are applied in turn.

Top      Up      ToC       Page 106 
C.1.  Local Interfaces and Neighbors

   The following selections and definitions are made:

   1.  For each Local Interface Tuple, select a network address from its
       I_local_iface_addr_list.  This is defined as the selected address
       for this Local Interface Tuple.

   2.  For each Link Tuple, the selected address of its corresponding
       Local Interface Tuple is defined as the selected local address
       for this Link Tuple.

   3.  For each Neighbor Tuple with N_symmetric = true and N_out_metric
       != UNKNOWN_METRIC, select a Link Tuple with L_status = SYMMETRIC
       for which this is the corresponding Neighbor Tuple and has
       L_out_metric = N_out_metric.  This is defined as the selected
       Link Tuple for this Neighbor Tuple.

   4.  For each network address (N_orig_addr or in N_neighbor_addr_list,
       the "neighbor address") from a Neighbor Tuple with N_symmetric =
       true and N_out_metric != UNKNOWN_METRIC, select a Link Tuple (the
       "selected Link Tuple") from those for which this is the
       corresponding Neighbor Tuple, have L_status = SYMMETRIC, and have
       L_out_metric = N_out_metric, by:

       1.  If there is such a Link Tuple whose
           L_neighbor_iface_addr_list contains the neighbor address,
           select that Link Tuple.

       2.  Otherwise, select the selected Link Tuple for this Neighbor
           Tuple.

       Then for this neighbor address:

       3.  The selected local address is defined as the selected local
           address for the selected Link Tuple.

       4.  The selected link address is defined as an address from the
           L_neighbor_iface_addr_list of the selected Link Tuple, if
           possible equal to this neighbor address.

   5.  Routing Tuple preference is decided by preference for minimum
       R_metric, then for minimum R_dist, and then for preference for
       corresponding Neighbor Tuples in this order:

       *  For greater N_will_routing.

       *  For N_mpr_selector = true over N_mpr_selector = false.

Top      Up      ToC       Page 107 
       Note that preferred Routing Tuples SHOULD be used.  Routing
       Tuples with minimum R_metric MUST be used; this is specified
       outside the definition of preference.  An implementation MAY
       modify this definition of preference (including for minimum
       R_dist) without otherwise affecting this algorithm.

C.2.  Add Neighbor Routers

   The following procedure is executed once.

   1.  For each Neighbor Tuple with N_symmetric = true and N_out_metric
       != UNKNOWN_METRIC, add a Routing Tuple with:

       *  R_dest_addr := N_orig_addr;

       *  R_next_iface_addr := selected link address for N_orig_addr;

       *  R_local_iface_addr := selected local address for N_orig_addr;

       *  R_metric := N_out_metric;

       *  R_dist := 1.

C.3.  Add Remote Routers

   The following procedure is executed once.

   1.  Add a label that may be "used" or "unused" to each Routing Tuple,
       with all initial values equal to unused.  (Note that this label
       is only required during this algorithm.)

   2.  If there are no unused Routing Tuples, then this stage is
       complete; otherwise, repeat the following until that is the case.

       1.  Find the unused Routing Tuple with minimum R_metric (if more
           than one, pick any) and denote it the "current Routing
           Tuple".

       2.  Mark the current Routing Tuple as used.

       3.  For each Router Topology Tuple, with
           TR_from_orig_addr = R_dest_addr of the current Routing Tuple:

           1.  Define:

               -  new_metric := R_metric of the current Routing Tuple +
                  TR_metric;

Top      Up      ToC       Page 108 
               -  new_dist := R_dist of the current Routing Tuple + 1.

           2.  If there is no Routing Tuple with R_dest_addr =
               TR_to_orig_addr, then create an unused Routing Tuple
               with:

               -  R_dest_addr := TR_to_orig_addr;

               -  R_next_iface_addr := R_next_iface_addr of the current
                  Routing Tuple;

               -  R_local_iface_addr := R_local_iface_addr of the
                  current Routing Tuple;

               -  R_metric := new_metric;

               -  R_dist := new_dist.

           3.  Otherwise, if there is an unused Routing Tuple with
               R_dest_addr = TR_to_orig_addr, and either new_metric <
               R_metric or (new_metric = R_metric and the updated
               Routing Tuple would be preferred), then update this
               Routing Tuple to have:

               -  R_next_iface_addr := R_next_iface_addr of the current
                  Routing Tuple;

               -  R_local_iface_addr := R_local_iface_addr of the
                  current Routing Tuple;

               -  R_metric := new_metric;

               -  R_dist := new_dist.

C.4.  Add Neighbor Addresses

   The following procedure is executed once.

   1.  For each Neighbor Tuple with N_symmetric = true and N_out_metric
       != UNKNOWN_METRIC:

       1.  For each network address (the "neighbor address") in
           N_neighbor_addr_list, if the neighbor address is not equal to
           the R_dest_addr of any Routing Tuple, then add a new Routing
           Tuple, with:

           +  R_dest_addr := neighbor address;

Top      Up      ToC       Page 109 
           +  R_next_iface_addr := selected link address for the
              neighbor address;

           +  R_local_iface_addr := selected local address for the
              neighbor address;

           +  R_metric := N_out_metric;

           +  R_dist := 1.

C.5.  Add Remote Routable Addresses

   The following procedure is executed once.

   1.  For each Routable Address Topology Tuple, if:

       *  TA_dest_addr is not equal to the R_dest_addr of any Routing
          Tuple added in an earlier stage; AND

       *  TA_from_orig_addr is equal to the R_dest_addr of a Routing
          Tuple (the "previous Routing Tuple"),

       then add a new Routing Tuple, with:

       *  R_dest_addr := TA_dest_addr;

       *  R_next_iface_addr := R_next_iface_addr of the previous Routing
          Tuple;

       *  R_local_iface_addr := R_local_iface_addr of the previous
          Routing Tuple;

       *  R_metric := R_metric of the previous Routing Tuple +
          TA_metric;

       *  R_dist := R_dist of the previous Routing Tuple + 1.

       There may be more than one Routing Tuple that may be added for an
       R_dest_addr in this stage.  If so, then for each such
       R_dest_addr, a Routing Tuple with minimum R_metric MUST be added;
       otherwise, a Routing Tuple that is preferred SHOULD be added.

Top      Up      ToC       Page 110 
C.6.  Add Attached Networks

   The following procedure is executed once.

   1.  For each Attached Network Tuple, if:

       *  AN_net_addr is not equal to the R_dest_addr of any Routing
          Tuple added in an earlier stage; AND

       *  AN_orig_addr is equal to the R_dest_addr of a Routing Tuple
          (the "previous Routing Tuple"),

       then add a new Routing Tuple, with:

       *  R_dest_addr := AN_net_addr;

       *  R_next_iface_addr := R_next_iface_addr of the previous Routing
          Tuple;

       *  R_local_iface_addr := R_local_iface_addr of the previous
          Routing Tuple;

       *  R_metric := R_metric of the previous Routing Tuple +
          AN_metric;

       *  R_dist := R_dist of the previous Routing Tuple + AN_dist.

       There may be more than one Routing Tuple that may be added for an
       R_dest_addr in this stage.  If so, then for each such
       R_dest_addr, a Routing Tuple with minimum R_metric MUST be added;
       otherwise, a Routing Tuple that is preferred SHOULD be added.

C.7.  Add 2-Hop Neighbors

   The following procedure is OPTIONAL according to Section 19.1 and MAY
   be executed once.

   1.  For each 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC, if:

       *  N2_2hop_addr is a routable address; AND

       *  N2_2hop_addr is not equal to the R_dest_addr of any Routing
          Tuple added in an earlier stage; AND

       *  the Routing Tuple with R_dest_addr = N_orig_addr of the
          corresponding Neighbor Tuple (the "previous Routing Tuple")
          has R_dist = 1,

Top      Up      ToC       Page 111 
       then add a new Routing Tuple, with:

       *  R_dest_addr := N2_2hop_addr;

       *  R_next_iface_addr := R_next_iface_addr of the previous Routing
          Tuple;

       *  R_local_iface_addr := R_local_iface_addr of the previous
          Routing Tuple;

       *  R_metric := R_metric of the previous Routing Tuple +
          N_out_metric of the corresponding Neighbor Tuple;

       *  R_dist := 2.

       There may be more than one Routing Tuple that may be added for an
       R_dest_addr in this stage.  If so, then for each such
       R_dest_addr, a Routing Tuple with minimum R_metric MUST be added;
       otherwise, a Routing Tuple that is preferred SHOULD be added.

Appendix D.  TC Message Example

   TC messages are instances of [RFC5444] messages.  This specification
   requires that TC messages contain <msg-hop-limit> and <msg-orig-addr>
   fields.  It supports TC messages with any combination of remaining
   message header options and address encodings enabled by [RFC5444]
   that convey the required information.  As a consequence, there is no
   single way to represent how all TC messages look.  This appendix
   illustrates a TC message; the exact values and content included are
   explained in the following text.

   The TC message's four-bit Message Flags (MF) field has a value of 15,
   indicating that the message header contains originator address, hop
   limit, hop count, and message sequence number fields.  Its four-bit
   Message Address Length (MAL) field has value 3, indicating addresses
   in the message have a length of four octets, here being IPv4
   addresses.  The overall message length is 75 octets.

   The message has a Message TLV Block with a content length of 17
   octets containing four TLVs.  The first two TLVs are validity and
   interval times for the message.  The third TLV is the content
   sequence number TLV used to carry the 2-octet ANSN and (with default
   type extension zero, i.e., COMPLETE) indicates that the TC message is
   complete.  The fourth TLV contains forwarding and routing willingness
   values for the originating router (FWILL and RWILL, respectively).
   Each TLV uses a TLV with Flags octet (MTLVF) value 16, indicating

Top      Up      ToC       Page 112 
   that it has a Value, but no type extension or start and stop indexes.
   The first two TLVs have a Value Length of 1 octet; the last has a
   Value Length of 2 octets.

   The message has two Address Blocks.  (This is not necessary.  The
   information could be conveyed using a single Address Block; the use
   of two Address Blocks, which is also allowed, is illustrative only.)
   The first Address Block contains 3 addresses, with Flags octet (ABF)
   value 128, hence with a Head section (with length 2 octets) but no
   Tail section and with Mid sections with length two octets.  The
   following TLV Block (content length 13 octets) contains two TLVs.
   The first TLV is a NBR_ADDR_TYPE TLV with Flags octet (ATLVF) value
   16, indicating a single Value but no indexes.  Thus, all these
   addresses are associated with the Value (with Value Length 1 octet)
   ROUTABLE_ORIG, i.e., they are originator addresses of advertised
   neighbors that are also routable addresses.  The second TLV is a
   LINK_METRIC TLV with Flags octet (ATLVF) value 20, indicating a Value
   for each address, i.e., as the total Value Length is 6 octets, each
   address is associated with a Value with length two octets.  These
   Value fields are each shown as having four bits indicating that they
   are outgoing neighbor metric values and as having twelve bits that
   represent the metric value (the first four bits being the exponent,
   the remaining eight bits the mantissa).

   The second Address Block contains 1 address, with Flags octet (ATLVF)
   176, indicating that there is a Head section (with length 2 octets),
   that the Tail section (with length 2 octets) consists of zero valued
   octets (not included), and that there is a single prefix length,
   which is 16.  The network address is thus Head.0.0/16.  The following
   TLV Block (content length 9 octets) includes two TLVs.  The first has
   a Flags octet (ATLVF) of 16, again indicating that no indexes are
   needed, but that a Value (with Value Length 1 octet) is present,
   indicating the address distance as a number of hops.  The second TLV
   is another LINK_METRIC TLV, as in the first Address TLV Block except
   with a Flags octet (ATLVF) value 16, indicating that a single Value
   is present.

Top      Up      ToC       Page 113 
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      TC       | MF=15 | MAL=3 |      Message Length = 75      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message TLV Block Length = 17 | VALIDITY_TIME |  MTLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 1 | Value (Time)  | INTERVAL_TIME |  MTLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 1 | Value (Time)  | CONT_SEQ_NUM  |  MTLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 2 |         Value (ANSN)          |  MPR_WILLING  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MTLVF = 16   | Value Len = 1 | FWILL | RWILL | Num Addrs = 3 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   ABF = 128   | Head Len = 2  |             Head              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              | Address TLV Block Length = 13 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | NBR_ADDR_TYPE |  ATLVF = 16   | Value Len = 1 | ROUTABLE_ORIG |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  LINK_METRIC  |  ATLVF = 20   | Value Len = 6 |0|0|0|1|Metric |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Metric (cont) |0|0|0|1|        Metric         |0|0|0|1|Metric |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Metric (cont) | Num Addrs = 1 |   ABF = 176   | Head Len = 2  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Head              | Tail Len = 2  | Pref Len = 16 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address TLV Block Length = 9  |    GATEWAY    |  ATLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 1 | Value (Hops)  |  LINK_METRIC  |  ATLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 2 |0|0|0|1|        Metric         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 114 
Appendix E.  Flow and Congestion Control

   Due to its proactive nature, this protocol has a natural control over
   the flow of its control traffic.  Routers transmit control messages
   at predetermined rates specified and bounded by message intervals.

   This protocol employs [RFC6130] for local signaling, embedding MPR
   selection advertisement through a simple Address Block TLV and router
   willingness advertisement (if any) as a single Message TLV.  Local
   signaling, therefore, shares the characteristics and constraints of
   [RFC6130].

   Furthermore, the use of MPRs can greatly reduce the signaling
   overhead from link state information dissemination in two ways,
   attaining both flooding reduction and topology reduction.  First,
   using MPR flooding, the cost of distributing link state information
   throughout the network is reduced, as compared to when using blind
   flooding, since only MPRs need to forward link state declaration
   messages.  Second, the amount of link state information for a router
   to declare is reduced; it only needs to contain that router's MPR
   selectors.  This reduces the size of a link state declaration as
   compared to declaring full link state information.  In particular,
   some routers may not need to declare any such information.  In dense
   networks, the reduction of control traffic can be of several orders
   of magnitude compared to routing protocols using blind flooding
   [MPR].  This feature naturally provides more bandwidth for useful
   data traffic and further pushes the frontier of congestion.

   Since the control traffic is continuous and periodic, it keeps the
   quality of the links used in routing more stable.  However, using
   some options, some control messages (HELLO messages or TC messages)
   may be intentionally sent in advance of their deadline in order to
   increase the responsiveness of the protocol to topology changes.
   This may cause a small, temporary, and local increase of control
   traffic; however, this is at all times bounded by the use of minimum
   message intervals.

   A router that recognizes that the network is suffering from
   congestion can increase its message interval parameters.  If this is
   done by most or all routers in the network, then the overall control
   traffic in the network will be reduced.  When using this capability,
   routers will have to take care not to increase message interval
   parameters such that they cannot cope with network topology changes.
   Note that routers can make such decisions independently; it is not
   necessary for all routers to be using the same parameter values, nor
   is it necessary that all routers decide to change their intervals at
   the same time.

Top      Up      ToC       Page 115 
Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/


   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/


   Philippe Jacquet
   Alcatel-Lucent Bell Labs

   Phone: +33 6 7337 1880
   EMail: philippe.jacquet@alcatel-lucent.com


   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 E. Arques Ave.
   Sunnyvale, CA  94085
   USA

   EMail: ulrich@herberg.name
   URI:   http://www.herberg.name/