RFC 7181
The Optimized Link State Routing Protocol Version 2
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
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.
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
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
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.
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.
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].
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 Assignment24.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
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
+--------------+------+-----------+--------------------+------------+ | 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
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
+---------------+------+-----------+-------------------+------------+ | 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].
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>
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.
[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.
[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.
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.
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.
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.
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.
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).)
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.
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.
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;
- 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;
+ 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.
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,
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
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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/