diff options
Diffstat (limited to 'doc/rfc/rfc6130.txt')
| -rw-r--r-- | doc/rfc/rfc6130.txt | 4931 |
1 files changed, 4931 insertions, 0 deletions
diff --git a/doc/rfc/rfc6130.txt b/doc/rfc/rfc6130.txt new file mode 100644 index 0000000..553a0b9 --- /dev/null +++ b/doc/rfc/rfc6130.txt @@ -0,0 +1,4931 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Clausen +Request for Comments: 6130 LIX, Ecole Polytechnique +Category: Standards Track C. Dearlove +ISSN: 2070-1721 BAE Systems ATC + J. Dean + Naval Research Laboratory + April 2011 + + + Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) + +Abstract + + This document describes a 1-hop and symmetric 2-hop neighborhood + discovery protocol (NHDP) for mobile ad hoc networks (MANETs). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6130. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + + + +Clausen, et al. Standards Track [Page 1] + +RFC 6130 MANET-NHDP April 2011 + + + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction .....................................................4 + 1.1. Motivation .................................................5 + 2. Terminology .....................................................6 + 3. Applicability Statement .........................................9 + 4. Protocol Overview and Functioning ..............................10 + 4.1. Routers and Interfaces ....................................11 + 4.2. Information Base Overview .................................12 + 4.2.1. Local Information Base .............................13 + 4.2.2. Interface Information Bases ........................13 + 4.2.3. Neighbor Information Base ..........................14 + 4.3. Signaling Overview ........................................14 + 4.3.1. HELLO Message Generation ...........................15 + 4.3.2. HELLO Message Content ..............................16 + 4.3.3. HELLO Message Processing ...........................17 + 4.4. Link Quality ..............................................17 + 5. Protocol Parameters and Constants ..............................18 + 5.1. Protocol and Port Numbers .................................18 + 5.2. Multicast Address .........................................18 + 5.3. Interface Parameters ......................................18 + 5.3.1. Message Intervals ..................................19 + 5.3.2. Information Validity Times .........................21 + 5.3.3. Link Quality .......................................22 + 5.3.4. Jitter .............................................22 + 5.4. Router Parameters .........................................23 + 5.4.1. Information Validity Time ..........................23 + 5.5. Parameter Change Constraints ..............................23 + 5.6. Constants .................................................24 + 6. Local Information Base .........................................24 + 6.1. Local Interface Set .......................................25 + 6.2. Removed Interface Address Set .............................26 + 7. Interface Information Bases ....................................26 + 7.1. Link Set ..................................................27 + 7.2. 2-Hop Set .................................................28 + 8. Neighbor Information Base ......................................28 + 8.1. Neighbor Set ..............................................28 + 8.2. Lost Neighbor Set .........................................29 + 9. Local Information Base Changes .................................29 + + + +Clausen, et al. Standards Track [Page 2] + +RFC 6130 MANET-NHDP April 2011 + + + 9.1. Adding an Interface .......................................29 + 9.2. Removing an Interface .....................................30 + 9.3. Adding a Network Address to an Interface ..................30 + 9.4. Removing a Network Address from an Interface ..............31 + 10. Packets and Messages ..........................................32 + 10.1. HELLO Messages ...........................................32 + 10.1.1. Address Blocks ....................................33 + 11. HELLO Message Generation ......................................34 + 11.1. HELLO Message Specification ..............................35 + 11.2. HELLO Message Transmission ...............................37 + 11.2.1. HELLO Message Jitter ..............................37 + 12. HELLO Message Processing ......................................38 + 12.1. Invalid Message ..........................................38 + 12.2. Definitions ..............................................40 + 12.3. Updating the Neighbor Set ................................41 + 12.4. Updating the Lost Neighbor Set ...........................42 + 12.5. Updating the Link Sets ...................................42 + 12.6. Updating the 2-Hop Set ...................................44 + 13. Other Information Base Changes ................................45 + 13.1. Link Tuple Symmetric .....................................46 + 13.2. Link Tuple Not Symmetric .................................47 + 13.3. Link Tuple Heard Timeout .................................48 + 14. Link Quality ..................................................48 + 14.1. Deployment without Link Quality ..........................49 + 14.2. Basic Principles of Link Quality .........................49 + 14.3. When Link Quality Changes ................................50 + 14.4. Updating Link Quality ....................................51 + 15. Proposed Values for Parameters and Constants ..................51 + 15.1. Message Interval Interface Parameters ....................51 + 15.2. Information Validity Time Interface Parameters ...........51 + 15.3. Information Validity Time Router Parameters ..............52 + 15.4. Link Quality Interface Parameters ........................52 + 15.5. Jitter Interface Parameters ..............................52 + 15.6. Constants ................................................52 + 16. Usage with Other Protocols ....................................52 + 17. Security Considerations .......................................54 + 17.1. Invalid HELLO Messages ...................................56 + 17.2. Authentication, Integrity, and Confidentiality + Suggestions ..............................................57 + 18. IANA Considerations ...........................................57 + 18.1. Expert Review: Evaluation Guidelines .....................58 + 18.2. Message Types ............................................58 + 18.3. Message-Type-Specific TLV Type Registries ................58 + 18.4. Address Block TLV Types ..................................59 + 18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values ...........60 + 19. Contributors ..................................................61 + 20. Acknowledgments ...............................................61 + 21. References ....................................................62 + + + +Clausen, et al. Standards Track [Page 3] + +RFC 6130 MANET-NHDP April 2011 + + + 21.1. Normative References .....................................62 + 21.2. Informative References ...................................62 + Appendix A. Address Block TLV Combinations ........................63 + Appendix B. Constraints ...........................................64 + Appendix C. HELLO Message Example .................................66 + Appendix D. Flow and Congestion Control ...........................69 + Appendix E. Interval and Timer Illustrations ......................70 + E.1. HELLO Message Generation Timing ..........................70 + E.2. HELLO Message Processing Timing ..........................76 + E.3. Other HELLO Message Timing ...............................77 + Appendix F. Topology Pictures ....................................79 + F.1. Example 1: Standard Single Interface Topology ............79 + F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor ....80 + F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor ....81 + F.4. Example 4: Dual Addressed Interfaces .....................81 + F.5. Example 5: Dual Interface on 2-Hop Neighbor ..............82 + F.6. Example 6: Dual interface on 1-Hop Neighbor ..............82 + F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors ...83 + F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor ..84 + F.9. Example 9: Dual Interface on All Routers .................85 + F.10. Example 10: Dual Addressed Dual Interfaces on All + Routers ......................................86 + F.11. Example 11: Single Addressed Dual Interface Locally ......87 + +1. Introduction + + This document describes a neighborhood discovery protocol (NHDP) for + a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a + local exchange of HELLO messages so that each router can determine + the presence of, and connectivity to, its 1-hop and symmetric 2-hop + neighbors. Messages are defined and sent in packets according to the + specification [RFC5444]. + + 1-hop neighborhood information is recorded for use by MANET routing + protocols to determine direct (1-hop) connectivity to neighboring + routers. 2-hop symmetric neighborhood information is recorded so as + to enable MANET routing protocols to employ flooding reduction + techniques, e.g., to select reduced relay sets for efficient network- + wide traffic dissemination. + + 1-hop and symmetric 2-hop neighborhood information is recorded in the + form of Information Bases. These are available for use by other + protocols, such as MANET routing protocols, that require information + regarding the local network connectivity. This protocol is designed + to maintain the information in these Information Bases even in the + presence of a dynamic network topology and wireless communication + channel characteristics. + + + + +Clausen, et al. Standards Track [Page 4] + +RFC 6130 MANET-NHDP April 2011 + + + This protocol makes no assumptions about the underlying link layer, + other than support of local broadcast or multicast for communication + to 1-hop neighbor routers. Link-layer information may be used if + available and applicable. + + This protocol is based on the neighborhood discovery process + contained in the Optimized Link State Routing (OLSR) Protocol + [RFC3626]. + +1.1. Motivation + + MANETs differ from more traditional wired and infrastructure-based + wireless networks due to their envisioned applicability over more + challenging communication channels (e.g., wireless, lossy, broadcast + channels with moderate and shared bandwidth, hidden and exposed + terminals, and interference from other network devices and the + environment) and in more challenging topological conditions (e.g., + rapid and unpredictable mobility, dynamic and non-predetermined + network membership). + + Due to the properties of wireless transmissions, communication + between two neighboring routers may not be bi-directional; even if + router A is able to receive packets from router B, the converse is + not guaranteed to be true. Furthermore, because of the localized + nature of wireless broadcast communication, neighboring routers + within the same communications channel may have different sets of + neighbors. That is, when using the same communication channel, even + if router A is able to exchange packets with router B, and router B + is able to exchange packets with router C, this does not guarantee + that router A and router C can exchange packets directly. + + Each router in a MANET may use more than one communication channel. + In particular, between the same pair of routers, more than one + distinct communication channel may exist, each with different + properties. This may, for example, be the case where MANET routers + are equipped with multiple distinct wireless interfaces, operating at + different frequencies. + + For use by MANET routing protocols, as well as for establishing a + router's neighbors, a router may also need to determine whether each + communication channel with that neighbor is bi-directional. + + The set of neighbor routers of a given MANET router may be + continuously changing, often due to router mobility or a changing + physical environment in which the MANET is located. There is + typically no information from lower layers that would enable an IP + routing protocol to detect and, as appropriate, react to such + changes. Such changes can often take place on a short timescale, + + + +Clausen, et al. Standards Track [Page 5] + +RFC 6130 MANET-NHDP April 2011 + + + such as of the order of seconds, requiring MANET routing protocols to + act rapidly to ensure suitable convergence properties. + + MANET routing protocols, for example [RFC3626] and [RFC5449], often + employ relay set reductions in order to conserve network capacity + when maintaining network-wide topological information, with + calculation of these reduced relay sets employing up to two hop + information. + + The neighborhood discovery protocol specified in this document + provides continued tracking of neighborhood changes, link bi- + directionality, and local topological information up to two hops. + Combined, this allows a MANET routing protocol access to information + describing link establishment/disappearance and provides the + necessary topological information for reduced relay set selection and + other purposes. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + All terms introduced in [RFC5444], including "packet", "message", + "Address Block", "TLV Block", "TLV", "address", "address prefix", and + "address object" are to be interpreted as described therein. + + Additionally, this document uses the following terminology: + + Network Address: + An address plus an associated prefix length. This may be an + address with an associated maximum prefix length or an address + prefix including a prefix length. A network address thus + represents a range of addresses. + + Router: + A MANET router that implements this neighborhood discovery + protocol. + + Interface: + A router's attachment to a communications medium. An interface is + assigned one or more addresses. + + MANET interface: + An interface participating in a MANET and using this neighborhood + discovery protocol. A router may have several MANET interfaces. + + + + +Clausen, et al. Standards Track [Page 6] + +RFC 6130 MANET-NHDP April 2011 + + + Heard: + A MANET interface of router X is considered heard on a MANET + interface of a router Y if the latter can receive control + messages, according to this specification, from the former. + + Link: + A link between two MANET interfaces exists if either can be heard + by the other. + + Symmetric link: + A symmetric link between two MANET interfaces exists if both can + be heard by the other. + + 1-hop neighbor: + A router X is a 1-hop neighbor of a router Y if a MANET interface + of router X is heard by a MANET interface of router Y. + + Symmetric 1-hop neighbor: + A router X is a symmetric 1-hop neighbor of a router Y if a + symmetric link exists between a MANET interface on router X and a + MANET interface on router Y. + + 2-hop neighbor: + A router X is a 2-hop neighbor of a router Y if router X is a + 1-hop neighbor of a 1-hop neighbor of router Y, but is not router + Y itself. + + Symmetric 2-hop neighbor: + A router X is a symmetric 2-hop neighbor of a router Y if router X + is a symmetric 1-hop neighbor of a symmetric 1-hop neighbor of + router Y, but is not router Y itself. + + 1-hop neighborhood: + The 1-hop neighborhood of a router X is the set of the 1-hop + neighbors of router X. + + Symmetric 1-hop neighborhood: + The symmetric 1-hop neighborhood of a router X is the set of the + symmetric 1-hop neighbors of router X. + + 2-hop neighborhood: + The 2-hop neighborhood of a router X is the set of the 2-hop + neighbors of router X. (This may include routers in the 1-hop + neighborhood of router X.) + + + + + + + +Clausen, et al. Standards Track [Page 7] + +RFC 6130 MANET-NHDP April 2011 + + + Symmetric 2-hop neighborhood: + The symmetric 2-hop neighborhood of a router X is the set of the + symmetric 2-hop neighbors of router X. (This may include routers + in the 1-hop neighborhood, or even in the symmetric 1-hop + neighborhood, of router X.) + + Constant: + A numerical value that MUST be the same for all MANET interfaces + of all routers in the MANET, at all times. + + Interface parameter: + A boolean or numerical value, specified separately for each MANET + interface of each router. A router MAY change interface parameter + values at any time, subject to some constraints. + + Router parameter: + A boolean or numerical value, specified for each router, and not + specific to an interface. A router MAY change router parameter + values at any time, subject to some constraints. + + Information Base: + A collection of information maintained by this protocol and which + is to be made available to MANET routing protocols. An + Information Base may be associated with a MANET interface or with + a router. + + Furthermore, this document uses the following notational conventions: + + X contains y, or y is contained in X + An unordered list membership operator. X is an unordered list and + y is an element. "X contains y" or "y is contained in X" returns + true if the unordered list X includes the element y, and returns + false otherwise. + + X contains Y, or Y is contained in X + An unordered list inclusion operator. X and Y are both unordered + lists. "X contains Y" or "Y is contained in X" returns true if + the unordered list X contains all elements y which are contained + in Y, and returns false otherwise. + + A overlaps B + If A and B are network addresses, and the range of addresses + represented by A and the range of addresses represented by B both + contain at least one common address. (This is only possible if + one range is a sub-range of the other.) + + + + + + +Clausen, et al. Standards Track [Page 8] + +RFC 6130 MANET-NHDP April 2011 + + + a := b + An assignment operator, whereby the left side (a) is assigned the + value of the right side (b). a and b may be values, network + addresses, or unordered lists (they must be of the same type). + + c = d + A comparison operator, returning true if the value of the left + side (c) is equal to the value of the right side (d). c and d may + be values, network addresses, or unordered lists (they must be of + the same type). If c and d are unordered lists, then they are + considered to be equal if c contains d and d contains c (i.e., + they contain the same set of elements, regardless of the order in + which they are recorded in the lists). If c and d are network + addresses, they are considered equal only if both addresses and + prefix lengths are equal (i.e., they represent the same). + + e != f + A comparison operator, returning not (e = f), i.e., returning true + where (e = f) would have returned false, and returning false where + (e = f) would have returned true. + +3. Applicability Statement + + This protocol: + + o Is applicable to networks, especially wireless networks, in which + unknown neighbors can be reached by local broadcast or multicast + packets. + + o Is designed to work in networks with a dynamic topology, and in + which messages may be lost, such as due to collisions in wireless + networks. + + o Supports routers that each have one or more participating MANET + interfaces. The set of a router's interfaces may change over + time. Each interface may have one or more associated network + addresses, and these may also be dynamically changing. + + o Provides each router with current local topology information up to + two hops away, and makes this local topology information available + to MANET routing protocols in Information Bases. + + o Uses the packet and message formats specified in [RFC5444]. This + includes the definition of a HELLO Message Type, used for + signaling local topology information. + + o Allows "external" and "internal" extensibility as enabled by + [RFC5444]. + + + +Clausen, et al. Standards Track [Page 9] + +RFC 6130 MANET-NHDP April 2011 + + + o May interact with, and be extended by, other protocols, such as + MANET routing protocols, see Section 16. + + o Can use relevant link-layer information if it is available. + + o Is designed to work in a completely distributed manner, and does + not depend on any central entity. + +4. Protocol Overview and Functioning + + The objective of this protocol is, for each router: + + o To identify 1-hop neighbors and symmetric 1-hop neighbors of this + router. + + o To find the interface network addresses of the router's symmetric + 2-hop neighbors. + + o To record this information in Information Bases and thus make this + information available to other protocols that use this + neighborhood discovery protocol. + + o To be available for use by other protocols, which MAY extend the + information in these Information Bases, including adding new Sets + to Information Bases, new elements to protocol Tuples and new TLVs + to be included in outgoing HELLO messages and processed when in + incoming HELLO messages. + + These objectives are achieved using local (1-hop) signaling that: + + o Advertises the presence of a router and its interface network + addresses. + + o Discovers links from neighboring routers. + + o Performs bi-directionality checks on the discovered links. + + o Advertises discovered links, and whether each is symmetric, to its + 1-hop neighbors, and hence discovers symmetric 2-hop neighbors. + + This specification defines, in turn: + + o Parameters and constants used by the protocol. Parameters used by + this protocol may, where appropriate, be specific to a given MANET + interface or to a MANET router. This protocol allows all + parameters to be changed dynamically, and to be set independently + for each MANET router or MANET interface, as appropriate. + + + + +Clausen, et al. Standards Track [Page 10] + +RFC 6130 MANET-NHDP April 2011 + + + o The Information Bases describing local interfaces, discovered + links and their status, current and former 1-hop neighbors, and + symmetric 2-hop neighbors. + + o The format of the HELLO message that is used for local signaling. + + o The generation of HELLO messages from some of the information in + the Information Bases. + + o The updating of the Information Bases according to received HELLO + messages and other events. + + o The response to other events, such as the expiration of + information in the Information Bases. + +4.1. Routers and Interfaces + + In order for a router to participate in a MANET, it MUST have at + least one, and possibly more, MANET interfaces. + + Each MANET interface: + + o Is configured with one or more network addresses. Each address in + the range of addresses represented by that network address MUST + satisfy the following properties: + + o It MUST be unique to this router, i.e., it MUST NOT be assigned + to any interface of any other router. + + o If assigned to other MANET interfaces, on the same router, + these MANET interfaces MUST be isolated, i.e., addresses may + only be assigned to different interfaces on the same router if + no MANET interface on another router can communicate with both. + For example, interfaces using distinct radio "channels" MAY be + assigned the same address. + + o Has a set of interface parameters, defining the behavior of this + MANET interface. Each MANET interface MAY be individually + parameterized. + + o Has an Interface Information Base, recording information regarding + links to this MANET interface and symmetric 2-hop neighbors that + can be reached through such links. + + o Generates and processes HELLO messages. + + + + + + +Clausen, et al. Standards Track [Page 11] + +RFC 6130 MANET-NHDP April 2011 + + + In addition to a set of MANET interfaces as described above, each + router has: + + o A Local Information Base, containing the network addresses of the + interfaces (MANET and non-MANET) of this router. The contents of + this Information Base are not changed by signaling. + + o A Neighbor Information Base, recording information regarding + current and recently lost 1-hop neighbors of this router. + + A router may have both MANET interfaces and non-MANET interfaces. + Interfaces of both of these types are recorded in a router's Local + Information Base, which is used, but not updated, by the signaling of + this protocol. + +4.2. Information Base Overview + + Each router maintains protocol state using Information Bases, + described in the following sections. Each Information Base consists + of a number of Protocol Sets. Each Protocol Set contains a number of + Protocol Tuples. + + An implementation of this protocol MAY maintain this information in + the indicated form, or in any other organization that offers access + to this information. In particular, note that it is not necessary to + remove Protocol Tuples from Protocol Sets at the exact time + indicated, only to behave as if the Protocol Tuples were removed at + that time. + + Information in the Local Information Base is defined locally and + included in HELLO messages. Information in the Interface Information + Base and the Neighbor Information Base is determined from received + HELLO messages; some of this information may also be included in + transmitted HELLO messages. Such information has a limited duration + in which it is considered valid. This duration is determined from + the VALIDITY_TIME TLV in the HELLO message in which the information + is received, which in turn is set by the router that originated the + HELLO message, using its corresponding interface parameter + H_HOLD_TIME. + + Appendix E illustrates the relationship between message reception, + included VALIDITY_TIME TLVs, and the duration for which information + received in a HELLO message is considered valid. Appendix F + illustrates some example topologies and how they correspond to + information in the Information Bases. + + + + + + +Clausen, et al. Standards Track [Page 12] + +RFC 6130 MANET-NHDP April 2011 + + +4.2.1. Local Information Base + + Each router maintains a Local Information Base, which contains the + router's local configuration information, specifically: + + o The Local Interface Set, which consists of Local Interface Tuples, + each of which represents an interface (MANET or non-MANET) of the + router. + + o The Removed Interface Address Set, which consists of Removed + Interface Address Tuples, each of which records a recently used + network address of an interface (MANET or non-MANET) of the + router. + + The Local Interface Set is used for generating HELLO messages, + specifically for determining which interface network addresses are to + be included and identified as local interfaces. The Removed + Interface Address Set is used to avoid incorrectly recording a + formerly used network address as a symmetric 2-hop neighbor's network + address. + + The Local Information Base is used for generating signaling, but is + not itself updated by signaling specified in this document. Updates + to the Local Information Base are due to changes of the router + configuration, and may be allowed to trigger signaling. + +4.2.2. Interface Information Bases + + Each router maintains, for each of its MANET interfaces, an Interface + Information Base, which contains 1-hop neighborhood and symmetric + 2-hop neighborhood information collected from this MANET interface, + specifically: + + o A Link Set, which records information about current and recently + lost links between this MANET interface and MANET interfaces of + 1-hop neighbors. The Link Set consists of Link Tuples, each of + which contains information about a single link. Link quality + information (see Section 14), when used, is recorded in Link + Tuples. + + o A 2-Hop Set, which records the existence of symmetric links + between symmetric 1-hop neighbors of this MANET interface and + other routers (symmetric 2-hop neighbors). The 2-Hop Set consists + of 2-Hop Tuples, each of which records a network address of a + symmetric 2-hop neighbor, and all network addresses of the + corresponding symmetric 1-hop neighbor. + + + + + +Clausen, et al. Standards Track [Page 13] + +RFC 6130 MANET-NHDP April 2011 + + + The Link Set for a MANET interface is used for generating HELLO + messages. Specifically, the Link Set information is included to both + allow other routers to identify symmetric links and to populate the + 2-Hop Set. Recently lost links are recorded in the Link Set for a + MANET interface so that they can be advertised in HELLO messages, + accelerating their removal from relevant 1-hop neighbors' Link Sets. + + The Link Set for a MANET interface is itself updated on receiving a + HELLO message, including recording symmetric links as indicated + above. The 2-Hop Set for a MANET interface is updated as indicated + above, and is not itself used in generating HELLO messages. + +4.2.3. Neighbor Information Base + + Each router maintains a Neighbor Information Base, which contains + collected information about current and recently lost 1-hop + neighbors, specifically: + + o The Neighbor Set consists of Neighbor Tuples, each of which + records all network addresses of a single 1-hop neighbor. + Neighbor Tuples are maintained as long as there are corresponding + Link Tuples. + + o The Lost Neighbor Set consists of Lost Neighbor Tuples, each of + which records a network address of a recently lost symmetric 1-hop + neighbor. + + The Neighbor Set associates all network addresses of each 1-hop + neighbor. These network addresses may be included when generating a + HELLO message, so that other symmetric 1-hop neighbors can record + this information in a 2-Hop Set. The Neighbor Set can be updated on + receiving a HELLO message. + + The Lost Neighbor Set is used to determine which network addresses + are to be included in a HELLO message as being lost (of a recently + symmetric 1-hop neighbor). The Lost Neighbor Set can itself be + updated on receiving a HELLO message. + +4.3. Signaling Overview + + This protocol contains a signaling mechanism for maintaining the + Interface Information Bases and the Neighbor Information Base. If + information from the link layer, or any other source, is available + and appropriate, it may also be used to update these Information + Bases. Such updates are subject to the constraints specified in + Appendix B. + + + + + +Clausen, et al. Standards Track [Page 14] + +RFC 6130 MANET-NHDP April 2011 + + + Signaling consists of a single type of message, known as a HELLO + message. Each router generates HELLO messages on each of its MANET + interfaces. HELLO messages are generated independently on each MANET + interface of a MANET router; the content of a given HELLO message + depends on the MANET interface for which it has been generated. + + Each HELLO message: + + o Identifies, as far as is required, the MANET interface for which + it is generated and transmitted; this allows recipients of that + HELLO message to identify that MANET interface from among those it + may hear. + + o Reports the network addresses of other interfaces (MANET and non- + MANET) of the router; this allows recipients of that HELLO message + to associate a set of network addresses with a single 1-hop + neighbor. + + o Includes 1-hop neighbor information from the Information Bases; + this allows detection of local symmetric links, and symmetric + 2-hop neighbors. + + HELLO message generation, and the validity of the information + recorded as a consequence of processing a HELLO message, is affected + by timers and validity information included in HELLO messages through + TLVs. The relationship between message timers and intervals is + illustrated in Appendix E. + +4.3.1. HELLO Message Generation + + HELLO messages are generated by a router for each of its MANET + interfaces, and MAY be sent: + + o Proactively, at a regular interval, known as HELLO_INTERVAL. + HELLO_INTERVAL may be fixed, or may be dynamic. For example, + HELLO_INTERVAL may be backed off due to congestion or network + stability. + + o As a response to a change in the router itself, or its 1-hop + neighborhood, for example, on first becoming active or in response + to a new, lost, or changed status link. + + o In a combination of these proactive and responsive mechanisms. + + Jittering of HELLO message generation and transmission SHOULD be used + as described in Section 11.2, unless the medium access control + mechanism in use prevents any simultaneous transmissions by + potentially interfering routers. + + + +Clausen, et al. Standards Track [Page 15] + +RFC 6130 MANET-NHDP April 2011 + + + HELLO messages MAY be scheduled independently for each MANET + interface, or, interface parameters permitting, using the same + schedule for all MANET interfaces of a router. + +4.3.2. HELLO Message Content + + The content of a HELLO message MUST satisfy the following: + + o A HELLO message MUST contain all of the network addresses in the + Local Interface Set of the router on which the HELLO message is + being generated. This includes: + + o At least one network address of each MANET interface of the + router. + + o Network addresses that include all source addresses of any IP + datagrams sent by the router on any MANET interface. + + o All other network addresses of the router that are to be made + known to any other router for any reason. + + o For each MANET interface, within every time interval equal to the + corresponding REFRESH_INTERVAL, sent HELLO messages MUST + collectively include all of the relevant information in the + corresponding Link Set and the Neighbor Information Base. Note + that when determining whether to include information in a HELLO + message, the sender MUST consider all times up to the latest time + when it may send its next HELLO message on this MANET interface. + + o For each MANET interface, within every time interval equal to the + corresponding REFRESH_INTERVAL, sent HELLO messages MUST + collectively include all of the relevant information in the + corresponding Link Set and the Neighbor Information Base. + + o When determining whether to include a given piece of neighbor + information in a HELLO message, it is not sufficient to consider + whether that information has been sent in the interval of length + REFRESH_INTERVAL up to the current time. Instead, the router MUST + consider the interval of length REFRESH_INTERVAL that will end at + the latest possible time at which the next HELLO message will be + sent on this MANET interface. (Normally, this will be + HELLO_INTERVAL past the current time, but MAY be earlier if this + router elects to divide its neighbor information among more than + one HELLO message in order to reduce the size of its HELLO + messages.) All neighbor information MUST be sent in this + interval, i.e., the router MUST ensure that this HELLO message + includes all neighbor information that has not already been + included in any HELLO messages sent since the start of this + + + +Clausen, et al. Standards Track [Page 16] + +RFC 6130 MANET-NHDP April 2011 + + + interval (normally, the current time - (REFRESH_INTERVAL - + HELLO_INTERVAL)). + + o A HELLO message MUST include exactly one VALIDITY_TIME Message + TLV, as specified in [RFC5497], that indicates the length of time + for which the message content is to be considered valid, and is + therefore to be included in the receiving router's Interface + Information Base. + + o A periodically generated HELLO message SHOULD include exactly one + INTERVAL_TIME Message TLV, as specified in [RFC5497], that + indicates the current value of HELLO_INTERVAL for that MANET + interface, i.e., the period within which a further HELLO message + is guaranteed to be sent on that MANET interface. + +4.3.3. HELLO Message Processing + + HELLO messages received by a router are used to update the Interface + Information Base for the MANET interface over which that HELLO + message was received, as well as the Neighbor Information Base of the + router. Specifically: + + o The router ensures that there is a single Neighbor Tuple + corresponding to the originator of that HELLO message. + + o The router ensures that there is a Link Tuple, with appropriate + status (heard or symmetric) and advertised duration, corresponding + to the link between the MANET interfaces on which that HELLO + message was sent and received. One or more Lost Neighbor Tuples + may be created if the HELLO message reports that the link was + lost. + + o If the link between the MANET interfaces on which the HELLO + message was sent and received is symmetric, then the router + ensures that there are the appropriate 2-Hop Tuples, with + advertised duration. + + The processing defined in this specification handles any unexpected + and erroneous information in a HELLO message, maintaining the + constraints on Information Base contents specified in Appendix B. + +4.4. Link Quality + + Some links in a MANET may be marginal, e.g., due to adverse wireless + propagation. In order to avoid using such marginal links, a link + quality value is recorded in each Link Tuple. A MANET router + considers links for which an insufficient link quality is recorded as + lost. Modifying the recorded link quality in a Link Tuple is + + + +Clausen, et al. Standards Track [Page 17] + +RFC 6130 MANET-NHDP April 2011 + + + OPTIONAL. If link quality is not to be modified, it MUST be set to + indicate an always usable quality link. + + Note that link quality is a "link admittance" mechanism, allowing a + router to determine that a given link is too unstable to even + consider for use. It is specifically not a link metric nor is it a + substitute for one. + + Link quality information is only used locally and is not used in + signaling. Routers may interoperate whether they are using the same, + different, or no link quality information. Link quality information + is thus not equivalent to a link metric. + + Link quality information is defined in this specification as a + normalized, dimensionless value in the interval zero to one, + inclusive, where the greater the value, the better the link quality. + See Section 14 for further details. + +5. Protocol Parameters and Constants + + The parameters and constants used in this specification are described + in this section. + +5.1. Protocol and Port Numbers + + This protocol specifies HELLO messages, which are included in packets + as defined by [RFC5444]. These packets may be sent using either the + "manet" protocol number or the "manet" well-known UDP port number, as + specified in [RFC5498]. + +5.2. Multicast Address + + This protocol specifies HELLO messages, which are included in packets + as defined by [RFC5444]. These packets may be locally transmitted + using the link-local multicast address "LL-MANET-Routers", as + specified in [RFC5498]. + +5.3. Interface Parameters + + The interface parameters used by this specification may be classified + into the following four categories: + + o Message intervals + + o Information validity times + + o Link quality + + + + +Clausen, et al. Standards Track [Page 18] + +RFC 6130 MANET-NHDP April 2011 + + + o Jitter + + These are detailed in the following sections. + + Different MANET interfaces (on the same or on different routers) MAY + employ different interface parameter values and MAY change their + interface parameter values dynamically, subject to the constraints + given in this section. A particular case is where all MANET + interfaces on all MANET routers within a given MANET employ the same + set of interface parameter values. + +5.3.1. Message Intervals + + HELLO messages serve two principal functions: + + o To advertise network addresses of this router's interface to its + 1-hop neighbors. The frequency of these advertisements is + regulated by the interface parameters HELLO_INTERVAL and + HELLO_MIN_INTERVAL. + + o To advertise this router's knowledge of each of its 1-hop + neighbors. The frequency of the advertisement of each such + neighbor is regulated by the interface parameter REFRESH_INTERVAL. + + Specifically, these parameters are as follows: + + HELLO_INTERVAL: + The maximum time between the transmission of two successive HELLO + messages on this MANET interface. If using periodic transmission + of HELLO messages, these SHOULD be at a separation of + HELLO_INTERVAL, possibly modified by jitter as specified in + [RFC5148]. + + HELLO_MIN_INTERVAL: + The minimum interval between transmission of two successive HELLO + messages on this MANET interface. (This minimum interval MAY be + modified by jitter, as defined in [RFC5148].) + + REFRESH_INTERVAL: + The maximum interval between advertisements, in a HELLO message on + this MANET interface, of each 1-hop neighbor network address and + its status. In all intervals of length REFRESH_INTERVAL, a router + MUST include each 1-hop neighbor network address and its status in + at least one HELLO message on this MANET interface. (This may be + in the same or in different HELLO messages.) + + + + + + +Clausen, et al. Standards Track [Page 19] + +RFC 6130 MANET-NHDP April 2011 + + + REFRESH_INTERVAL thus represents the frequency at which a piece of + information, as received in HELLO messages, can be expected to be + refreshed. Thus, the REFRESH_INTERVAL is used as a basis for + determining when such information expires in receiving routers (see + Section 5.3.2). HELLO_INTERVAL represents the frequency of HELLO + message emissions. Logically, HELLO_INTERVAL cannot be greater than + the REFRESH_INTERVAL; otherwise, information cannot be refreshed in a + timely manner. + + HELLO messages can, however, be sent with a higher frequency. A + possible use for sending HELLO messages at such a higher frequency + includes sending partial HELLO messages (e.g., accommodating + constraints on packet sizes from the underlying medium) refreshing + only part of the information in each HELLO message. Another use is + for a router to send "empty HELLO messages", advertising its own + presence frequently in smaller HELLO messages (e.g., in case HELLO + message exchange success rates are used for link quality estimation, + or to enable rapid detection by new routers in the neighborhood) in + between HELLO messages refreshing neighbor information in other + routers. + + The following constraints apply to these interface parameters: + + o HELLO_INTERVAL > 0 + + o HELLO_MIN_INTERVAL >= 0 + + o HELLO_INTERVAL >= HELLO_MIN_INTERVAL + + o REFRESH_INTERVAL >= HELLO_INTERVAL + + o If an INTERVAL_TIME Message TLV as defined in [RFC5497] is + included in a HELLO message, then HELLO_INTERVAL MUST be + representable as described in [RFC5497]. + + If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute + its neighbor advertisements between HELLO messages in any manner, + subject to the constraints above. + + In the absence of any changes to the local neighborhood, a router + will send a HELLO message on a MANET interface after an (possibly + jittered) interval of length HELLO_INTERVAL. For a router to employ + this protocol in a purely responsive manner on a MANET interface, + i.e., for the router to only send HELLO messages on that MANET + interface as a response to external events, HELLO_INTERVAL (and hence + also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such + that a responsive HELLO message is always expected with a shorter + period than this value. + + + +Clausen, et al. Standards Track [Page 20] + +RFC 6130 MANET-NHDP April 2011 + + + If a router has more than one MANET interface, then, even if the + router configures different values of HELLO_INTERVAL on each MANET + interface, the router SHOULD configure the same value of + HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO + messages may be sent. (This ensures that changes observed on one + MANET interface are reported on other MANET interfaces, so that 1-hop + neighbors connected to the latter can maintain up-to-date 2-hop + neighborhood information.) + +5.3.2. Information Validity Times + + The following interface parameters manage the validity time of link + information: + + L_HOLD_TIME: + The period of advertisement, on this MANET interface, of former + 1-hop neighbor network addresses as lost in HELLO messages, + allowing recipients of these HELLO messages to accelerate removal + of this information from their Link Sets. L_HOLD_TIME MAY be set + to zero, if accelerated information removal is not required. + + H_HOLD_TIME: + Used as the Value in the VALIDITY_TIME Message TLV included in all + HELLO messages on this MANET interface. It is then used by each + router receiving such a HELLO message to indicate the validity of + the information taken from that HELLO message and recorded in the + receiving router's Information Bases. + + Note that as each item of neighbor information is included in HELLO + messages within an interval of length REFRESH_INTERVAL, constraints + on H_HOLD_TIME are based on REFRESH_INTERVAL, not on HELLO_INTERVAL. + + The following constraints apply to these interface parameters: + + o L_HOLD_TIME >= 0 + + o H_HOLD_TIME >= REFRESH_INTERVAL + + o If HELLO messages can be lost, then both parameters SHOULD be + significantly greater than REFRESH_INTERVAL. + + o H_HOLD_TIME MUST be representable as described in [RFC5497]. + + + + + + + + + +Clausen, et al. Standards Track [Page 21] + +RFC 6130 MANET-NHDP April 2011 + + +5.3.3. Link Quality + + The following interface parameters manage the usage of link quality + (see Section 14): + + HYST_ACCEPT: + The link quality threshold at or above which a link becomes + usable, if it was not already so. + + HYST_REJECT: + The link quality threshold below which a link becomes unusable, if + it was not already so. + + INITIAL_QUALITY: + The initial quality of a newly identified link. + + INITIAL_PENDING: + If true, then a newly identified link is considered pending, and + is not usable until the link quality has reached or exceeded the + HYST_ACCEPT threshold. + + The following constraints apply to these interface parameters: + + o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1 + + o 0 <= INITIAL_QUALITY <= 1. + + o If link quality is not updated, then INITIAL_QUALITY >= + HYST_ACCEPT. + + o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false. + + o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true. + +5.3.4. Jitter + + If jitter, as defined in [RFC5148], is used, then these parameters + are as follows: + + HP_MAXJITTER: + Represents the value of MAXJITTER used in [RFC5148] for + periodically generated HELLO messages on this MANET interface. + + HT_MAXJITTER: + Represents the value of MAXJITTER used in [RFC5148] for externally + triggered HELLO messages on this MANET interface. + + For constraints on these interface parameters, see [RFC5148]. + + + +Clausen, et al. Standards Track [Page 22] + +RFC 6130 MANET-NHDP April 2011 + + +5.4. Router Parameters + + The two router parameters defined by this specification are in the + category of information validity time. + +5.4.1. Information Validity Time + + The following router parameter manages the validity time of lost + symmetric 1-hop neighbor information: + + N_HOLD_TIME: + Used as the period during which former 1-hop neighbor network + addresses are advertised as lost in HELLO messages, allowing + recipients of these HELLO messages to accelerate removal of this + information from their 2-Hop Sets. N_HOLD_TIME MAY be set to + zero, if accelerated information removal is not required. + + I_HOLD_TIME: + The period for which a recently used local interface network + address is recorded. + + The following constraints apply to these router parameters: + + o N_HOLD_TIME >= 0 + + o I_HOLD_TIME >= 0 + +5.5. Parameter Change Constraints + + If protocol parameters are changed dynamically, the constraints in + this section apply. + + HELLO_INTERVAL + + o If the HELLO_INTERVAL for a MANET interface increases, then the + next HELLO message on this MANET interface MUST be generated + according to the previous, shorter, HELLO_INTERVAL. A number + of subsequent HELLO messages MAY be generated according to the + previous, shorter, HELLO_INTERVAL (but MUST include times + according to current parameters). This ensures that "promises" + as to timely transmission of a future HELLO message are kept + until these previous promises have expired. + + o If the HELLO_INTERVAL for a MANET interface decreases, then the + following HELLO messages on this MANET interface MUST be + generated according to this current, shorter, HELLO_INTERVAL. + + + + + +Clausen, et al. Standards Track [Page 23] + +RFC 6130 MANET-NHDP April 2011 + + + REFRESH_INTERVAL + + o If the REFRESH_INTERVAL for a MANET interface increases, then + the content of subsequent HELLO messages must be organized such + that the specification of the old value of REFRESH_INTERVAL is + satisfied for a further period equal to the old value of + REFRESH_INTERVAL. + + o If the REFRESH_INTERVAL for a MANET interface decreases, then + it MAY be necessary to reschedule HELLO message generation on + that MANET interface, in order for the specification of + REFRESH_INTERVAL is satisfied from the time of change. + + HYST_ACCEPT and HYST_REJECT + + o If HYST_ACCEPT or HYST_REJECT changes, then the appropriate + actions for link quality change, as specified in Section 14.3, + MUST be taken. + + L_HOLD_TIME + + o If L_HOLD_TIME changes, then the expiry times of all relevant + Link Tuples MUST be changed. + + N_HOLD_TIME + + o If N_HOLD_TIME changes, then the expiry times of all relevant + Lost Neighbor Tuples MUST be changed. + + HP_MAXJITTER + + o If HP_MAXJITTER changes, then the periodic HELLO message + schedule on this MANET interface MAY be changed. + + HT_MAXJITTER + + o If HT_MAXJITTER changes, then externally triggered HELLO + messages on this MANET interface MAY be rescheduled. + +5.6. Constants + + The constant C (time granularity) is used as specified in [RFC5497]. + +6. Local Information Base + + A router maintains a Local Information Base that records information + about its interfaces (MANET and non-MANET). Each interface of a + router MUST be identified by at least one network address. Such + + + +Clausen, et al. Standards Track [Page 24] + +RFC 6130 MANET-NHDP April 2011 + + + network addresses MAY be specific to that interface, or MAY in some + circumstances be used by more than one interface as specified below. + + The Local Information Base is not modified by signaling. If a + router's interface configuration changes, then the Local Information + Base MUST reflect these changes. This MAY also result in signaling + to advertise these changes. + + It is not necessary to include all addresses of an interface in the + Local Information Base, and hence in HELLO messages. However, any + address that may be the source address of an IP datagram sent from + that interface MUST be included (and at least one address MUST be + included). A protocol using this specification MAY add additional + requirements to these, e.g., that any address that may be the + destination address of an IP datagram is also included. + + The addresses assigned to an interface are "owned" by the router, and + MUST NOT be used by any other router as an interface address. If an + address has a prefix length and represents a range of addresses, this + applies to all addresses in that range (i.e., such ranges MUST NOT + overlap). + + The addresses assigned to different interfaces on the same router + MUST be distinct (hence, network address ranges MUST NOT overlap) + except that: + + o The same address MAY be assigned to any number of non-MANET + interfaces as well as to one (or more if the following condition + also applies) MANET interface. + + o The same address MAY be assigned to two (or more if each pair + satisfies this condition) MANET interfaces if those two MANET + interfaces cannot communicate to, from, or one to and one from any + other MANET interface of another router. + +6.1. Local Interface Set + + A router's Local Interface Set records its local interfaces. It + consists of Local Interface Tuples, one per interface: + + (I_local_iface_addr_list, I_manet) + + where: + + I_local_iface_addr_list is an unordered list of the network + addresses of this interface. + + + + + +Clausen, et al. Standards Track [Page 25] + +RFC 6130 MANET-NHDP April 2011 + + + I_manet is a boolean flag, describing if this interface is a MANET + interface. + + Local Interface Tuples are removed from the Local Interface Set only + when the routers' interface configuration changes, subject to + Section 9, i.e., they are not subject to timer-based expiration. + +6.2. Removed Interface Address Set + + A router's Removed Interface Address Set records network addresses + that were recently used as local interface network addresses. If a + router's interface network addresses are immutable, then the Removed + Interface Address Set is always empty and MAY be omitted. It + consists of Removed Interface Address Tuples, one per network + address: + + (IR_local_iface_addr, IR_time) + + where: + + IR_local_iface_addr is a recently used network address of an + interface of this router. + + IR_time specifies when this Tuple expires and MUST be removed. + +7. Interface Information Bases + + A router maintains an Interface Information Base for each of its + MANET interfaces. This records information about links to that MANET + interface and symmetric 2-hop neighbors that can be reached in two + hops using those links as the first hop. Each Interface Information + Base includes a Link Set and a 2-Hop Set. + + A network address of a symmetric 2-hop neighbor can also be present + as the network address of a 1-hop neighbor. This allows the router + using this network address to be immediately considered as a + symmetric 2-hop neighbor if it fails to be a symmetric 1-hop + neighbor. + + An element that specifies a time is considered expired if the current + time is greater than or equal to that time. One such element, + present in most Tuples, indicates, when expired, that the Tuple + itself is considered expired and MUST be removed. Tuples that do not + have such a time element are removed at other times as specified; for + example, a Neighbor Tuple is removed when all corresponding Link + Tuples have been removed. + + + + + +Clausen, et al. Standards Track [Page 26] + +RFC 6130 MANET-NHDP April 2011 + + +7.1. Link Set + + An interface's Link Set records links from other routers that are, or + recently were, 1-hop neighbors. It consists of Link Tuples, each + representing a single link: + + (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, + L_quality, L_pending, L_lost, L_time) + + where: + + L_neighbor_iface_addr_list is an unordered list of the network + addresses of the MANET interface of the 1-hop neighbor; + + L_HEARD_time is the time up to which the MANET interface of the + 1-hop neighbor would be considered heard if not considering link + quality; + + L_SYM_time is the time up to which the link to the 1-hop neighbor + would be considered symmetric if not considering link quality; + + L_quality is a dimensionless number between 0 (inclusive) and 1 + (inclusive) describing the quality of a link; a greater value of + L_quality indicating a higher quality link; + + L_pending is a boolean flag, describing if a link is considered + pending (i.e., a candidate, but not yet established, link); + + L_lost is a boolean flag, describing if a link is considered lost + due to low link quality; + + L_time specifies when this Tuple expires and MUST be removed. + + The status of the link, as obtained through HELLO message exchange + and using link quality, is denoted L_status. L_status can take the + Values PENDING, HEARD, SYMMETRIC, and LOST. The values LOST, + SYMMETRIC, and HEARD are defined in Section 18.5. The Value PENDING + is never used in a HELLO message, it is only used locally by a + router, and any Value distinct from LOST, SYMMETRIC, and HEARD may be + used. + + L_status is defined by: + + 1. If L_pending = true, then L_status := PENDING; + + 2. otherwise, if L_lost = true, then L_status := LOST; + + + + + +Clausen, et al. Standards Track [Page 27] + +RFC 6130 MANET-NHDP April 2011 + + + 3. otherwise, if L_SYM_time is not expired, then L_status := + SYMMETRIC; + + 4. otherwise, if L_HEARD_time is not expired, then L_status := + HEARD; + + 5. otherwise, L_status := LOST. + +7.2. 2-Hop Set + + An interface's 2-Hop Set records network addresses of symmetric 2-hop + neighbors, and the symmetric links to symmetric 1-hop neighbors + through which these symmetric 2-hop neighbors can be reached. It + consists of 2-Hop Tuples, each representing a single network address + of a symmetric 2-hop neighbor, and a single MANET interface of a + symmetric 1-hop neighbor. + + (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time) + + where: + + N2_neighbor_iface_addr_list is an unordered list of the network + addresses of the MANET interface of the symmetric 1-hop neighbor + from which this information was received; + + N2_2hop_addr is a network address of a symmetric 2-hop neighbor + that has a symmetric link (using any MANET interface) to the + indicated symmetric 1-hop neighbor; + + N2_time specifies when this Tuple expires and MUST be removed. + +8. Neighbor Information Base + + Each router maintains a Neighbor Information Base that records + information about network addresses of current and recently symmetric + 1-hop neighbors. + +8.1. Neighbor Set + + A router's Neighbor Set records all network addresses of each 1-hop + neighbor. It consists of Neighbor Tuples, each representing a single + 1-hop neighbor: + + (N_neighbor_addr_list, N_symmetric) + + + + + + + +Clausen, et al. Standards Track [Page 28] + +RFC 6130 MANET-NHDP April 2011 + + + where: + + N_neighbor_addr_list is an unordered list of the network addresses + of a 1-hop neighbor; + + N_symmetric is a boolean flag, describing if this is a symmetric + 1-hop neighbor. + + Neighbor Tuples are removed from the Neighbor Set only when + corresponding Link Tuples expire from the routers' Link Set, i.e., + Neighbor Tuples are not directly subject to timer-based expiration. + +8.2. Lost Neighbor Set + + A router's Lost Neighbor Set records network addresses of routers + that recently were symmetric 1-hop neighbors but that are now + advertised as lost. It consists of Lost Neighbor Tuples, each + representing a single such network address: + + (NL_neighbor_addr, NL_time) + + where: + + NL_neighbor_addr is a network address of a router that recently + was a symmetric 1-hop neighbor of this router; + + NL_time specifies when this Tuple expires and MUST be removed. + +9. Local Information Base Changes + + The Local Information Base MUST be updated in response to changes in + the router's local interface configuration. These MAY also change + the Interface Information Base and the Neighbor Information Base. If + any changes to the latter Information Bases satisfy any of the + conditions described in Section 13, then those changes MUST be + applied immediately, unless noted otherwise below. + + A router MAY transmit HELLO messages in response to these changes. + +9.1. Adding an Interface + + If an interface is added to the router, then this is indicated by the + addition of a Local Interface Tuple to the Local Interface Set. If + the new interface is a MANET interface, then an initially empty + Interface Information Base MUST be created for this new MANET + interface. The actions in Section 9.3 MUST be taken for each network + address of this added interface. A HELLO message MAY be sent on all + MANET interfaces, it SHOULD be sent on the new interface if it is a + + + +Clausen, et al. Standards Track [Page 29] + +RFC 6130 MANET-NHDP April 2011 + + + MANET interface. If using scheduled messages, then a message + schedule MUST be established on the new MANET interface. + +9.2. Removing an Interface + + If an interface is removed from the router, then this MUST result in + changes to the Local Information Base and to the Neighbor Information + Base as follows: + + 1. Identify the Local Interface Tuple that corresponds to the + interface to be removed. + + 2. For each network address (henceforth removed address) in the + I_local_iface_addr_list of that Local Interface Tuple, if that + network address is not in the I_local_iface_addr_list of any + other Local Interface Tuple, then create a Removed Interface + Address Tuple with: + + o IR_local_iface_addr := removed address; + + o IR_time := current time + I_HOLD_TIME. + + 3. Remove that Local Interface Tuple from the Local Interface Set. + + 4. If the interface to be removed is a MANET interface (i.e., with + I_manet = true), then: + + 1. Remove the Interface Information Base for that MANET + interface; + + 2. All Neighbor Tuples for which none of the network addresses + in its N_neighbor_addr_list are contained in any + L_neighbor_iface_addr_list in any remaining Link Tuple are + removed. + + If the removed interface is the last MANET interface of the router, + then there will be no remaining Interface Information Bases, and the + router will no longer participate in this protocol. + + After removing the interface and making these changes, a HELLO + message MAY be sent on all remaining MANET interfaces. + +9.3. Adding a Network Address to an Interface + + If a network address is added to an interface, then this is indicated + by the addition of a network address to the appropriate + I_local_iface_addr_list. The following changes MUST be made to the + Information Bases: + + + +Clausen, et al. Standards Track [Page 30] + +RFC 6130 MANET-NHDP April 2011 + + + 1. Remove any Removed Interface Address Tuple whose + IR_local_iface_addr is the added network address. + + 2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a + network address that overlaps the added network address. + + 3. Remove any Link Tuples, in any Link Set, for which either: + + o L_neighbor_iface_addr_list contains any network address in the + N_neighbor_addr_list of any removed Neighbor Tuple; OR + + o L_neighbor_iface_addr_list contains a network address that + overlaps the added network address. + + Apply Section 13.2 but not Section 13.3. + + 4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps + the added network address. + + 5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added + network address. + + After adding the network address and making these changes, a HELLO + message MAY be sent on all MANET interfaces. + + These changes, other than to the appropriate I_local_iface_addr_list, + are made in order to maintain consistency of the Information Bases. + Specifically, these changes remove any record of any use of this + network address by routers in the 1-hop neighborhood or in the + symmetric 2-hop neighborhood of this router. + +9.4. Removing a Network Address from an Interface + + If a network address (henceforth removed address) is removed from an + interface, then: + + 1. Identify the Local Interface Tuple that corresponds to the + removed address. + + 2. If this is the only network address of that interface (the only + network address in the corresponding I_local_iface_addr_list), + then remove that interface as specified in Section 9.2. + + 3. Otherwise: + + 1. Remove the removed address from this I_local_iface_addr_list. + + + + + +Clausen, et al. Standards Track [Page 31] + +RFC 6130 MANET-NHDP April 2011 + + + 2. If the removed address is not in the I_local_iface_addr_list + of any other Local Interface Tuple, then create a Removed + Interface Address Tuple with: + + o IR_local_iface_addr := removed address; + + o IR_time := current time + I_HOLD_TIME. + + After removing the network address and making these changes, a HELLO + message MAY be sent on all MANET interfaces. + +10. Packets and Messages + + The packet and message format used by this protocol is defined in + [RFC5444], which is used with the following considerations: + + o This protocol specifies one Message Type, the HELLO message. + + o A HELLO message MAY use any combination of Message Header options + specified in [RFC5444]. + + o HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if + present, MUST have the value 1. + + o HELLO messages MAY be included in multi-message packets as + specified in [RFC5444]. + + o Received HELLO messages MUST be parsed in accordance with + [RFC5444]. A HELLO message that is not in conformance with + [RFC5444] MUST be discarded without being processed. A HELLO + message can also be discarded without being processed for other + reasons, see Section 12.1. + + o This protocol specifies three Address Block TLVs. It also uses + two Message TLVs defined in [RFC5497]. These five TLV Types are + all defined only with Type Extension = 0. TLVs of other types, + and of these types but without Type Extension = 0, are ignored by + this protocol. All references in this specification to, for + example, an Address Block TLV with Type = LINK_STATUS, are to be + considered as referring to an Address Block TLV with Type = + LINK_STATUS and Type Extension = 0. + +10.1. HELLO Messages + + A HELLO message MUST contain: + + o Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497], + representing H_HOLD_TIME for the transmitting MANET interface. + + + +Clausen, et al. Standards Track [Page 32] + +RFC 6130 MANET-NHDP April 2011 + + + The options included in [RFC5497] for representing zero and + infinite times MUST NOT be used. + + A HELLO message transmitted due to a periodic timer SHOULD contain, + and otherwise (i.e., transmitted for any other reason, in particular + in response to any Information Base changes) MAY contain: + + o Exactly one INTERVAL_TIME Message TLV as specified in [RFC5497], + representing HELLO_INTERVAL for the transmitting MANET interface. + The options included in [RFC5497] for representing zero and + infinite times MUST NOT be used. + + A HELLO message MAY contain: + + o Other Message TLVs. + + o One or more Address Blocks, each with an associated Address Block + TLV Block, which MAY contain other Address Block TLVs. + +10.1.1. Address Blocks + + All network addresses in a router's Local Interface Set (i.e., in any + I_local_iface_addr_list) MUST be represented as address objects (see + [RFC5444]), and included in the Address Blocks in all generated HELLO + messages, with the following permitted exception: + + o If the MANET interface on which the HELLO message is to be sent + has a single address with maximum prefix length (i.e., /32 for + IPv4, /128 for IPv6), then that address MAY be omitted from being + included in any Address Block, provided that this address is + included as the sending address of the IP datagram in which the + HELLO message is included. + + All network addresses of the router's interfaces included in any + Address Block(s) MUST be associated with an Address Block TLV with + Type = LOCAL_IF, as defined in Table 1. + + +----------+---------+----------------------------------------------+ + | Name | Value | Description | + | | Length | | + +----------+---------+----------------------------------------------+ + | LOCAL_IF | 1 octet | Specifies that the network address is | + | | | associated with the MANET interface on which | + | | | the message was sent (THIS_IF) or another | + | | | interface of the sending router (OTHER_IF). | + +----------+---------+----------------------------------------------+ + + Table 1: LOCAL_IF TLV Definition + + + +Clausen, et al. Standards Track [Page 33] + +RFC 6130 MANET-NHDP April 2011 + + + Address Blocks MAY contain current or recently lost 1-hop neighbors' + network addresses, represented as address objects (see [RFC5444]), + each of which is associated with one or both Address Block TLVs as + described in Table 2. + + +--------------+---------+------------------------------------------+ + | Name | Value | Description | + | | Length | | + +--------------+---------+------------------------------------------+ + | LINK_STATUS | 1 octet | Specifies the status of the link from | + | | | the indicated network address and to the | + | | | MANET interface over which the HELLO | + | | | message is transmitted (LOST, SYMMETRIC, | + | | | or HEARD). | + | OTHER_NEIGHB | 1 octet | Specifies that the network address is | + | | | (SYMMETRIC) or was (LOST) of a MANET | + | | | interface of a symmetric 1-hop neighbor | + | | | of the router transmitting the HELLO | + | | | message. | + +--------------+---------+------------------------------------------+ + + Table 2: LINK_STATUS and OTHER_NEIGHB TLV Definition + + An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or + Value = LOST also performs the function of an Address Block TLV with + Type = OTHER_NEIGHB and the same Value. Including the latter + associated with the same address object is discouraged for efficiency + reasons. If an Address Block TLV with Type = LINK_STATUS and Value = + SYMMETRIC is combined with an Address Block TLV with Type = + OTHER_NEIGHB and Value = LOST associated with the same address + object, then the latter MUST be ignored and SHOULD NOT be included. + See Appendix A. + + Other network addresses MAY be represented as address objects (see + [RFC5444]) and included in Address Blocks, but MUST NOT be associated + with any of the Address Block TLVs specified in this specification. + +11. HELLO Message Generation + + Each MANET interface MUST generate HELLO messages according to the + specification in this section. HELLO messages are generated for each + MANET interface independently. HELLO message generation and + scheduling MUST be according to the interface parameters for that + MANET interface, and MAY be independent for each MANET interface or, + interface parameters permitting, MANET interfaces MAY use the same + schedule. + + + + + +Clausen, et al. Standards Track [Page 34] + +RFC 6130 MANET-NHDP April 2011 + + + If transmitting periodic HELLO messages, then, following a HELLO + message transmission on a MANET interface, another HELLO message MUST + be transmitted on the same MANET interface after an interval not + greater than HELLO_INTERVAL. Two successive HELLO message + transmissions on the same MANET interface MUST be separated by at + least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1. + +11.1. HELLO Message Specification + + HELLO messages are generated independently on each MANET interface. + + All network addresses in any I_local_iface_addr_list MUST be + included, represented as address objects (see [RFC5444]), except + that: + + o If the interface on which the HELLO message is to be sent has a + single address with maximum prefix length (i.e., /32 for IPv4, + /128 for IPv6), then that address MAY be omitted, provided that + this address is included as the sending address of the IP datagram + in which the HELLO message is included. + + All such included address objects MUST be associated with an Address + Block TLV with Type := LOCAL_IF and Value according to the following: + + o If the address object represents a network address of the sending + MANET interface, then Value := THIS_IF. + + o Otherwise, Value := OTHER_IF. + + If such a network address is included in more than one + I_local_iface_addr_list, then, for efficiency reasons, it is + encouraged that the corresponding address object is associated with + only one Value using an Address Block TLV with Type := LOCAL_IF; this + MUST be Value := THIS_IF if the address object represents a network + address of the sending MANET interface. + + The following network addresses of current or former 1-hop neighbors + MAY be represented as address objects (see [RFC5444]) and included in + any HELLO message, respecting the parameter REFRESH_INTERVAL for each + association for that MANET interface, and according to the following: + + o Network addresses of MANET interfaces of 1-hop neighbors from the + Link Set of the Interface Information Base for this MANET + interface (i.e., from an L_neighbor_iface_addr_list), other than + those from Link Tuples with L_status = PENDING. + + + + + + +Clausen, et al. Standards Track [Page 35] + +RFC 6130 MANET-NHDP April 2011 + + + o Other network addresses of symmetric 1-hop neighbors from the + Neighbor Set of this router's Neighbor Information Base (i.e., + from an N_neighbor_addr_list). + + o Network addresses of MANET interfaces of previously symmetric or + heard 1-hop neighbors connected on this MANET interface from the + Link Set of the Interface Information Base for this MANET + interface (i.e., from an L_neighbor_iface_addr_list with L_status + = LOST). + + o Other network addresses of previously symmetric 1-hop neighbors + from the Lost Neighbor Set of this router's Neighbor Information + Base (i.e., from an NL_neighbor_addr). + + Each such address object (see [RFC5444]) MUST be associated with one + or more appropriate Address Block TLVs. Specifically: + + 1. For each address object (henceforth linked address) that + represents a network address contained in an + L_neighbor_iface_addr_list of a Link Tuple in the Link Set for + this MANET interface, for which L_status != PENDING, include the + linked address with an associated Address Block TLV with: + + o Type := LINK_STATUS; AND + + o Value := L_status. + + 2. For each address object (henceforth neighbor address) that + represents a network address contained in an N_neighbor_addr_list + in a Neighbor Tuple with N_symmetric = true and that has not + already been included with an associated Address Block TLV with + Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor + network address with an associated Address Block TLV with: + + o Type := OTHER_NEIGHB; AND + + o Value := SYMMETRIC. + + 3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth + lost address) has not already been represented as an address + object and included, include lost address with an associated + Address Block TLV with: + + o Type := OTHER_NEIGHB; AND + + o Value := LOST. + + + + + +Clausen, et al. Standards Track [Page 36] + +RFC 6130 MANET-NHDP April 2011 + + + If any such network addresses have been added to these Information + Bases since the last HELLO message was sent on this MANET interface, + or if their status (as indicated by these TLVs and the Values they + associate with that network address) have changed since that network + address was last reported on this MANET interface, then that network + address, and the indicated TLVs, SHOULD be included in the HELLO + message. + + If the address object (see [RFC5444]) representing a network address + of a 1-hop neighbor is specified with more than one associated + Address Block TLV, then these Address Block TLVs MAY be independently + included or excluded from each HELLO message. Each such Address + Block TLV MUST be included associated with the address object + representation of that network address in a HELLO message sent on + that MANET interface in every interval of length equal to that MANET + interface's parameter REFRESH_INTERVAL. Address Block TLVs + associated with the same address object included in the same HELLO + message MAY be applied to the same or different copies of that + address object. + + An implementation of this protocol MAY limit the information included + in each HELLO message, for example, to accommodate smaller MTU sizes. + HELLO messages remain constrained by the above requirements, in + particular, that all local interface information MUST be included in + all HELLO messages, and that all neighbor information MUST be sent + within each interval of length REFRESH_INTERVAL. This neighbor + information MAY, however, be sent in the same or in different HELLO + messages. + +11.2. HELLO Message Transmission + + HELLO messages are transmitted in the format specified by [RFC5444]. + +11.2.1. HELLO Message Jitter + + HELLO messages MAY be sent using periodic message generation or + externally triggered message generation. If using data link and + physical layers that are subject to packet loss due to collisions, + HELLO messages SHOULD be jittered as described in [RFC5148]. + + Internally triggered message generation (such as due to a change in + local interfaces) MAY be treated as if externally generated message + generation or MAY be not jittered. + + HELLO messages MUST NOT be forwarded, and thus message forwarding + jitter does not apply to HELLO messages. + + + + + +Clausen, et al. Standards Track [Page 37] + +RFC 6130 MANET-NHDP April 2011 + + + Each form of jitter described in [RFC5148] requires a parameter + MAXJITTER. These interface parameters may be dynamic and are + specified by: + + o For periodic message generation: HP_MAXJITTER. + + o For externally triggered message generation: HT_MAXJITTER. + + When HELLO message generation is delayed in order that a HELLO + message is not sent within HELLO_MIN_INTERVAL of the previous HELLO + message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD + be reduced by jitter, with maximum reduction HP_MAXJITTER, as + described in [RFC5148]. In this case, HP_MAXJITTER MUST NOT be + greater than HELLO_MIN_INTERVAL. + +12. HELLO Message Processing + + On receiving a HELLO message, a router MUST first check if the + message is invalid for processing by this router, as defined in + Section 12.1 and, if so, discard the message without further + processing. Otherwise, for each received and valid HELLO message, + the receiving router MUST update its appropriate Interface + Information Base and its Neighbor Information Base as specified in + Section 12.3 to Section 12.6. These updates MUST be performed in the + order in which they are presented in this specification. If any + changes satisfy any of the conditions described in Section 13, then + the indicated consequences in that section MUST be applied + immediately, unless noted otherwise. + + All message processing, including determination of whether a message + is invalid, considers only TLVs with Type Extension = 0. TLVs with + any other type extension are ignored. All references to, for + example, a TLV with Type = LINK_STATUS refer to a TLV with Type = + LINK_STATUS and Type Extension = 0. + +12.1. Invalid Message + + A received HELLO message is invalid for processing by this router if + any of the following conditions are true: + + o The address length as specified in the Message Header is not equal + to the length of the addresses used by this router. + + o The message has a <msg-hop-limit> field in its Message Header with + a value other than one. (Note that the message does not need to + have a <msg-hop-limit> field.) + + + + + +Clausen, et al. Standards Track [Page 38] + +RFC 6130 MANET-NHDP April 2011 + + + o The message has a <msg-hop-count> field in its Message Header with + a value other than zero. (Note that the message does not need to + have a <msg-hop-count> field.) + + o The message does not have a Message TLV with Type = VALIDITY_TIME + in its Message TLV Block. + + o The message has more than one Message TLV with Type = + VALIDITY_TIME in its Message TLV Block. + + o The message has more than one Message TLV with Type = + INTERVAL_TIME in its Message TLV Block. + + o The message has any Address Block TLV(s) with Type = LOCAL_IF and + any single Value v such that v != THIS_IF and v != OTHER_IF. + + o Any address object (including different address objects + representing the same network address, in the same or different + Address Blocks) is associated with more than one Value by one or + more Address Block TLV(s) with Type = LOCAL_IF. + + o Any address object (henceforth local address) associated with an + Address Block TLV with Type = LOCAL_IF represents one of the + receiving router's current or recently used network addresses + (i.e., local address overlaps any network address in any + I_local_iface_addr_list in the Local Interface Set or any + IR_local_iface_addr in the Removed Interface Address Set). + + o The message has any Address Block TLV(s) with Type = LINK_STATUS + with any single Value v such that v != LOST, v != SYMMETRIC, and v + != HEARD. + + o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB + with any single Value v such that v != LOST and v != SYMMETRIC. + + o Any address object (including different copies of an address + object, in the same or different Address Blocks) is associated + with an Address Block TLV with Type = LOCAL_IF and with an Address + Block TLV with Type = LINK_STATUS. + + o Any address object (including different copies of an address + object, in the same or different Address Blocks) is associated + with an Address Block TLV with Type = LOCAL_IF and with an Address + Block TLV with Type = OTHER_NEIGHB. + + + + + + + +Clausen, et al. Standards Track [Page 39] + +RFC 6130 MANET-NHDP April 2011 + + + o Any address object (including different copies of an address + object, in the same or different Address Blocks) is associated + with more than one Value by one or more Address Block TLVs with + Type = LINK_STATUS. + + o Any address object (including different copies of an address + object, in the same or different Address Blocks) is associated + with more than one Value by one or more Address Block TLVs with + Type = OTHER_NEIGHB. + + A router MAY recognize additional reasons for identifying that a + message is badly formed and therefore invalid for processing, e.g., + to allow a security protocol as suggested in Section 17 to perform + verification of HELLO message signatures and prevent processing of + unverifiable HELLO messages by this protocol. + + An invalid message MUST be silently discarded, without updating the + router's Information Bases. + +12.2. Definitions + + For the purpose of this section, note the following definitions: + + o "validity time" is calculated from the Message TLV with Type = + VALIDITY_TIME of the HELLO message as specified in [RFC5497]. + (Note that, as specified by Section 12.1, there must be exactly + one such Message TLV in the HELLO message.) All information in + the HELLO message used by this specification has the same validity + time. + + o "Receiving Address List" is the I_local_iface_addr_list + corresponding to the MANET interface on which the HELLO message + was received + + o "Sending Address List" is an unordered list of network addresses + of the MANET interface over which the HELLO message was sent, + i.e., is an unordered list of the network addresses represented by + address objects contained in the HELLO message with an associated + Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If + the Sending Address List is otherwise empty, then the Sending + Address List contains a single network address with maximum prefix + length (i.e., /32 for IPv4, /128 for IPv6) with an address equal + to the sending address of the IP datagram in which the HELLO + message was included. + + o "Neighbor Address List" is an unordered list of all the network + addresses of all the interfaces of the router that generated the + HELLO message, i.e., is the Sending Address List, plus the network + + + +Clausen, et al. Standards Track [Page 40] + +RFC 6130 MANET-NHDP April 2011 + + + addresses represented by address objects contained in the HELLO + message with an associated Address Block TLV with Type = LOCAL_IF + and Value = OTHER_IF. + + o "EXPIRED" indicates that a timer is set to a value clearly + preceding the current time (e.g., current time - 1). + + o "Removed Address List" is a list of network addresses created by + this HELLO message processing that were formerly reported as local + by the router originating the HELLO message but that are not + included in the Neighbor Address List. This list is initialized + as empty. + + o "Lost Address List" is a subset of the Removed Address List + containing network addresses that were formerly considered as + symmetric. This list is initialized as empty. + +12.3. Updating the Neighbor Set + + On receiving a HELLO message, the router MUST update its Neighbor Set + and populate the Removed Address List and Lost Address List: + + 1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples) + where N_neighbor_addr_list contains any network address that + overlaps with any network address in the Neighbor Address List. + + 2. If there are no matching Neighbor Tuples, then: + + 1. Create a new Neighbor Tuple with: + + o N_neighbor_addr_list := Neighbor Address List; + + o N_symmetric := false. + + 3. If there is one matching Neighbor Tuple, then: + + 1. If the matching Neighbor Tuple's N_neighbor_addr_list != + Neighbor Address List, then: + + 1. For each network address (henceforth removed address) + that is contained in that N_neighbor_addr_list but that + is not contained in the Neighbor Address List: + + 1. Add the removed address to the Removed Address List. + + 2. If N_symmetric = true, then add the removed address + to the Lost Address List. + + + + +Clausen, et al. Standards Track [Page 41] + +RFC 6130 MANET-NHDP April 2011 + + + 2. Update the matching Neighbor Tuple by: + + o N_neighbor_addr_list := Neighbor Address List. + + 4. If there are two or more matching Neighbor Tuples, then: + + 1. For each network address (henceforth removed address) that is + contained in the N_neighbor_addr_list of any of the matching + Neighbor Tuples but is not contained in the Neighbor Address + List: + + 1. Add removed address to the Removed Address List. + + 2. If N_symmetric = true, then add removed address to the + Lost Address List. + + 2. Replace the matching Neighbor Tuples by a single Neighbor + Tuple with: + + o N_neighbor_addr_list := Neighbor Address List; + + o N_symmetric := false + +12.4. Updating the Lost Neighbor Set + + On receiving a HELLO message, a router MUST update its Lost Neighbor + Set: + + 1. For each network address (henceforth lost address) that is + contained in the Lost Address List, if no Lost Neighbor Tuple + with NL_neighbor_addr = lost address exists, then add a Lost + Neighbor Tuple with: + + o NL_neighbor_addr := lost address; + + o NL_time := current time + N_HOLD_TIME. + +12.5. Updating the Link Sets + + On receiving a HELLO message, a router MUST update its Link Sets: + + 1. Remove all network addresses in the Removed Address List from the + L_neighbor_iface_addr_list of all Link Tuples. + + 2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now + empty; apply Section 13.2 but not Section 13.3. + + + + + +Clausen, et al. Standards Track [Page 42] + +RFC 6130 MANET-NHDP April 2011 + + + The router MUST then update its Link Set for the MANET interface on + which the HELLO message is received: + + 1. Find all Link Tuples (henceforth matching Link Tuples) where: + + o L_neighbor_iface_addr_list contains one or more network + addresses in the Sending Address List. + + 2. If there is more than one matching Link Tuple, then remove them + all; apply Section 13.2 but not Section 13.3. + + 3. If no matching Link Tuples remain, then create a new matching + Link Tuple with: + + o L_neighbor_iface_addr_list := empty; + + o L_HEARD_time := EXPIRED; + + o L_SYM_time := EXPIRED; + + o L_quality := INITIAL_QUALITY; + + o L_pending := INITIAL_PENDING; + + o L_lost := false; + + o L_time := current time + validity time. + + 4. The matching Link Tuple, existing or new, is then modified as + follows: + + 1. If the router finds any network address (henceforth receiving + address) in the Receiving Address List in an Address Block in + the HELLO message, then the Link Tuple is modified as + follows: + + 1. If any receiving address in the HELLO message is + associated with an Address Block TLV with Type = + LINK_STATUS and with Value = HEARD or Value = SYMMETRIC, + then: + + o L_SYM_time := current time + validity time. + + 2. Otherwise, if any receiving address in the HELLO message + is associated with an Address Block TLV with Type = + LINK_STATUS and Value = LOST, then: + + 1. if L_SYM_time has not expired, then: + + + +Clausen, et al. Standards Track [Page 43] + +RFC 6130 MANET-NHDP April 2011 + + + 1. L_SYM_time := EXPIRED. + + 2. if L_status = HEARD, then: + + o L_time := current time + L_HOLD_TIME. + + 2. L_neighbor_iface_addr_list := Sending Address List. + + 3. L_HEARD_time := max(current time + validity time, + L_SYM_time). + + 4. If L_status = PENDING, then: + + o L_time := max(L_time, L_HEARD_time). + + 5. Otherwise, if L_status = HEARD or L_status = SYMMETRIC, then: + + o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME). + +12.6. Updating the 2-Hop Set + + On receiving a HELLO message, a router MUST update its 2-Hop Set for + the MANET interface on which the HELLO message was received: + + 1. Remove all network addresses in the Removed Address List from the + N2_neighbor_iface_addr_list of all 2-Hop Tuples. + + 2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending + Address List, has L_status = SYMMETRIC, then: + + 1. For each network address (henceforth 2-hop address) in an + Address Block of the HELLO message, where: + + o a 2-hop address is not contained in the Neighbor Address + List; + + o a 2-hop address is not contained in any + I_local_iface_addr_list; AND + + o a 2-hop address != any IR_local_iface_addr + + perform the following processing: + + 1. If the 2-hop address has an associated Address Block TLV + with: + + o Type = LINK_STATUS and Value = SYMMETRIC; OR + + + + +Clausen, et al. Standards Track [Page 44] + +RFC 6130 MANET-NHDP April 2011 + + + o Type = OTHER_NEIGHB and Value = SYMMETRIC, + + then, if there is no 2-Hop Tuple such that: + + o N2_neighbor_iface_addr_list contains one or more + network addresses in the Sending Address List; AND + + o N2_2hop_addr = 2-hop address, + + then create a 2-Hop Neighbor Tuple with: + + o N2_2hop_addr := 2-hop address. + + This 2-Hop Tuple (existing or new) is then modified as + follows: + + o N2_neighbor_iface_addr_list := Sending Address List; + + o N2_time := current time + validity time. + + 2. Otherwise, if a 2-hop address has an Address Block TLV + with: + + o Type = LINK_STATUS and Value = LOST or Value = HEARD; + OR + + o Type = OTHER_NEIGHB and Value = LOST; + + then remove all 2-Hop Tuples with: + + o N2_neighbor_iface_addr_list containing one or more + network addresses in the Sending Address List; AND + + o N2_2hop_addr = 2-hop address. + +13. Other Information Base Changes + + The Interface and Neighbor Information Bases MUST be changed when + certain events occur. These events may result from HELLO message + processing or may be otherwise generated (e.g., expiry of timers or + link quality changes). + + Events that cause changes in the Information Bases are: + + o A Link Tuple's L_status changes to SYMMETRIC. In this case, the + actions specified in Section 13.1 are performed. + + + + + +Clausen, et al. Standards Track [Page 45] + +RFC 6130 MANET-NHDP April 2011 + + + o A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple + is removed. In this case, the actions specified in Section 13.2 + are performed. + + o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed. + In this case, the actions specified in Section 13.3 are performed. + + o Local interface network address changes. In this case, the + actions specified in Section 9 are performed. + + o Link quality changes. In this case, the actions specified in + Section 14 are performed. + + If a Link Tuple is removed, or if L_status changes from SYMMETRIC and + L_HEARD_time expires, then the actions specified in Section 13.2 MUST + be performed before the actions specified in Section 13.3 are + performed for that Link Tuple. + + A router MAY report updated information in response to any of these + changes in HELLO message(s), subject to the constraints in + Section 11. + + A router that transmits HELLO messages in response to such changes + SHOULD transmit a HELLO message: + + o On all MANET interfaces, if the Neighbor Set changes such as to + indicate the change in symmetry of any 1-hop neighbors (including + addition or removal of symmetric 1-hop neighbors). + + o Otherwise, on all those MANET interfaces whose Link Set changes + such as to indicate a change in L_status of any 1-hop neighbors + (including the addition or removal of any 1-hop neighbors, other + than those considered pending). + +13.1. Link Tuple Symmetric + + If, for any Link Tuple that does not have L_status = SYMMETRIC: + + o L_status changes to SYMMETRIC; + + then: + + 1. For the Neighbor Tuple whose N_neighbor_addr_list contains + L_neighbor_iface_addr_list, set: + + o N_symmetric := true. + + + + + +Clausen, et al. Standards Track [Page 46] + +RFC 6130 MANET-NHDP April 2011 + + + 2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is + contained in that N_neighbor_addr_list. + + This includes any newly created Link Tuples whose status is + immediately updated such that L_status = SYMMETRIC. (Note that in + this specification, all Link Tuples are created such that their + L_status is not SYMMETRIC, but a Link Tuple may be immediately + updated by subsequent processing of the same HELLO message that + caused the creation of the Link Tuple such that the Link Tuple's + L_status changes to SYMMETRIC.) + +13.2. Link Tuple Not Symmetric + + If for any Link Tuple with L_status = SYMMETRIC: + + o L_status changes to any other value; OR + + o the Link Tuple is removed; + + then: + + 1. All 2-Hop Tuples for the same MANET interface with: + + o N2_neighbor_iface_addr_list contains one or more network + addresses in L_neighbor_iface_addr_list; + + are removed. + + 2. For the Neighbor Tuple whose N_neighbor_addr_list contains + L_neighbor_iface_addr_list: + + 1. If there are no remaining Link Tuples for any MANET interface + where: + + o L_neighbor_iface_addr_list is contained in + N_neighbor_addr_list; AND + + o L_status = SYMMETRIC; + + then modify the Neighbor Tuple by: + + 1. N_symmetric := false. + + 2. For each network address (henceforth neighbor address) in + N_neighbor_addr_list, add a Lost Neighbor Tuple with: + + o NL_neighbor_addr := neighbor address; + + + + +Clausen, et al. Standards Track [Page 47] + +RFC 6130 MANET-NHDP April 2011 + + + o NL_time := current time + N_HOLD_TIME. + +13.3. Link Tuple Heard Timeout + + If, for any Link Tuple: + + o L_HEARD_time expires; OR + + o the Link Tuple is removed; + + then: + + 1. For the Neighbor Tuple whose N_neighbor_addr_list contains + L_neighbor_iface_addr_list, if no Link Tuples for any MANET + interface remain where: + + o L_neighbor_iface_addr_list is contained in + N_neighbor_addr_list; AND + + o L_HEARD_time is not expired; + + then remove the Neighbor Tuple. + +14. Link Quality + + Link quality is a mechanism whereby a router MAY take considerations + other than message exchange into account for determining when a link + is and is not a candidate for being considered as HEARD or SYMMETRIC. + As such, it is a "link admission" mechanism. + + Link quality information for a link is generated (e.g., through + access to signal to noise ratio, packet loss rate, or other + information from the link layer) and used only locally, i.e., is not + included in signaling, and routers may interoperate whether they are + using the same, different, or no, link quality information. Link + quality information is specified as a normalized, dimensionless + figure in the interval zero to one, inclusive, a higher value + indicating a better link quality. + + For deployments where no link quality is used, the considerations in + Section 14.1 apply. For deployments where link quality is used, the + general principles of link quality usage are described in + Section 14.2. Sections 14.3 and 14.4 detail link quality + functioning. + + + + + + + +Clausen, et al. Standards Track [Page 48] + +RFC 6130 MANET-NHDP April 2011 + + +14.1. Deployment without Link Quality + + In order for a router to not employ link quality, the router MUST + define: + + o INITIAL_PENDING := false; + + o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define + INITIAL_QUALITY := 1). + +14.2. Basic Principles of Link Quality + + To enable link quality usage, the L_quality value of a Link Tuple is + used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT, + to set the flags L_pending and L_lost of that Link Tuple. Based on + these flags, the link status to advertise for that Link Tuple is + determined as described in Section 7.1. + + The use of two thresholds implements link hysteresis, whereby a link + that has HYST_REJECT <= L_quality < HYST_ACCEPT may be either + accepted or rejected (depending on which threshold it has most + recently crossed, or, if neither, on the value of parameter + INITIAL_PENDING). With appropriate values of these parameters, this + prevents overly rapid changes of link status. + + The basic principles of link quality usage are as follows: + + o A router does not advertise a neighbor interface in any state + until L_quality is acceptable: + + o If INITIAL_PENDING = true, then the link is advertised when + link L_quality >= HYST_ACCEPT. + + o Otherwise, the link is advertised when L_quality >= + HYST_REJECT. + + A link that is not yet advertised has L_pending = true. + + o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false, + indicating that the link can be advertised. + + o A link for which L_pending = false is advertised until its + L_quality drops below HYST_REJECT. + + o If a link has L_pending = false and L_quality < HYST_REJECT, the + link is LOST and is advertised as such. This link is not + reconsidered as a candidate HEARD or SYMMETRIC link until + L_quality >= HYST_ACCEPT. + + + +Clausen, et al. Standards Track [Page 49] + +RFC 6130 MANET-NHDP April 2011 + + + o A link that has an acceptable quality may be advertised as HEARD, + SYMMETRIC or LOST according to the exchange of HELLO messages. + + In order that these principles can all hold, a router MUST NOT + define: + + o INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR + + o INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT. + +14.3. When Link Quality Changes + + If L_quality for a link changes, then the following actions MUST be + taken: + + 1. If L_quality >= HYST_ACCEPT, then the corresponding Link Tuple is + modified by: + + 1. L_pending := false; + + 2. L_lost := false; + + 3. If L_status = HEARD or L_status = SYMMETRIC, then: + + o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME). + + 2. If L_status != PENDING, and L_quality < HYST_REJECT, then the + corresponding Link Tuple is modified by: + + 1. If L_lost = false, then: + + o L_lost := true; + + o L_time := min(L_time, current time + L_HOLD_TIME). + + As a result of this processing, the L_STATUS of a Link Tuple may + change. In this case, the processing actions corresponding to this + change, as specified in Section 13, MUST also be taken. + + If L_quality for a link is updated based on HELLO message reception, + or on reception of a packet including a HELLO message, then L_quality + MUST be updated prior to the HELLO message processing described in + Section 12. (If the receipt of the HELLO message, or the packet + containing it, creates the Link Tuple, then the Link Tuple MUST be + created with the appropriately updated L_quality value, rather than + with L_quality := INITIAL_QUALITY.) + + + + + +Clausen, et al. Standards Track [Page 50] + +RFC 6130 MANET-NHDP April 2011 + + +14.4. Updating Link Quality + + A router MAY update link quality based on any information available + to it. Particular cases that MAY be used include: + + o Information from the link layer, such as signal-to-noise ratio or + packet acknowledgment reception and loss information. + + o Receipt or loss of control packets. If control packets include a + sequential packet sequence number, as defined in [RFC5444], then + link quality can be updated when a control packet is received, + whether or not it contains a HELLO message. The link quality may + then, for example, be based on whether the last N out of M control + packets on the link were received, or may use a "leaky integrator" + tracking packet reception and loss. + + o Receipt or loss of HELLO messages. If the maximum interval + between HELLO messages is known (such as by inclusion in HELLO + messages of a Message TLV with Type := INTERVAL_TIME, as defined + in [RFC5497]), then the loss of HELLO messages can be determined + without the need to receive a later HELLO message. Note that if + this case is combined with the previous case, then care must be + taken to avoid "double counting" a lost HELLO message in a lost + packet. + +15. Proposed Values for Parameters and Constants + + This section lists the parameters and constants used in the + specification of the protocol, and proposed values of each that MAY + be used when a single value of each is used. + +15.1. Message Interval Interface Parameters + + o HELLO_INTERVAL := 2 seconds + + o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4 + + o REFRESH_INTERVAL := HELLO_INTERVAL + +15.2. Information Validity Time Interface Parameters + + o H_HOLD_TIME := 3 x REFRESH_INTERVAL + + o L_HOLD_TIME := H_HOLD_TIME + + + + + + + +Clausen, et al. Standards Track [Page 51] + +RFC 6130 MANET-NHDP April 2011 + + +15.3. Information Validity Time Router Parameters + + o N_HOLD_TIME := L_HOLD_TIME + + o I_HOLD_TIME := N_HOLD_TIME + +15.4. Link Quality Interface Parameters + + If link quality is changed, then parameter values will depend on the + link quality process. If link quality is not changed, then: + + o HYST_ACCEPT := 1 + + o HYST_REJECT := 0 + + o INITIAL_QUALITY := 1 + + o INITIAL_PENDING := false + +15.5. Jitter Interface Parameters + + o HP_MAXJITTER := HELLO_INTERVAL/4 + + o HT_MAXJITTER := HP_MAXJITTER + +15.6. Constants + + o C := 1/1024 second + +16. Usage with Other Protocols + + Other protocols, such as MANET routing protocols, that use + neighborhood discovery, may need to interact with this protocol. + This protocol is designed to permit such interactions, in particular: + + o Through accessing, and possibly extending, the information in the + Local Information Base (Section 6), the Interface Information Base + (Section 7), and the Neighbor Information Base (Section 8). These + Information Bases record the interface configuration of the + router, as well as the local connectivity, up to two hops away. + All updates to the elements specified in this document are subject + to the constraints specified in Appendix B. + + o Through accessing an outgoing HELLO message prior to it being + transmitted over any MANET interface, and to add information + (e.g., TLVs) as specified in [RFC5444]. This may, for example, be + to allow a security protocol, as suggested in Section 17, to add a + TLV containing a cryptographic signature to the message, or be to + + + +Clausen, et al. Standards Track [Page 52] + +RFC 6130 MANET-NHDP April 2011 + + + allow inserting relay selection information into a HELLO message + by way of adding a TLV to an outgoing HELLO message prior to it + being transmitted. + + o Through accessing an incoming HELLO message, and potentially + discarding it prior to processing by this protocol. This may, for + example, allow a security protocol as suggested in Section 17 to + perform verification of HELLO message signatures and prevent + processing of unverifiable HELLO messages by this protocol. + + o Through accessing an incoming HELLO message after it has been + completely processed by this protocol. This may, in particular, + allow a protocol that has added information, such as relay + selection information by way of inclusion of appropriate TLVs, + access to such information after appropriate updates have been + recorded in the Information Bases in this protocol. + + o Through requesting that a HELLO message be generated at a specific + time. In that case, HELLO message generation MUST still respect + the constraints in Appendix B. + + Address objects in HELLO messages are processed according to their + associated Address Block TLVs. All such address objects are to be + processed according to this specification are associated with Address + Block TLVs with Type of LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS (and + type extension zero). Address objects not associated with an Address + Block TLV of any of these Types are therefore not processed by the + protocol described in this specification. + + A protocol, such as a MANET routing protocol, interacting with this + protocol may need to add information to HELLO messages. This may be + in the form of associating TLVs (of Type other than LOCAL_IF, + OTHER_NEIGHB, or LINK_STATUS) to address objects already included by + this specification. + + A protocol, such as a MANET routing protocol, interacting with this + protocol may also add information to HELLO messages by inserting + address objects not already included by this specification. Such + address objects are in the following called "inserted addresses". + These inserted addresses may added to Address Blocks already present + by virtue of the HELLO message generation in this specification, or + may appear in new Address Blocks. In both cases, the following MUST + be observed: + + o An inserted address MUST NOT be associated with an Address Block + TLV of Type LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS. Consequently, + the processing in this specification will ignore such address + objects. + + + +Clausen, et al. Standards Track [Page 53] + +RFC 6130 MANET-NHDP April 2011 + + + o Each inserted address MUST be associated with an Address Block + TLV, to be defined by the specification of the protocol inserting + the address object. In this way, all addresses present in a HELLO + message are associated with an Address Block TLV defining their + semantics. + + Informally speaking, Address Block TLVs define the semantics of + address objects in an Address Block. If an address object in an + Address Block does not have any Address Block TLVs associated, that + address object has no semantics. Consequently, all protocols using + the protocol defined in this specification MUST respect the + following: + + o An address object in an Address Block, which is not associated + with any Address Block TLV, MUST be silently ignored; the mere + presence of an address object without an associated Address Block + TLV in a HELLO message MUST NOT cause any processing. + + A protocol interacting with this protocol MAY also add an originator + address to HELLO messages, as specified in [RFC5444]. Such an + originator address MUST be unique to the originating router, it MAY + be a local interface address of the router. It SHOULD be used + consistently, but SHOULD NOT be constrained in any other way. + + Strict adherence to these points will enable unambiguous coexistence + of future "extensions" to HELLO messages. + + In some cases, a protocol interacting with the protocol defined in + this specification, may need to recognize which HELLO messages to + process and which HELLO messages to discard. It is the + responsibility of that protocol to ensure that such messages are + suitably identifiable, e.g., through inclusion of a Message TLV or + through recognizing an administrative configuration (such as address + ranges). Note that such a protocol interacting with this protocol + MAY specify such interaction by recognizing an additional reason for + discarding a message. As suggested in Section 17 this might, for + example, be a security protocol discarding a message that does not + carry a Message TLV containing a cryptographic signature. + +17. Security Considerations + + The objective of this protocol is to allow each router in the network + to acquire information describing its 1-hop neighborhood and + symmetric 2-hop neighborhood. This is acquired through HELLO message + exchange between neighboring routers. This information is made + available through the Interface Information Bases and Neighbor + Information Base, describing the router's 1-hop neighborhood and + symmetric 2-hop neighborhood. + + + +Clausen, et al. Standards Track [Page 54] + +RFC 6130 MANET-NHDP April 2011 + + + Under normal circumstances, the information recorded in these + Information Bases is correct, i.e., corresponds to the actual network + topology, apart from any changes that have not (yet) been tracked by + the HELLO message exchanges. + + If a router for some reason, whether malice or malfunction, transmits + invalid HELLO messages, incorrect information may be recorded in + other routers' Information Bases. This protocol specification does, + however, prevent inconsistent information from being included in the + Information Bases through the specified processing, which maintains + the constraints in Appendix B. The exact consequence of information + inexactness depends on the use of these Information Bases, and SHOULD + therefore be reflected in the specification of protocols that use + information provided by this neighborhood discovery protocol. + + This section, therefore, firstly outlines the ways in which correctly + formed, but still invalid, HELLO messages may appear, in + Section 17.1. + + Injection of invalid HELLO messages into a network may be prevented + in a number of ways. If, for example, a network is deployed in a + site to which access is strictly regulated, so that physical access + and proximity to the network is prevented, then further security + mechanisms to protect against malicious routers injecting invalid + HELLO messages may not be required. Similarly, if the link layer + over which the network is formed provides appropriate + confidentiality, authentication, and integrity, then this may, for a + given deployment, suffice to appropriately protect against disclosure + of information to an eavesdropper, and against a malicious router + injecting invalid HELLO messages. In the latter case, the link layer + would discard frames that fail the link-layer checks, without + attempting to deliver such frames to IP. Finally, certain usage may + be of a nature where disruption of service is of no consequence, or + at least not of sufficient consequence to warrant deployment of + additional security mechanisms. + + A further point to stress, and which follows from the discussions + above is, that it will not be the case that "one size security fits + all". Different deployments may have different requirements. For + example, in a deployment of a low-value sensor network, + authentication using a simple message authentication code and shared + symmetric keys may suffice, while anything beyond that may require + too many computational resources to be viable. Conversely, in, for + example, a community network, verifying not only that the originator + of a HELLO message "has the right key" but also the precise identity + of the originator may be required to be proved, and computational + resources may be available to make such a requirement feasible. + + + + +Clausen, et al. Standards Track [Page 55] + +RFC 6130 MANET-NHDP April 2011 + + + Section 17.2, therefore, does not specify a single "one-size-fits- + all" mechanism, but rather details how the security suggestions in + [RFC5444] are considered for applicability within the context of this + protocol, and with the purpose of aiding deployment-specific security + mechanisms to be developed. + +17.1. Invalid HELLO Messages + + A correctly formed, but still invalid, HELLO message may take any of + the following forms. Note that a present or absent address object in + an Address Block, does not by itself cause a problem. It is the + presence, absence, or incorrectness of associated LOCAL_IF, + LINK_STATUS, and OTHER_NEIGHB Address Block TLVs that causes + problems. + + A router may provide false information about its own identity: + + o The HELLO message may contain address objects with an + associated LOCAL_IF Address Block TLV that do not correspond to + addresses of interfaces of the router transmitting the HELLO + message. + + o The HELLO message may omit network addresses, or their + associated LOCAL_IF Address Block TLV, of interfaces of the + router transmitting the HELLO message (other than the allowed + omission of the only local interface network address of the + MANET interface over which the HELLO message is transmitted, if + that is the case). + + o The HELLO message may incorrectly specify the LOCAL_IF Address + Block TLV Value associated with one or more local interface + network addresses, indicating incorrectly whether they are + associated with the MANET interface over which the HELLO + message is transmitted. + + A router may provide false information about the identity of other + routers: + + o A present LINK_STATUS Address Block TLV may, incorrectly, + identify a network address as being of a MANET interface that + is or was heard on the MANET interface over which the HELLO + message is transmitted. + + o A consistently absent LINK_STATUS Address Block TLV may, + incorrectly, fail to identify a network address as being of a + MANET interface that is or was heard on the MANET interface + over which the HELLO message is transmitted. + + + + +Clausen, et al. Standards Track [Page 56] + +RFC 6130 MANET-NHDP April 2011 + + + o A present OTHER_NEIGHB Address Block TLV may, incorrectly, + identify a network address as being of a router that is or was + in the sending router's symmetric 1-hop neighborhood. + + o A consistently absent OTHER_NEIGHB Address Block TLV may, + incorrectly, fail to identify a network address as being of a + router that is or was in the sending router's symmetric 1-hop + neighborhood. + + o The Value of a LINK_STATUS Address Block TLV may incorrectly + indicate the status (LOST, SYMMETRIC or HEARD) of the link from + a 1-hop neighbor. + + o The Value of an OTHER_NEIGHB Address Block TLV may incorrectly + indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop + neighbor. + +17.2. Authentication, Integrity, and Confidentiality Suggestions + + The security suggestions in [RFC5444] regarding inclusion of a + cryptographic signature in a Message TLV or a Packet TLV can be + applied to this protocol. Failure to verify either form of + cryptographic signature should cause a HELLO message to be rejected + without being processed. + + The following simplification of the suggestions for end-to-end + authentication for integrity in [RFC5444] may be applied to HELLO + messages: + + o As the Message Header fields <msg-hop-count> and <msg-hop-limit> + are either omitted or will always have the values 0 and 1, + respectively, an end to end cryptographic signature can be + calculated based on the entire HELLO message, including its + unmodified Message Header. + + The security mechanisms suggested in [RFC5444] with respect to + confidentiality can be directly applied to this protocol. + +18. IANA Considerations + + This specification defines one Message Type, which has been allocated + from the "Message Types" registry of [RFC5444], and three Address + Block TLV Types, which have been allocated from the "Address Block + TLV Types" registry of [RFC5444]. + + + + + + + +Clausen, et al. Standards Track [Page 57] + +RFC 6130 MANET-NHDP April 2011 + + +18.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]. + +18.2. Message Types + + This specification defines one Message Type, which has been allocated + from the 0-223 range of the "Message Types" namespace defined in + [RFC5444], as specified in Table 3. + + +------+-------------------------+ + | Type | Description | + +------+-------------------------+ + | 0 | HELLO : Local signaling | + +------+-------------------------+ + + Table 3: Message Type Assignment + +18.3. Message-Type-Specific TLV Type Registries + + IANA has created a registry for Message-Type-specific Message TLVs + for HELLO messages, in accordance with Section 6.2.1 of [RFC5444], + and with initial assignments and allocation policies as specified in + Table 4. + + +---------+-------------+-------------------+ + | Type | Description | Allocation Policy | + +---------+-------------+-------------------+ + | 128-223 | Unassigned | Expert Review | + +---------+-------------+-------------------+ + + Table 4: HELLO Message-Type-specific Message TLV Types + + IANA has created a registry for Message-Type-specific Address Block + TLVs for HELLO messages, in accordance with Section 6.2.1 of + [RFC5444], and with initial assignments and allocation policies as + specified in Table 5. + + +---------+-------------+-------------------+ + | Type | Description | Allocation Policy | + +---------+-------------+-------------------+ + | 128-223 | Unassigned | Expert Review | + +---------+-------------+-------------------+ + + Table 5: HELLO Message-Type-specific Address Block TLV Types + + + + +Clausen, et al. Standards Track [Page 58] + +RFC 6130 MANET-NHDP April 2011 + + +18.4. Address Block TLV Types + + This specification defines three Address Block TLV Types, which have + been allocated from the "Address Block TLV Types" namespace defined + in [RFC5444]. IANA has made allocations in the 0-127 range for these + types. Three new type extension registries have been created, with + assignments as specified in Tables 6, 7, and 8. Specifications of + these Address Block TLVs are in Section 10.1.1, with Value Constants + defined in Section 18.5. + + +----------+------+-----------+------------------------+------------+ + | Name | Type | Type | Description | Allocation | + | | | extension | | policy | + +----------+------+-----------+------------------------+------------+ + | LOCAL_IF | 2 | 0 | Specifies that the | | + | | | | network address is | | + | | | | associated with this | | + | | | | local interface of the | | + | | | | sending router | | + | | | | (THIS_IF = 0) or | | + | | | | another local | | + | | | | interface of the | | + | | | | sending router | | + | | | | (OTHER_IF = 1) | | + | LOCAL_IF | 2 | 1-255 | Unassigned | Expert | + | | | | | Review | + +----------+------+-----------+------------------------+------------+ + + Table 6: Address Block TLV Type Assignment: LOCAL_IF + + +-------------+------+-----------+---------------------+------------+ + | Name | Type | Type | Description | Allocation | + | | | extension | | policy | + +-------------+------+-----------+---------------------+------------+ + | LINK_STATUS | 3 | 0 | Specifies the | | + | | | | status of the link | | + | | | | from the indicated | | + | | | | network address | | + | | | | (LOST = 0, | | + | | | | SYMMETRIC = 1, or | | + | | | | HEARD = 2) | | + | LINK_STATUS | 3 | 1-255 | Unassigned | Expert | + | | | | | Review | + +-------------+------+-----------+---------------------+------------+ + + Table 7: Address Block TLV Type Assignment: LINK_STATUS + + + + + +Clausen, et al. Standards Track [Page 59] + +RFC 6130 MANET-NHDP April 2011 + + + +--------------+------+-----------+--------------------+------------+ + | Name | Type | Type | Description | Allocation | + | | | extension | | policy | + +--------------+------+-----------+--------------------+------------+ + | OTHER_NEIGHB | 4 | 0 | Specifies the | | + | | | | status of the | | + | | | | relationship with | | + | | | | the router that | | + | | | | uses the indicated | | + | | | | network address on | | + | | | | one or more | | + | | | | interfaces (LOST = | | + | | | | 0, or SYMMETRIC = | | + | | | | 1) | | + | OTHER_NEIGHB | 4 | 1-255 | Unassigned | Expert | + | | | | | Review | + +--------------+------+-----------+--------------------+------------+ + + Table 8: Address Block TLV Type Assignment: OTHER_NEIGHB + +18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values + + Note: This information is recorded here for clarity and for use + elsewhere in this specification. The information required by IANA is + included in the descriptions of the Address Block TLVs allocated in + Section 18.4. + + The Values that the LOCAL_IF Address Block TLV can use are the + following: + + o THIS_IF := 0 + + o OTHER_IF := 1 + + The Values that the LINK_STATUS Address Block TLV can use are the + following: + + o LOST := 0 + + o SYMMETRIC := 1 + + o HEARD := 2 + + The Values that the OTHER_NEIGHB Address Block TLV can use are the + following: + + o LOST := 0 + + + + +Clausen, et al. Standards Track [Page 60] + +RFC 6130 MANET-NHDP April 2011 + + + o SYMMETRIC := 1 + +19. Contributors + + This specification is the result of the joint efforts of the + following contributors from the OLSRv2 Design Team, listed + alphabetically: + + o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil> + + o Cedric Adjih, INRIA, France, <Cedric.Adjih@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 ATC, UK, + <chris.dearlove@baesystems.com> + + o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> + +20. Acknowledgments + + The authors would like to acknowledge the team behind OLSRv1, + specified in RFC3626 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): Alan Cullen + (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe + Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA), + and the entire IETF MANET working group. + + + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 61] + +RFC 6130 MANET-NHDP April 2011 + + +21. References + +21.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. + + [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. + +21.2. Informative References + + [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking + (MANET): Routing Protocol Performance Issues and + Evaluation Considerations", RFC 2501, January 1999. + + [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing + Protocol (OLSR)", RFC 3626, October 2003. + + [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, + "OSPF Multipoint Relay (MPR) Extension for Ad Hoc + Networks", RFC 5449, February 2009. + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 62] + +RFC 6130 MANET-NHDP April 2011 + + +Appendix A. Address Block TLV Combinations + + The algorithm for generating HELLO messages in Section 11 specifies + which 1-hop neighbor network addresses may be included in the Address + Blocks, and with which associated Address Block TLVs. These Address + Block TLVs may have Type = LINK_STATUS or Type = OTHER_NEIGHB, or + both. Address Block TLVs with Type = LINK_STATUS may have three + possible Values (Value = HEARD, Value = SYMMETRIC, or Value = LOST), + and Address Block TLVs of TYPE = OTHER_NEIGHB may have two possible + Values (Value = SYMMETRIC or Value = LOST). When both Address Block + TLVs are associated with the same network address only certain + combinations of these Address Block TLV Values are necessary, and are + the only combinations generated by the algorithm in Section 11. + These combinations are indicated in Table 9. + + Cells labeled with "Yes" indicate the possible combinations that are + generated by the algorithm in Section 11. Cells labeled with "No" + indicate combinations not generated by the algorithm in Section 11 + but that are correctly parsed and interpreted by the algorithm in + Section 12. The cell labeled with "No*" is actually inconsistent, it + is handled by ignoring the Address Block TLV with Type = + OTHER_NEIGHB, but SHOULD NOT be used. + + +----------------+----------------+----------------+----------------+ + | | Type = | Type = | Type = | + | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | + | | (absent) | Value = | Value = LOST | + | | | SYMMETRIC | | + +----------------+----------------+----------------+----------------+ + | Type = | No | Yes | Yes | + | LINK_STATUS | | | | + | (absent) | | | | + | Type = | Yes | Yes | Yes | + | LINK_STATUS, | | | | + | Value = HEARD | | | | + | Type = | Yes | No | No* | + | LINK_STATUS, | | | | + | Value = | | | | + | SYMMETRIC | | | | + | Type = | Yes | Yes | No | + | LINK_STATUS, | | | | + | Value = LOST | | | | + +----------------+----------------+----------------+----------------+ + + Table 9: LINK_STATUS and OTHER_NEIGHB TLV Combinations + + + + + + +Clausen, et al. Standards Track [Page 63] + +RFC 6130 MANET-NHDP April 2011 + + +Appendix B. Constraints + + Any process that updates the Local Information Base or the Neighbor + Information Base MUST ensure that all constraints specified in this + appendix are maintained. + + In each Local Interface Tuple: + + o I_local_iface_addr_list MUST NOT be empty. + + o I_local_iface_addr_list MUST NOT contain any duplicated network + addresses. + + o If I_manet = true, then I_local_iface_addr_list MUST NOT contain + any network address that overlaps any network address in the + I_local_iface_addr_list of any other Local Interface Tuple with + I_manet = true, unless it is known that the corresponding MANET + interfaces will always communicate with separate sets of MANET + interfaces on other routers. + + In each Removed Interface Address Tuple: + + o IR_local_iface_addr MUST NOT contain any network address that is + in the I_local_iface_addr_list of any Local Interface Tuple. + + o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any + other Removed Interface Address Tuple. + + In each Link Tuple: + + o L_neighbor_iface_addr_list MUST NOT be empty. + + o L_neighbor_iface_addr_list MUST NOT contain any network address + that overlaps any network address in the I_local_iface_addr_list + of any Local Interface Tuple or the IR_local_iface_addr of any + Removed Interface Address Tuple. + + o L_neighbor_iface_addr_list MUST NOT contain any duplicated network + addresses. + + o L_neighbor_iface_addr_list MUST NOT contain any network address + which is in the L_neighbor_iface_addr_list of any other Link Tuple + in the same Link Set. + + o If L_HEARD_time has not expired, then there MUST be a Neighbor + Tuple whose N_neighbor_addr_list contains + L_neighbor_iface_addr_list. + + + + +Clausen, et al. Standards Track [Page 64] + +RFC 6130 MANET-NHDP April 2011 + + + o L_HEARD_time MUST NOT be greater than L_time. + + o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are + expired). + + o L_quality MUST NOT be less than 0 or greater than 1. + + o If L_quality >= HYST_ACCEPT, then L_pending MUST be false. + + o If L_quality < HYST_REJECT, then L_status MUST be PENDING or LOST. + + o L_pending MUST NOT be set to true if it is currently false. + + In each Neighbor Tuple: + + o N_neighbor_addr_list MUST NOT contain any network address that + overlaps any network address in the I_local_iface_addr_list of any + Local Interface Tuple or the IR_local_iface_addr of any Removed + Interface Address Tuple. + + o N_neighbor_addr_list MUST NOT contain any duplicated network + addresses. + + o N_neighbor_addr_list MUST NOT contain any network address that is + in the N_neighbor_addr_list of any other Neighbor Tuple. + + o If N_symmetric is = true, then there MUST be one or more Link + Tuples with: + + o L_neighbor_iface_addr_list contained in N_neighbor_addr_list; + AND + + o L_status = SYMMETRIC. + + o If N_symmetric is = false, then there MUST be one or more Link + Tuples with: + + o L_neighbor_iface_addr_list contained in N_neighbor_addr_list. + + All such Link Tuples MUST NOT have L_status = SYMMETRIC. At least + one such Link Tuple MUST have L_HEARD_time not expired. + + In each Lost Neighbor Tuple: + + o NL_neighbor_addr MUST NOT overlap any network address in the + I_local_iface_addr_list of any Local Interface Tuple or the + IR_local_iface_addr of any Removed Interface Address Tuple. + + + + +Clausen, et al. Standards Track [Page 65] + +RFC 6130 MANET-NHDP April 2011 + + + o NL_neighbor_addr MUST NOT equal the NL_neighbor_addr of any other + Lost Neighbor Tuple. + + o NL_neighbor_addr MUST NOT be in the N_neighbor_addr_list of any + Neighbor Tuple with N_symmetric = true. + + In each 2-Hop Tuple: + + o There MUST be a Link Tuple associated with the same MANET + interface with: + + o L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND + + o L_status = SYMMETRIC. + + o N2_2hop_addr MUST NOT overlap any network address in the + I_local_iface_addr_list of any Local Interface Tuple or the + IR_local_iface_addr of any Removed Interface Address Tuple. + + o N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple + in the same 2-Hop Set and with the same + N2_neighbor_iface_addr_list. + + o N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the + same 2-Hop Tuple. + +Appendix C. HELLO Message Example + + HELLO messages are instances of [RFC5444] messages, and this protocol + supports any combination of 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 HELLO + messages look. This appendix illustrates two HELLO message with + similar content, the exact values included are explained in the + following text. + + The HELLO message's four bit Message Flags (MF) field has value 7 + indicating that the message header contains 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 message is as + transmitted, with a hop limit of 1 and a hop count of 0. The overall + message length is 45 octets. + + The message contains a Message TLV Block with content length 8 octets + containing two Message TLVs, of types VALIDITY_TIME and + INTERVAL_TIME. Each uses a Message TLV with Flags octet (MTLVF) + value 16, indicating that each has a Value, and each has a Value + + + +Clausen, et al. Standards Track [Page 66] + +RFC 6130 MANET-NHDP April 2011 + + + Length of 1 octet. The Values included are time codes (as defined in + [RFC5497]) representing the parameters H_HOLD_TIME and + HELLO_INTERVAL, respectively. + + The message has a single Address Block containing 5 addresses. The + Address Block Flags octet (ABF) value 128 indicates an address Head + but no address Tail, and no address prefixes. The Head Length of 3 + octets indicates address Mid sections of one octet each (Mid 0 to Mid + 4). + + The following Address Block TLV Block (content length 14 octets) + includes two Address Block TLVs. The first is a LOCAL_IF Address + Block TLV with Flags octet (ATLVF) value 80, which indicates that a + single address, with index 0 (i.e., the address Head:Mid 0) is the + single local interface address of this router (the one octet Value + THIS_IF indicates that this address is of this interface). The + second is a LINK_STATUS Address Block TLV with Flags octet (ATLVF) + value 52, which specifies the link status values of all reported + neighbors in a single multivalue Address Block TLV that covers the + addresses with indexes 1 to 4, inclusive. The Address Block TLV + Value Length of 4 octets indicates one octet per Value per address. + The last four addresses thus are of neighbors, each an with + associated link status: the first and second HEARD, the third + SYMMETRIC, and the fourth LOST. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 67] + +RFC 6130 MANET-NHDP April 2011 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HELLO | MF=7 | MAL=3 | Message Length = 45 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hop Limit = 1 | Hop Count = 0 | Message Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value Len = 1 | Value (Time) | Num Addrs = 5 | ABF = 128 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Head Len = 3 | Head | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mid 0 | Mid 1 | Mid 2 | Mid 3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mid 4 | Address TLV Block Length = 14 | LOCAL_IF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ATLVF = 80 | Index = 0 | Value Len = 1 | THIS_IF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LINK_STATUS | ATLV = 52 | Strt Indx = 1 | Stop Indx = 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value Len = 4 | HEARD | HEARD | SYMMETRIC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LOST | + +-+-+-+-+-+-+-+-+ + + Note that this example is for illustrative purposes. The essential + information can be conveyed, more efficiently (assuming that the + local interface address will be supplied by IP, and that the + INTERVAL_TIME TLV is not needed) by the 29 octets: + + + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 68] + +RFC 6130 MANET-NHDP April 2011 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HELLO |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 1 1| Head | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mid 1 | Mid 2 | Mid 3 | Mid 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LOST | + +-+-+-+-+-+-+-+-+ + + Note that the above example assumes that H_HOLD_TIME and C have their + default values of 6 seconds and 1/1024 second, and thus result in a + time code of 100 (hexadecimal 64). + +Appendix D. Flow and Congestion Control + + This protocol specifies one Message Type, the HELLO message. The + maximum size of a HELLO message is proportional to the size of the + originating router's 1-hop neighborhood. HELLO messages MUST NOT be + forwarded. + + A router MUST report its 1-hop neighborhood in HELLO messages on each + of its MANET interfaces at least each REFRESH_INTERVAL. This puts a + lower bound on the control traffic generated by each router in the + network employing this protocol. + + A router MUST ensure that two successive HELLO messages sent on the + same MANET interface are separated by at least HELLO_MIN_INTERVAL. + (If using jitter, then this may be reduced to a mean minimum value of + HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound + on the control traffic generated by each router in the network + employing this protocol. + + + + + + + + + +Clausen, et al. Standards Track [Page 69] + +RFC 6130 MANET-NHDP April 2011 + + +Appendix E. Interval and Timer Illustrations + + This informative appendix illustrates the relationship between + message timers and intervals. (The adjustments to this timing when + using timing jitter, as defined in [RFC5148], are not shown.) + +E.1. HELLO Message Generation Timing + + Figure 1 illustrates a basic HELLO message schedule for a router, on + a MANET interface, employing strictly periodic transmission of HELLO + messages. The router transmits a HELLO message each HELLO_INTERVAL. + Each HELLO message contains all 1-hop neighbor network addresses of + the router that are to be reported in any such HELLO message. (The + parameter REFRESH_INTERVAL, not shown, is in this example equal to + the parameter HELLO_INTERVAL.) + + The router includes a VALIDITY_TIME TLV in each HELLO message, + encoding the parameter H_HOLD_TIME, the duration for which + information received in the HELLO message should be considered valid + by receiving routers. Receiving routers will, when recording the + information received in the HELLO message, each use this for setting + the L_HEARD_time, L_SYM_time and L_time elements of their + corresponding Link Tuple, and the N2_time in the corresponding 2-Hop + Tuple for each network address. Only L_time is illustrated in + Figure 1. + + H_HOLD_TIME: |-----------------------------| ... + + HELLO_INTERVAL: |---------|---------|---------| ... + + Time: ---*---------*---------*---------*------> + + ^ ^ ^ ^ + | | | | + HELLO (a, b, c, d) | | | + | | | + HELLO (a, b, c, d) | | ... + | | + HELLO (a, b, c, d) | + | + HELLO (a, b, c, d) + + L_time: |-----------------------------| + |-------------------- ... + |---------- ... + | ... + + Figure 1: HELLO Message Generation: Regular Schedule + + + +Clausen, et al. Standards Track [Page 70] + +RFC 6130 MANET-NHDP April 2011 + + + Figure 2 illustrates a message schedule similar to Figure 1, where + the router announces its own presence more frequently by sending + additional HELLO messages. HELLO messages are still sent regularly, + at a reduced interval defined by a new value of HELLO_INTERVAL. + However, REFRESH_INTERVAL has not been reduced. Each 1-hop neighbor + network address included in these HELLO messages need be advertised + only once within each REFRESH_INTERVAL. Consequently, the additional + HELLO messages due to the reduced value of HELLO_INTERVAL may + therefore be empty. (This is not the only allowed distribution of + 1-hop neighbor network addresses, they could, for example, be sent + alternately a, b and c, d.) + + H_HOLD_TIME: |-----------------------------| ... + + REFRESH_INTERVAL: |---------|---------|---------| ... + + HELLO_INTERVAL: |----|----|----|----|----|----| ... + + Time: ---*---------*---------*---------*------> + + ^ ^ ^ ^ ^ ^ ^ + | | | | | | | + HELLO (a, b, c, d) | | | | | | + | | | | | | + HELLO () | | | | | + | | | | | + HELLO (a, b, c, d) | | | | + | | | | ... + HELLO () | | | + | | | + HELLO (a, b, c, d) | | + | | + HELLO () | + | + HELLO (a, b, c, d) + + L_time: |-----------------------------| + |------------------------- ... + |-------------------- ... + |--------------- ... + |---------- ... + |----- ... + | ... + + Figure 2: HELLO Message Generation: Regular Schedule with Different + HELLO_INTERVAL and REFRESH_INTERVAL + + + + + +Clausen, et al. Standards Track [Page 71] + +RFC 6130 MANET-NHDP April 2011 + + + HELLO messages may also be sent in response to events. The minimal + interval between two successive HELLO message transmissions by a + router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO + message emission rate. Hence, for each HELLO message transmission, a + router must wait at least HELLO_MIN_INTERVAL before the next HELLO + message transmission. Similarly, the maximum interval between two + successive HELLO message transmissions is HELLO_INTERVAL, setting a + lower bound on the message transmission rate. Hence, for each HELLO + message transmission, the router must ensure that the next HELLO + message transmission must not wait more than HELLO_INTERVAL. + + Figure 3 illustrates a message schedule similar to Figure 1, but with + HELLO messages responding to events at maximum rate, i.e., with HELLO + messages being sent each HELLO_MIN_INTERVAL. Note that when a HELLO + message is sent, it is assumed that the following messages may all be + scheduled at an interval of HELLO_INTERVAL, and hence each HELLO + message contains all 1-hop neighbor network addresses. In each HELLO + message in this example, a new 1-hop neighbor network address is + added, reflecting the changes occurring since the last HELLO message + was sent. HELLO messages are sent at the maximum allowed rate in + order to signal these changes as rapidly as possible. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 72] + +RFC 6130 MANET-NHDP April 2011 + + + H_HOLD_TIME: |-----------------------------| ... + + HELLO_INTERVAL: |---------|---------|---------| ... + + HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ... + + Time: ---*---------*---------*---------*------> + + ^ ^ ^ ^ ^ ^ ^ + | | | | | | | + HELLO () | | | | | | + | | | | | | + HELLO (a) | | | | | + | | | | | + HELLO (a, b) | | | | + | | | | ... + HELLO (a, b, c) | | | + | | | + HELLO (a, b, c, d) | | + | | + HELLO (a, b, c, d, e) | + | + HELLO (a, b, c, d, e, f) + + L_time: |-----------------------------| + |------------------------- ... + |-------------------- ... + |--------------- ... + |---------- ... + |----- ... + | ... + + Figure 3: HELLO Message Generation: Regular Schedule with Responsive + Messages + + Figure 4 shows the same example as Figure 3, but with an increased + REFRESH_INTERVAL, and showing partial HELLO messages that include + only the necessary network addresses. + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 73] + +RFC 6130 MANET-NHDP April 2011 + + + H_HOLD_TIME: |-----------------------------| ... + + REFRESH_INTERVAL: |-------------------|---------- ... + |-------------------|----- ... + |-------------------| ... + |--------------- ... + |---------- ... + |----- ... + | ... + + HELLO_INTERVAL: |---------|---------|---------| ... + + HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ... + + Time: ---*---------*---------*---------*------> + + ^ ^ ^ ^ ^ ^ ^ + | | | | | | | + HELLO () | | | | | | + | | | | | | + HELLO (a) | | | | | + | | | | | + HELLO (b) | | | | + | | | | ... + HELLO (c) | | | + | | | + HELLO (a, d) | | + | | + HELLO (b, e) | + | + HELLO (c, f) + + L_time: |-----------------------------| + |------------------------- ... + |-------------------- ... + |--------------- ... + |---------- ... + |----- ... + | ... + + Figure 4: HELLO Message Generation: Regular Schedule with Responsive + Messages and Different HELLO_INTERVAL and REFRESH_INTERVAL + + + + + + + + + +Clausen, et al. Standards Track [Page 74] + +RFC 6130 MANET-NHDP April 2011 + + + Figure 5 summarizes the overall relationship between the intervals + governing HELLO message transmissions by a router. + + H_HOLD_TIME: |------------------------------------| + + REFRESH_INTERVAL: |----------------| + + HELLO_INTERVAL: |----------| + + HELLO_MIN_INTERVAL: |---| + + Time: -----------------------------------------------> + + ^ ^ ^ ^ ^ + | | | | | + | | | | Time up to which + HELLO message | | | received HELLO + transmission | | | message content + | | | is valid. + | | | + | | Time before which all + | | neighbor information must + | | be transmitted in HELLO + | | messages (one or more) + | | + | Latest time for next HELLO message + | transmission + | + Earliest time for next HELLO message + transmission + + Figure 5: HELLO Message Generation Intervals + + + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 75] + +RFC 6130 MANET-NHDP April 2011 + + +E.2. HELLO Message Processing Timing + + Figure 6 illustrates the Link Set timers when receiving a HELLO + message not including the network address of the receiving MANET + interface. + + VALIDITY_TIME: |--------------------------| + + L_time: |--------------------------| + + L_HEARD_time: |--------------------------| + + L_SYM_time: *-| (i.e., expired) + + Time: ---*--------------------------------> + ^ + | + HELLO () received + + Figure 6: HELLO Message Processing: Network Address Not Present + + Figure 7 illustrates the Link Set timers when, following the received + HELLO message illustrated in Figure 6, a router receives a HELLO + message including the network address (a) of the receiving interface + with link status = HEARD (or SYM). + + VALIDITY_TIME: |--------------------------| + |--------------------------| + + L_time: |--------------------------| + |--------------------------| + + L_HEARD_time: |--------------------------| + |--------------------------| + + L_SYM_time: *-| (i.e., expired) + L_SYM_time: |--------------------------| + + Time: -*-----*---------------------------------> + ^ ^ + | | + HELLO () received | + | + HELLO (a:HEARD) received + + Figure 7: HELLO Message Processing: Network Address Present + + + + + +Clausen, et al. Standards Track [Page 76] + +RFC 6130 MANET-NHDP April 2011 + + + Figure 8 illustrates the Link Set timers when, following the received + HELLO messages illustrated in Figure 7, a router receives a HELLO + message including the network address (a) of the receiving interface + with link status = LOST. + + VALIDITY_TIME: |--------------------------| + |--------------------------| + |--------------------------| + + L_time: |--------------------------| + |--------------------------| + |--------------------------| + + L_HEARD_time: |--------------------------| + |--------------------------| + |--------------------------| + + L_SYM_time: *-| (i.e., expired) + |--------------------------| + *-| (i.e., expired) + + Time: -*-----*-----*---------------------------------> + ^ ^ ^ + | | | + HELLO () received | | + | | + HELLO (a:HEARD) received | + | + HELLO (a:LOST) received + + Figure 8: HELLO Message Processing: Network Address Lost + +E.3. Other HELLO Message Timing + + There are three other timing parameters that are used by a router to + control HELLO message generation and processing. + + Figure 9 illustrates the time, with duration L_HOLD_TIME, during + which the appropriate network addresses of a formerly, but no longer, + symmetric 1-hop neighbor, as connected by this MANET interface, are + advertised as LOST using a LINK_STATUS TLV in HELLO messages on this + MANET interface, thus allowing that 1-hop neighbor to update its Link + Set accordingly. + + + + + + + + +Clausen, et al. Standards Track [Page 77] + +RFC 6130 MANET-NHDP April 2011 + + + L_HOLD_TIME: |----------------------------| + + Time: ---*----------------------------------> + ^ ^ + | | + Formerly symmetric 1-hop neighbor | + ceases to be symmetric on this | + MANET interface | + | + Time up to which network addresses of + this neighbor connected using this MANET + interface are advertised in HELLO + messages on this MANET interface + using a LINK_STATUS TLV, Value = LOST + + Figure 9: HELLO Message Generation: Advertisement of Formerly + Symmetric 1-Hop Neighbor on This MANET Interface as Lost + + Figure 10 illustrates the time, with duration N_HOLD_TIME, during + which all network addresses of a formerly, but no longer, symmetric + 1-hop neighbor, are advertised as LOST in HELLO messages on all MANET + interfaces using an OTHER_NEIGHB TLV (if not also reported using a + LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to + update their 2-Hop Sets accordingly. + + L_HOLD_TIME: |----------------------------| + + Time: ---*----------------------------------> + ^ ^ + | | + Formerly symmetric 1-hop neighbor | + ceases to be symmetric | + | + Time up to which network addresses of + this neighbor are advertised in HELLO + messages on all MANET interfaces + using an OTHER_NEIGHB TLV, + Value = LOST + + Figure 10: HELLO Message Generation: Advertisement of Formerly + Symmetric 1-Hop Neighbor on Any MANET Interface as Lost + + Figure 11 illustrates the time, with duration I_HOLD_TIME, during + which a formerly, but no longer, used local interface network address + is excluded from being considered as a 2-hop neighbor network address + (in order that a router is not recorded as its own 2-hop neighbor + during that period). + + + + +Clausen, et al. Standards Track [Page 78] + +RFC 6130 MANET-NHDP April 2011 + + + I_HOLD_TIME: |----------------------------| + + Time: ---*-----------------------------------> + ^ ^ + | | + Formerly used local interface | + network address ceases to be | + assigned to a local interface | + | + Time up to which this network + address is excluded from being + included in this router's 2-Hop Set + + Figure 11: Local Interface Removed Network Address + +Appendix F. Topology Pictures + + This appendix illustrates various examples of physical topologies, as + well as how these are logically recorded by NHDP from the point of + view of the router A. This representation is a composite of + information that would be contained within A's various Information + Bases after NHDP has been running for sufficiently long time for the + state to converge. + + Note that the examples given in this appendix are NOT exhaustive, but + are selected to be illustrative of NHDP neighborhood representations + of physical MANET topologies. + + The example topologies presented contain 3 physical routers A, B, and + C. Each of these routers has one or two distinct interfaces, + denoted "top" and "bottom". Each interface has one or two addresses, + and symmetric connectivity between a pair of interfaces is + illustrated by these being connected by a line. + + In all examples, the topology is described as it is recorded by NHDP + in router A. + +F.1. Example 1: Standard Single Interface Topology + + In Figure 12, each router has a single interface, each with a single + IP address. This is the simplest possible network, and the resulting + representation is given to the right in Figure 12. + + + + + + + + + +Clausen, et al. Standards Track [Page 79] + +RFC 6130 MANET-NHDP April 2011 + + + __________ __________ + | | | + {1} {2} {3} + | | | {1}--------{2}--------{3} + +--'--+ +--'--+ +--'--+ + | A | | B | | C | + +-----+ +-----+ +-----+ + + Figure 12: Standard Single Interface Topology (Left), and + Corresponding NHDP Representation (Right) + + The Local Information Set in A contains a single Local Interface + Tuple that has an I_local_iface_addr_list of {1}. This value is + denoted with a {1} on the leftmost part of the resulting + representation. + + The Interface Information Base has only one Link Set, which + represents the "top" interface of A, or {1}. This Link Set's only + Link Tuple has an L_neighbor_iface_addr_list containing {2}; this + corresponds to the dashed line from {1} to {2} to the right in + Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with + N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}; + this corresponds to the dashed line from {2} to {3} to the right in + Figure 12. + + The descriptions of the following examples in this appendix will be + derived similarly, and use the same notational conventions. + +F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor + + In Figure 13, the network is identical to that in Example 1, except + that the middle router, B, has two IP addresses on its single + interface. + + __________ __________ + | | | + {1} {2,4} {3} + | | | {1}-------{2,4}-------{3} + +--'--+ +--'--+ +--'--+ + | A | | B | | C | + +-----+ +-----+ +-----+ + + Figure 13: Single Interfaces, with 1-Hop Neighbor B Having Two + Addresses (Left), and Corresponding NHDP Representation (Right) + + + + + + + +Clausen, et al. Standards Track [Page 80] + +RFC 6130 MANET-NHDP April 2011 + + + The content of the Interface Information Base is in this case + identical to Example 1, except that L_neighbor_iface_addr_list is + {2,4} and N2_neighbor_iface_addr_list is {2,4}. + +F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor + + In Figure 14, the network is identical to that in Example 1, except + that the rightmost router, C, has two IP addresses on its interface. + + __________ __________ + | | | + {1} {2} {3,4} +----{3} + | | | {1}--------{2}---+ + +--'--+ +--'--+ +--'--+ +----{4} + | A | | B | | C | + +-----+ +-----+ +-----+ + + Figure 14: Single Interfaces, with 2-Hop Neighbor C Having Two + Addresses (Left), and Corresponding NHDP Representation (Right) + + The content of the Interface Information Base is in this case + identical to than in Example 1, except that the 2-Hop Set contains an + extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and + N2_2hop_addr being {4}. These two 2-Hop Tuples are illustrated by + the two lines from {2} to {3} and (2) to {4}, respectively. + +F.4. Example 4: Dual Addressed Interfaces + + In Figure 15, the network is identical to that in Example 1, except + that all routers have two IP addresses on their interface. The Local + Information Base in router A is the same as in Example 1, except that + I_local_iface_addr_list is {1,5}. + + __________ __________ + | | | + {1,5} {2,6} {3,4} +----{3} + | | | {1,5}------{2,6}--+ + +--'--+ +--'--+ +--'--+ +----{4} + | A | | B | | C | + +-----+ +-----+ +-----+ + + Figure 15: Single interfaces, all routers having two addresses + (left), and corresponding NHDP representation (right) + + The content of the Interface Information Base is in this case a + combination of the Interface Information Bases from Examples 1, 2, + and 3. + + + + +Clausen, et al. Standards Track [Page 81] + +RFC 6130 MANET-NHDP April 2011 + + +F.5. Example 5: Dual Interface on 2-Hop Neighbor + + In Figure 16, all routers have a single IP address on each interface, + and with the 2-hop neighbor having two interfaces. + + __________ __________ + | | | + {1} {2} {3} +----{3} + | | | {1}--------{2}---+ + +--'--+ +--'--+ +-----+ +----{4} + | A | | B | | C | + +-----+ +-----+ +-----+ + | + {4} + + Figure 16: Single Addresses, with 2-Hop Neighbor C Having Two + Interfaces (Left), and Corresponding NHDP Representation (Right) + + The Interface Information Base is identical to that in Example 3; + NHDP does not distinguish topologically between this example and + Example 3. + +F.6. Example 6: Dual interface on 1-Hop Neighbor + + In Figure 17, all routers have a single IP address on each interface, + and with the 1-hop neighbor having two interfaces. + + __________ + | | + {1} {2} +-----+ + | | {1}-------| {2} |------{4} + +--'--+ +--'--+ +-----+ | {5} | + | A | | B | | C | +-----+ + +-----+ +-----+ +-----+ + | | + {5} {4} + |__________| + + Figure 17: Single Addresses, with 1-Hop Neighbor B Having Two + Interfaces (Left), and Corresponding NHDP Representation (Right) + + The Local Information Base is identical to that in Example 1. + + The Interface Information Base has only one Link Set containing one + Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set + contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being + {2} and N2_2hop_addr being {4}. + + + + +Clausen, et al. Standards Track [Page 82] + +RFC 6130 MANET-NHDP April 2011 + + + The Neighbor Information Base contains a Neighbor Set containing a + single Neighbor Tuple, which represents router B, with + N_neighbor_addr_list being {2,5}. This entry is represented on the + right of Figure 17 by boxing {2} with {5}. + + Note that router A does not have information indicating which of + router B's interfaces is connected to router C. However, router A + knows that the address {4} (and thus router C) is reachable by using + {2} as next hop. + +F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors + + In Figure 18, all routers have a single IP address on each interface, + and both the 1-hop and 2-hop neighbors have two interfaces. + Furthermore, there are now two physical links between routers B and + C, over distinct interface pairs. + + __________ __________ + | | | + {1} {2} {3} +-----+ +----{3} + | | | {1}-------| {2} |---+ + +--'--+ +--'--+ +-----+ | {5} | +----{4} + | A | | B | | C | +-----+ + +-----+ +-----+ +-----+ + | | + {5} {4} + |__________| + + Figure 18: Single Addresses, with 1-Hop and 2-Hop Neighbors B and C + Having Two Interfaces (Left), and Corresponding NHDP Representation + (Right) + + The Local Information Base is identical to that in Example 1. + + The Link Set is identical to that in Example 6, and the 2-Hop Set + contains, as in Example 5 (and similarly to Examples 3 and 4), two + 2-Hop Tuples representing the two links between routers B and C. + + Note that router A does not have information describing which of + router B's interfaces is connected to which interfaces of router C, + or even that the interfaces with addresses {3} and {4} are interfaces + of the same router. However, router A knows that the addresses {3} + and {4} (and thus router C) are reachable using {2} as next hop. + + + + + + + + +Clausen, et al. Standards Track [Page 83] + +RFC 6130 MANET-NHDP April 2011 + + +F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor + + In Figure 19, all routers have a single IP address on each interface, + and both A and its the 1-hop neighbor B have two interfaces. + Furthermore, there are now two physical links between routers A and + B, over distinct interface pairs. + + __________ __________ + | | | +-----+ + {1} {2} {3} {1}-------| {2} |--------{3} + | | | | {5} | + +--'--+ +--'--+ +-----+ +-----+ + | A | | B | | C | + +-----+ +-----+ +-----+ +-----+ + | | | {2} | + {6} {5} {6}-------| {5} |--------{3} + |__________| +-----+ + + Figure 19: Single Addresses, with Both A and 1-Hop Neighbor B Having + Two Interfaces (Left), and Corresponding NHDP Representation (Right) + + The Local Information Set contains two Local Interface Tuples, with + I_local_iface_addr_list of {1} and {6}, respectively. + + Each Interface Information Base's Link Set contains one Link Tuple, + representing the links between {1} and {2}, and between {6} and {5}, + respectively. The 2-Hop Set for interface {1} contains a single + 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and + N2_2hop_addr being {3}. The 2-Hop Set for interface {6} contains a + single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and + N2_2hop_addr being {3}. + + The Neighbor Information Base contains a Neighbor Set containing a + single Neighbor Tuple, which represents router B, with + N_neighbor_addr_list being {2,5}. This entry is denoted by boxing + {2} with {5}. + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 84] + +RFC 6130 MANET-NHDP April 2011 + + +F.9. Example 9: Dual Interface on All Routers + + In Figure 20, all routers have a single IP address on each interface, + and all routers have two interfaces. Furthermore, there are now two + physical links between A and B, over distinct interface pairs, and + two physical links between B and C, also over distinct interface + pairs. + + __________ __________ + | | | +-----+ +----{3} + {1} {2} {3} {1}-------| {2} |---+ + | | | | {5} | +----{4} + +--'--+ +--'--+ +-----+ +-----+ + | A | | B | | C | + +-----+ +-----+ +-----+ +-----+ + | | | | {2} | +----{3} + {6} {5} {4} {6}-------| {5} |---+ + |__________|__________| +-----+ +----{4} + + Figure 20: Single Addresses, with All Routers Having Two Interfaces + (Left), and Corresponding NHDP Representation (Right) + + The Local Information Set is identical to that in Example 8. The + Interface Information Base for each interface in A is also identical + to that in Example 8, except that an additional 2-Hop Tuple is + present in each 2-Hop Set, each representing the link between router + B and the interface of router C with address {4}. + + As in Example 7, router A does not have information describing which + of router B's interfaces is connected to which interface of C, or + even that the interfaces with addresses {3} and {4} are interfaces of + the same router. However, router A knows that the addresses {3} and + {4} (and router C) are reachable by using {2} or {5} (depending on + via which of its local interfaces) as next hop. + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 85] + +RFC 6130 MANET-NHDP April 2011 + + +F.10. Example 10: Dual Addressed Dual Interfaces on All Routers + + In Figure 21, all routers have two IP addresses on each interface, + and all routers have two interfaces. Furthermore, there are now two + physical links between A and B, over distinct interface pairs, and + two physical links between B and C, also over distinct interface + pairs. + + +--{9} + __________ __________ +------| + | | | +-----+ | +--{10} + {1,2} {5,6} {9,10} {1,2}--|{5,6}|---+ + | | | |{7,8}| | +--{11} + +--'--+ +--'--+ +-----+ +-----+ +------| + | A | | B | | C | +--{12} + +-----+ +-----+ +-----+ + | | | +--{9} + | | | +-----+ +------| + | | | |{5,6}| | +--{10} + {3,4} {7,8} {11,12} {3,4}--|{7,8}|---+ + |__________|__________| +-----+ | +--{11} + +------| + +--{12} + + Figure 21: Dual Addresses, with All Routers Having Two Interfaces + (Left) and Corresponding NHDP Representation (Right) + + This example is the combination of all the preceding examples in this + appendix. The Local Information Set in A contains Local Information + Tuples for each of its interfaces, and each Interface Information + Base contains in its Link Set a representation of links {1,2}-{5,6} + or {3,4}-{7,8}, respectively. The Neighbor Set (in the Neighbor + Information Base) records the existence of router B and all of its + addresses on all its interfaces, i.e., {5,6,7,8}. + + As in Example 9, each interface address of router C is represented in + the 2-Hop Set of each Interface Information Base as a link from + router B to each of these addresses. Router A does not have + information describing which of router B's interfaces is connected to + which interface of C, nor that the addresses {9}, {10}, {11}, and + {12} are addresses of the same router (or that some of these, such as + {9} and {10}, are addresses on the same interface of the router). + + + + + + + + + +Clausen, et al. Standards Track [Page 86] + +RFC 6130 MANET-NHDP April 2011 + + +F.11. Example 11: Single Addressed Dual Interface Locally + + In Figure 22, all routers have a single interface, except for router + A which has two. Each of A's two interfaces has a link with the + single interface of router B. All interfaces have a single address. + + __________ __________ + | _____| | + {1} | {2} {3} {1}--------{2}---------{3} + | | | | + +--'--+ | +--'--+ +-----+ + | A | | | B | | C | + +-----+ | +-----+ +-----+ + | | + {6} | {6}--------{2}---------{3} + |____| + + Figure 22: Single Addresses, with A Having Two Interfaces, Both + Linked to the Single Interface of B (Left), and Corresponding NHDP + Representation (Right) + + This is similar to Example 8, except that the single address {2} also + replaces the address {5}. In particular, both Link Tuples (one in + each Link Set, each in its corresponding Interface Information Base) + have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the + Neighbor Information Base) contains a single Neighbor Tuple with + N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each + 2-Hop Set, each in its corresponding Interface Information Base) have + N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}. + + + + + + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 87] + +RFC 6130 MANET-NHDP April 2011 + + +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 ATC + + Phone: +44 1245 242194 + EMail: chris.dearlove@baesystems.com + URI: http://www.baesystems.com/ + + + Justin W. Dean + Naval Research Laboratory + + Phone: +1 202 767 3397 + EMail: jdean@itd.nrl.navy.mil + URI: http://pf.itd.nrl.navy.mil/ + + + + + + + + + + + + + + + + + + + + + + + + + + + +Clausen, et al. Standards Track [Page 88] + |