Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7181

The Optimized Link State Routing Protocol Version 2

Pages: 115
Proposed Standard
Errata
Updated by:  7183718771887466
Part 5 of 5 – Pages 84 to 115
First   Prev   None

Top   ToC   RFC7181 - Page 84   prevText

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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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   ToC   RFC7181 - 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/