draft-ietf-manet-nhdp-07.txt   draft-ietf-manet-nhdp-08.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: January 11, 2009 BAE Systems Advanced Technology Expires: September 10, 2009 BAE Systems ATC
Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
July 10, 2008 March 9, 2009
MANET Neighborhood Discovery Protocol (NHDP) MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-07 draft-ietf-manet-nhdp-08
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes a 1-hop and symmetric 2-hop neighborhood This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs). discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 9 3.1. Usage in Other Protocols . . . . . . . . . . . . . . . . . 10
4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
4.2. Information Base Overview . . . . . . . . . . . . . . . . 10 4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11
4.2.1. Local Information Base . . . . . . . . . . . . . . . . 10 4.2. Information Base Overview . . . . . . . . . . . . . . . . 12
4.2.2. Interface Information Bases . . . . . . . . . . . . . 11 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 12
4.2.3. Node Information Base . . . . . . . . . . . . . . . . 11 4.2.2. Interface Information Bases . . . . . . . . . . . . . 13
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 12 4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 14
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 12 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 12 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 15
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 13 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 15
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 16
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 15 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 15 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 17
5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 15 5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 18
5.1.2. Information Validity Times . . . . . . . . . . . . . . 16 5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 18
5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. Information Validity Times . . . . . . . . . . . . . . 19
5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 20
5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 18 5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Information Validity Time . . . . . . . . . . . . . . 18 5.2. Router Parameters . . . . . . . . . . . . . . . . . . . . 21
5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 18 5.2.1. Information Validity Time . . . . . . . . . . . . . . 21
5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 21
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 21 5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 21 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 23
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 21 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 23
7. Interface Information Base . . . . . . . . . . . . . . . . . . 22 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 23
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Interface Information Base . . . . . . . . . . . . . . . . . . 24
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Node Information Base . . . . . . . . . . . . . . . . . . . . 24 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 24 8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 26
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 24 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 26
9. Local Information Base Changes . . . . . . . . . . . . . . . . 25 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 26
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 25 9. Local Information Base Changes . . . . . . . . . . . . . . . . 27
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 25 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 27
9.3. Adding an Address to an Interface . . . . . . . . . . . . 26 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 27
9.4. Removing an Address from an Interface . . . . . . . . . . 27 9.3. Adding an Address to an Interface . . . . . . . . . . . . 28
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 28 9.4. Removing an Address from an Interface . . . . . . . . . . 29
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 28 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 29
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 29 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 30
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 31 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 31
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 31 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 32
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 33 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 32
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 33 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 34
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 34 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 34
12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 35 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 35
12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 36 12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 35
12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 36 12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36
12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 38 12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 37
13. Other Information Base Changes . . . . . . . . . . . . . . . . 40 12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 38
13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 40 12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 39
13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 41 12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 40
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 42 13. Other Information Base Changes . . . . . . . . . . . . . . . . 41
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 43 13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 42
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 43 13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 43
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 43 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 43
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 44 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 44
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 45 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 44
15. Proposed Values for Parameters and Constants . . . . . . . . . 46 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 45
15.1. Message Interval Interface Parameters . . . . . . . . . . 46 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 46
15.2. Information Validity Time Interface Parameters . . . . . . 46 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 46
15.3. Information Validity Time Node Parameters . . . . . . . . 46 15. Proposed Values for Parameters and Constants . . . . . . . . . 47
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 46 15.1. Message Interval Interface Parameters . . . . . . . . . . 47
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 46 15.2. Information Validity Time Interface Parameters . . . . . . 47
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 47 15.3. Information Validity Time Router Parameters . . . . . . . 47
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 47
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 48
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 48
16. Security Considerations . . . . . . . . . . . . . . . . . . . 48 16. Security Considerations . . . . . . . . . . . . . . . . . . . 48
16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48 16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48
16.2. Authentication, Integrity and Confidentiality
Suggestions . . . . . . . . . . . . . . . . . . . . . . . 50
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
17.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 50 17.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 50
17.2. Address Block TLV Types . . . . . . . . . . . . . . . . . 50 17.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 50
17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 51 17.3. Message-Type-specific TLV Type Registries . . . . . . . . 51
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 17.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 51
18.1. Normative References . . . . . . . . . . . . . . . . . . . 53 17.5. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 52
18.2. Informative References . . . . . . . . . . . . . . . . . . 53 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
20.1. Normative References . . . . . . . . . . . . . . . . . . . 54
20.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 54 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 54
Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 55 Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 55
Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 58 Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 58
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 61 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 60
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 62
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
This document describes a neighborhood discovery protocol (NHDP) for This document describes a neighborhood discovery protocol (NHDP) for
a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an
exchange of HELLO messages in order that each node can determine the exchange of HELLO messages in order that each router can determine
presence and status of its 1-hop and symmetric 2-hop neighbors. the presence of, and connectivity to, its 1-hop and symmetric 2-hop
Messages are defined as instances of the specification [packetbb]. neighbors. Messages are defined as instances of the specification
[RFC5444].
This neighborhood information is recorded in the form of Information 1-hop and symmetric 2-hop neighborhood information is recorded in the
Bases. These may be used by other protocols, such as MANET routing form of Information Bases. These may be used by other protocols,
protocols, for determining local connectivity and node configuration. such as MANET routing protocols, which require information regarding
This protocol is designed to maintain this information in the the local network connectivity. This protocol is designed to
presence of a dynamic network topology. maintain the information in these Information Bases even in the
presence of a dynamic network topology and wireless ad hoc network
interface characteristics.
This protocol makes no assumptions about the underlying link layer, This protocol makes no assumptions about the underlying link layer,
other than support of link local broadcast or multicast. Link layer other than support of link local broadcast or multicast. Link layer
information may be used if available and applicable. information may be used if available and applicable.
This protocol is based on the neighborhood discovery process This protocol is based on the neighborhood discovery process
contained in the Optimized Link State Routing Protocol (OLSR) contained in the Optimized Link State Routing Protocol (OLSR)
[RFC3626]. [RFC3626].
1.1. Motivation 1.1. Motivation
skipping to change at page 4, line 42 skipping to change at page 5, line 45
interfaces with moderate and shared bandwidth, hidden and exposed interfaces with moderate and shared bandwidth, hidden and exposed
terminals and interference from other network interfaces and the terminals and interference from other network interfaces and the
environment) and in more challenging topological conditions (e.g. environment) and in more challenging topological conditions (e.g.
rapid and unpredictable mobility, dynamic and non-predetermined rapid and unpredictable mobility, dynamic and non-predetermined
network membership). An approach, often taken by MANET routing network membership). An approach, often taken by MANET routing
protocols, is to collect local topological information up to 2 hops, protocols, is to collect local topological information up to 2 hops,
in order to, for example, optimize their flooding performance within in order to, for example, optimize their flooding performance within
the MANET. the MANET.
Due to the properties of wireless transmissions, communication Due to the properties of wireless transmissions, communication
between two network interfaces on neighboring nodes may not be bi- between two network interfaces on neighboring routers may not be
directional; even if node A is able to receive a packets from node B, bidirectional; even if router A is able to receive a packets from
the converse is not guaranteed to be true. Furthermore, because of router B, the converse is not guaranteed to be true. Furthermore,
the localized nature of wireless broadcasts communication, differing because of the localized nature of wireless broadcast communication,
neighbor sets often exist for differing neighboring nodes within the neighboring routers within the same communications channel may have
same communications channel. If node A is able to exchange packets different sets of neighbors. If router A is able to exchange packets
with node B and node B is able to exchange packets with node C on the with router B and router B is able to exchange packets with router C
same interface, this does not guarantee that node A and node C can on the same interface, this does not guarantee that router A and
exchange packets directly. router C can exchange packets directly.
Nodes in a MANET may have multiple heterogeneous interfaces Routers in a MANET may have multiple heterogeneous interfaces
participating in the same MANET routing protocol, each of which with participating in the same MANET routing protocol, each of which with
the characteristics as described above. Between the same pair of the characteristics described above. Between the same pair of
nodes more than one distinct communications channel (links) may routers, more than one distinct communications channel (link) may
therefore exist, with different properties. therefore exist, each with different properties.
For MANET routing protocols to correctly identify candidate links for For MANET routing protocols to correctly identify candidate links for
inclusion in a routing path, the existence and bi-directionality of inclusion in a routing path, the existence and, in many cases,
such distinct links between a node and its neighbors must be bidirectionality of such distinct links between a router and its
established and monitored. neighbors must be established and monitored.
The set of neighbor nodes of a given MANET node may be continuously The set of neighbor routers of a given MANET router may be
changing, often due to node mobility or due to a changing physical continuously changing, often due to router mobility or a changing
environment in which the MANET is located. There are typically no physical environment in which the MANET is located. There are
signals from lower layers which would enable an IP routing protocol typically no signals from lower layers which would enable an IP
to detect and, as appropriate, react to such changes. Yet as such routing protocol to detect and, as appropriate, react to such
changes are can often take place on the order of seconds, requiring changes. Such changes are can often take place on a short timescale,
MANET IP routing protocols to also act rapidly to ensure sufficient such as of the order of seconds, requiring MANET routing protocols to
convergence properties. act rapidly to ensure suitable convergence properties.
MANET routing protocols often employ relay set reductions in order to MANET routing protocols, for example [RFC3626] and [RFC5449], often
conserve network capacity when maintaining network-wide topological employ relay set reductions in order to conserve network capacity
information, with calculation of these reduced relay sets employing when maintaining network-wide topological information, with
up to 2-hop information. Such is the case e.g. for [RFC3626]. calculation of these reduced relay sets employing up to two hop
information.
The neighborhood discovery protocol specified in this document The neighborhood discovery protocol specified in this document
provides continued tracking of neighborhood changes, continued bi- provides continued tracking of neighborhood changes, continued
directionality tracking of links between neighbors and local bidirectionality tracking of links between neighbors, and local
topological information up to two hops. Combined, this allows a topological information up to two hops. Combined, this allows a
MANET routing protocol access to information describing link MANET routing protocol access to information describing link
establishment/disappearance, and provides the necessary topological establishment/disappearance, and provides the necessary topological
information for reduced relay set selection and other purposes. information for reduced relay set selection and other purposes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The terms "packet", "message", "address", "address block", "TLV", and All terms introduced in [RFC5444], including "packet", "message",
"TLV block" in this document are to be interpreted as described in "Address Block", "TLV Block" and "TLV", are to be interpreted as
[packetbb]. described there.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Node - A MANET router which implements this neighborhood discovery Router - A MANET router which implements this neighborhood discovery
protocol. protocol.
Interface - A network device, configured and assigned one or more IP Interface - A network device, configured and assigned one or more IP
addresses. addresses.
Address - An address, as recorded in the Information Bases specified Address - An IPv4 or IPv6 address, as recorded in the Information
by this protocol, and included in HELLO messages generated by this Bases specified by this protocol, and included in messages
protocol, may be either an address or an address prefix. The generated by this protocol, may be either an address or an address
exception to this is addresses described as originator addresses; prefix. The exception to this is addresses described as
these must be simple addresses without a prefix length. Non- originator addresses; these must be simple addresses without a
originator addresses can be represented as a single address object prefix length. Non-originator addresses can be represented as a
in a HELLO message, as defined by [packetbb]. An address so single address object in a message, as defined by [RFC5444]. An
represented is considered to have a prefix length equal to its address so represented is considered to have a prefix length equal
length (in bits) when considered as an address object, and a to its length (in bits) when considered as an address object, and
similar convention is used in the Information Bases specified by a similar convention is used in the Information Bases specified by
this protocol. Two addresses (address objects) are considered this protocol. Two addresses (address objects) are considered
equal only if their prefix lengths are also equal. equal only if their prefix lengths are also equal.
MANET interface - An interface participating in a MANET and using MANET interface - An interface participating in a MANET and using
this neighborhood discovery protocol. A node may have several this neighborhood discovery protocol. A router may have several
MANET interfaces. MANET interfaces.
Heard - A MANET interface of node X is considered heard on a MANET Heard - A MANET interface of router X is considered heard on a MANET
interface of a node Y if the latter can receive traffic from the interface of a router Y if the latter can receive traffic from the
former. former.
Link - A pair of MANET interfaces from two different nodes, where at Link - A pair of MANET interfaces from two different routers, where
least one interface is heard by the other. at least one interface is heard by the other.
Symmetric link - A link where both MANET interfaces are heard by the Symmetric link - A link where both MANET interfaces are heard by the
other. other.
1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a MANET 1-hop neighbor - A router X is a 1-hop neighbor of a router Y if a
interface of node X is heard by a MANET interface of node Y. MANET interface of router X is heard by a MANET interface of
router Y.
Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of Symmetric 1-hop neighbor - A router X is a symmetric 1-hop neighbor
a node Y if a symmetric link exists between a MANET interface on of a router Y if a symmetric link exists between a MANET interface
node X and a MANET interface on node Y. on router X and a MANET interface on router Y.
Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of Symmetric 2-hop neighbor - A router X is a symmetric 2-hop neighbor
a node Y if node X is a symmetric 1-hop neighbor of a symmetric of a router Y if router X is a symmetric 1-hop neighbor of a
1-hop neighbor of node Y, but is not node Y itself. symmetric 1-hop neighbor of router Y, but is not router Y itself.
1-hop neighborhood - The 1-hop neighborhood of a node X is the set 1-hop neighborhood - The 1-hop neighborhood of a router X is the set
of the 1-hop neighbors of node X. of the 1-hop neighbors of router X.
Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a
node X is the set of the symmetric 1-hop neighbors of node X. router X is the set of the symmetric 1-hop neighbors of router X.
Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a
node X is the set of the symmetric 2-hop neighbors of node X. router X is the set of the symmetric 2-hop neighbors of router X.
(This may include nodes in the 1-hop neighborhood, or even in the (This may include routers in the 1-hop neighborhood, or even in
symmetric 1-hop neighborhood, of node X.) the symmetric 1-hop neighborhood, of router X.)
Constant - A constant is a numerical value which MUST be the same Constant - A constant is a numerical value which MUST be the same
for all MANET interfaces of all nodes in the MANET, at all times. for all MANET interfaces of all routers in the MANET, at all
times.
Interface parameter - An interface parameter is a boolean or Interface parameter - An interface parameter is a boolean or
numerical value, specified separately for each MANET interface of numerical value, specified separately for each MANET interface of
each node. A node MAY change interface parameter values at any each router. A router MAY change interface parameter values at
any time, subject to some constraints.
Router parameter - A router parameter is 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. time, subject to some constraints.
Node parameter - A node parameter is a boolean or numerical value, Furthermore, this document uses the following notational conventions:
specified for each node. A node MAY change node parameter values
at any time, subject to some constraints. X contains y, or y is contained in X, is an unordered list
membership operator, returning true if the unordered list X
includes the element y, and returning false otherwise.
X contains Y, or Y is contained in X, is an unordered list inclusion
operator, returning true if the unordered list X contains all
elements y which are contained in Y, and returning false
otherwise.
a := b is an assignment operator, whereby the left side (a) is
assigned the value of the right side (b). a and b may be values,
addresses, or unordered lists (they must be of the same type).
c = d is 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, 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 they contain the same set of elements,
regardless of the order in which they are recorded in either list
(in which case c is contains d, and d contains c).
e != f is a comparison operator, returning true where (e = f) would
have returned false, and returning false where (e = f) would have
returned true.
3. Applicability Statement 3. Applicability Statement
This protocol: This protocol:
o Provides each router with local topology information up to two
hops away.
o Makes this local topology information a available to MANET routing
protocols in Information Bases, which are defined in this
specification.
o May interact with other protocols, such as MANET routing
protocols, see Section 3.1.
o Is applicable to networks, especially wireless networks, in which o Is applicable to networks, especially wireless networks, in which
unknown neighbors (i.e. other nodes with which direct unknown neighbors (i.e. other routers with which direct link layer
communication can be established) can be reached by local communication can be established) can be reached by local
broadcast or multicast packets. broadcast or multicast packets.
o Is designed to work in networks with a dynamic topology, and in 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 which messages may be lost, such as due to collisions in wireless
networks. networks.
o Supports nodes that each have one or more participating MANET o Supports routers that each have one or more participating MANET
interfaces. The set of a node's interfaces may change over time. interfaces. The set of a router's interfaces may change over
Each interface may have one or more interface addresses, and these time. Each interface may have one or more interface addresses,
may also be dynamically changing. and these may also be dynamically changing.
o Can use the link local multicast address "LL-MANET-Routers", and o Can use the link local multicast address "LL-MANET-Routers", and
either the "manet" UDP port or the "manet" IP protocol number, all either the "manet" UDP port or the "manet" IP protocol number, all
as specified in [manet-iana]. as specified in [manet-iana].
o Uses the packet and message formats specified in [packetbb]. Such o Uses the packet and message formats specified in [RFC5444]. Such
packets may contain messages specified by this protocol as well as packets may contain messages specified by this protocol as well as
other protocols. other protocols.
o Specifies signaling using HELLO messages. The necessary contents o Specifies signaling using HELLO messages. The necessary contents
of these messages are defined in this specification, and may be of these messages are defined in this specification, and may be
extended using the TLV mechanisms described in [packetbb]. extended using the TLV mechanisms described in [RFC5444].
o Can use relevant link layer information if it is available. o Can use relevant link layer information if it is available.
o Provides each node with local topology information up to two hops
away. This information is made available to other protocols, of
which this protocol may be a part, in Information Bases defined in
this specification.
o Is designed to work in a completely distributed manner, and does o Is designed to work in a completely distributed manner, and does
not depend on any central entity. not depend on any central entity.
3.1. Usage in Other Protocols
Other protocols which 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 16, to add a
TLV containing a cryptographic signature to the message, or be to
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
discard it prior to processing by this protocol. This may, for
example, allow a security protocol, as suggested in Section 16, 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 which has added information, such as relay
selection information by way of inclusion of appropriate TLVs,
access to such information after appropriate updates has 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.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The objective of this protocol is, for each node: The objective of this protocol is, for each router:
o To identify other nodes with which bidirectional links can be o To identify other routers which can be heard, and those with which
established (symmetric 1-hop neighbors). bidirectional links can be established (symmetric 1-hop
neighbors).
o To agree on the status of such links with the corresponding o To agree on the status of such links with the corresponding
symmetric 1-hop neighbor. symmetric 1-hop neighbor.
o To find the node's symmetric 2-hop neighbors. o To find the interface addresses of the router's symmetric 2-hop
neighbors.
o To record this information in Information Bases that can be used o To record this information in Information Bases that can be used
by other protocols, of which this neighborhood discovery protocol by other protocols, of which this neighborhood discovery protocol
may be a part. may be a part.
These objectives are achieved using local (one hop) signaling that: These objectives are achieved using local (one hop) signaling that:
o Advertises the presence of a node and its interfaces. o Advertises the presence of a router and its interfaces.
o Discovers links with adjacent nodes. o Discovers links from neighboring routers.
o Performs bidirectionality checks on the discovered links. o Performs bidirectionality checks on the discovered links.
o Advertises discovered links, and whether each is symmetric, to its o Advertises discovered links, and whether each is symmetric, to its
1-hop neighbors, and hence discovers symmetric 2-hop neighbors. 1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
This specification defines, in turn: This specification defines, in turn:
o Parameters and constants used by the protocol. Parameters used by o Parameters and constants used by the protocol. Parameters used by
this protocol may be, where appropriate, specific to a MANET this protocol may be, where appropriate, specific to a specific
interface. This protocol allows all parameters to be changed MANET interface, or to a MANET router. This protocol allows all
dynamically. parameters to be changed dynamically, and to be set independently
for each MANET router or MANET interface, as appropriate.
o The Information Bases describing local interfaces, discovered o The Information Bases describing local interfaces, discovered
links and their status, current and former 1-hop neighbors, and links and their status, current and former 1-hop neighbors, and
symmetric 2-hop neighbors. symmetric 2-hop neighbors.
o The format of the HELLO message that is used for local signaling. 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 o The generation of HELLO messages from some of the information in
the Information Bases. the Information Bases.
o The updating of the Information Bases according to received HELLO o The updating of the Information Bases according to received HELLO
messages and other events. messages and other events.
4.1. Nodes and Interfaces 4.1. Routers and Interfaces
In order for a node to participate in a MANET, it MUST have at least In order for a router to participate in a MANET, it MUST have at
one, and possibly more, MANET interfaces. Each MANET interface: least one, and possibly more, MANET interfaces. Each MANET
interface:
o Is characterized by a set of interface parameters, defining the o Is characterized by a set of interface parameters, defining the
behavior of this MANET interface. Each MANET interface MAY be behavior of this MANET interface. Each MANET interface MAY be
individually parameterized. individually parameterized.
o Has an Interface Information Base, recording information regarding o Has an Interface Information Base, recording information regarding
links to this MANET interface and symmetric 2-hop neighbors which links to this MANET interface and symmetric 2-hop neighbors which
can be reached through such links. can be reached through such links.
o Generates and processes HELLO messages, according to the interface o Generates and processes HELLO messages, according to the interface
parameters for that MANET interface. parameters for that MANET interface.
In addition to a set of MANET interfaces as described above, each In addition to a set of MANET interfaces as described above, each
node has: router has:
o A Local Information Base, containing the addresses of the o A Local Information Base, containing the addresses of the
interfaces (MANET and non-MANET) of this node. The contents of interfaces (MANET and non-MANET) of this router. The contents of
this Information Base are not changed by signaling. this Information Base are not changed by signaling.
o A Node Information Base, recording information regarding current o A Neighbor Information Base, recording information regarding
and recently lost 1-hop neighbors of this node. current and recently lost 1-hop neighbors of this router.
A node may have both MANET interfaces and non-MANET interfaces. A router may have both MANET interfaces and non-MANET interfaces.
Interfaces of both of these types are recorded in a node's Local 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 Information Base, which is used, but not updated, by the signaling of
this protocol. this protocol.
4.2. Information Base Overview 4.2. Information Base Overview
Each node maintains the Information Bases described in the following Each router maintains the Information Bases described in the
sections. These are used for describing the protocol in this following sections. These are used for describing the protocol in
document. An implementation of this protocol MAY maintain this this document. An implementation of this protocol MAY maintain this
information in the indicated form, or in any other organization which information in the indicated form, or in any other organization which
offers access to this information. In particular note that it is not offers access to this information. In particular note that it is not
necessary to remove Tuples from Sets at the exact time indicated, necessary to remove Tuples from Sets at the exact time indicated,
only to behave as if the Tuples were removed at that time. only to behave as if the Tuples were removed at that time.
4.2.1. Local Information Base 4.2.1. Local Information Base
Each node maintains a Local Information Base, which contains: Each router maintains a Local Information Base, which contains:
o The Local Interface Set, which consists of Local Interface Tuples, o The Local Interface Set, which consists of Local Interface Tuples,
each of which records the addresses of an interface (MANET or non- each of which records the addresses of an interface (MANET or non-
MANET) of the node. MANET) of the router.
o The Removed Interface Address Set, which consists of Removed o The Removed Interface Address Set, which consists of Removed
Interface Address Tuples, each of which records a recently used Interface Address Tuples, each of which records a recently used
address of an interface (MANET or non-MANET) of the node. 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 addresses are to be
included and identified through inclusion of an appropriate TLV as
being a "local interface" of the router at which the HELLO message is
generated. The Removed Interface Address Set is used to allow a
router to detect if a neighbor is advertising a formerly used
address, and to exclude this from inclusion in the Interface
Information Bases described below.
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 4.2.2. Interface Information Bases
Each node maintains, for each of its MANET interfaces, an Interface Each router maintains, for each of its MANET interfaces, an Interface
Information Base, which contains: Information Base, which contains:
o A Link Set, which records information about current and recently o A Link Set, which records information about current and recently
lost links between this interface and MANET interfaces of 1-hop lost links between this interface and MANET interfaces of 1-hop
neighbors. The Link Set consists of Link Tuples, each of which neighbors. The Link Set consists of Link Tuples, each of which
contains information about a single link. Recently lost links are contains information about a single link. Recently lost links are
recorded so that they can be advertised in HELLO messages, recorded so that they can be advertised in HELLO messages,
accelerating their removal from relevant 1-hop neighbors' Link accelerating their removal from relevant 1-hop neighbors' Link
Sets. Link quality information, if used and available, is Sets. Link quality information (see Section 14), if used and
recorded in Link Tuples and may indicate that links are treated as available, is recorded in Link Tuples and may indicate that links
lost. are treated as lost.
o A 2-Hop Set, which records the existence of bidirectional links o A 2-Hop Set, which records the existence of bidirectional links
between symmetric 1-hop neighbors of this MANET interface and between symmetric 1-hop neighbors of this MANET interface and
other nodes (symmetric 2-hop neighbors). The 2-Hop Set consists other routers (symmetric 2-hop neighbors). The 2-Hop Set consists
of 2-Hop Tuples, each of which records an interface address of a of 2-Hop Tuples, each of which records an interface address of a
symmetric 2-hop neighbor, and all interface addresses of the symmetric 2-hop neighbor, and all interface addresses of the
corresponding symmetric 1-hop neighbor. The 2-Hop Set is updated corresponding symmetric 1-hop neighbor. The 2-Hop Set is updated
by the signaling of this protocol, but is not itself reported in by the signaling of this protocol, but is not itself reported in
that signaling. that signaling.
4.2.3. Node Information Base 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 detect bidirectionality (if router A
advertises router B as heard in a HELLO message and router B receives
that HELLO message, then router B knows that bidirectional
communication is possible between routers A and B), and to populate
the 2-Hop Set (if router C receives a HELLO message from router B
advertising a bidirectional link to address A, then router C knows
that address A is reachable in two hops via router B).
Each node maintains a Node Information Base, which contains: The Link Set for a MANET interface is itself updated upon receipt of
a HELLO message, including to record link bidirectionality 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:
o The Neighbor Set, which records 1-hop neighbors, each of which o The Neighbor Set, which records 1-hop neighbors, each of which
must be currently heard, although this may be over a link with must be currently heard, although this may be over a link with
insufficient link quality. The Neighbor Set consists of Neighbor insufficient link quality. The Neighbor Set consists of Neighbor
Tuples, each of which records all interface addresses (whether Tuples, each of which records all interface addresses of a single
directly linked or not) of a single 1-hop neighbor. Neighbor 1-hop neighbor. Neighbor Tuples are maintained as long as there
Tuples are maintained as long as there are corresponding current are corresponding current Link Tuples.
Link Tuples.
o The Lost Neighbor Set, which records recently lost symmetric 1-hop o The Lost Neighbor Set, which records recently lost symmetric 1-hop
neighbors. The Lost Neighbor Set consists of Lost Neighbor neighbors. The Lost Neighbor Set consists of Lost Neighbor
Tuples, each of which records an interface address of such a Tuples, each of which records an interface address of such a
neighbor. These are recorded so that they can be advertised in neighbor. These are recorded so that they can be advertised in
HELLO messages, accelerating their removal from other nodes' 2-Hop HELLO messages, accelerating their removal from other routers'
Sets. 2-Hop Sets.
The Neighbor Set is used for recording which interface addresses of
neighbor routers are associated to the same router, and for including
this when generating HELLO messages such that 2-Hop sets in other
neighboring routers may record this information. The Neighbor Set
can itself be updated on receipt of a HELLO message.
The Lost Neighbor Set is used for generating HELLO messages.
Specifically, the Lost Neighbor Set is used for determining which
addresses are to be included in a HELLO and identified through
inclusion of an appropriate TLV as being "lost", i.e. formerly, but
no longer, recorded as a symmetric neighbor. The Lost Neighbor Set
can itself be updated on receipt of a HELLO message.
4.3. Signaling Overview 4.3. Signaling Overview
This protocol contains a signaling mechanism for maintaining the This protocol contains a signaling mechanism for maintaining the
Interface Information Bases and the Node Information Base. If Interface Information Bases and the Neighbor Information Base. If
information from the link layer, or any other source, is available information from the link layer, or any other source, is available
and appropriate, it may also be used to update these Information and appropriate, it may also be used to update these Information
Bases. Such updates are subject to the constraints specified in Bases. Such updates are subject to the constraints specified in
Appendix C. Appendix B.
Signaling consists of a single type of message, known as a HELLO Signaling consists of a single type of message, known as a HELLO
message. Each node generates HELLO messages on each of its MANET message. Each router generates HELLO messages on each of its MANET
interfaces. Each HELLO message identifies that MANET interface, and interfaces. HELLO messages are generated independently on each MANET
reports the other interfaces (MANET and non-MANET) of the node. Each interface of a MANET router; the content of a given HELLO message
HELLO message includes information from the Link Set of the Interface depends on the interface for which it has been generated.
Information Base of the MANET interface, and from the Node
Information Base. Each HELLO message identifies the MANET interface for which it is
generated and over which it is transmitted. This allows its
recipients to identify from which MANET interface this HELLO message
has been received. Each HELLO message also reports the other
interfaces (MANET and non-MANET) of the router, which allows
recipients to associate a set of interface addresses with a single
neighbor. Finally, each HELLO message also includes information from
the Link Set of the Interface Information Base of the MANET
interface, and from the Neighbor Information Base. This serves to
allow detection of bidirectional communication between two MANET
routers and over a pair of MANET interfaces, as well as to determine
symmetric 2-hop neighborhood information.
4.3.1. HELLO Message Generation 4.3.1. HELLO Message Generation
HELLO messages are generated by a node for each of its MANET HELLO messages are generated by a router for each of its MANET
interfaces, and MAY be sent: interfaces, and MAY be sent:
o Proactively, at a regular interval, known as HELLO_INTERVAL. 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 fixed, or may be dynamic. For example
HELLO_INTERVAL may be backed off due to congestion or network HELLO_INTERVAL may be backed off due to congestion or network
stability. stability.
o As a response to a change in the node itself, or its 1-hop 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 neighborhood, for example on first becoming active or in response
to a new, broken, or changed status link. to a new, broken, or changed status link.
o In a combination of these proactive and responsive mechanisms. o In a combination of these proactive and responsive mechanisms.
Jittering of HELLO message generation and transmission, as described Jittering of HELLO message generation and transmission, as described
in Section 11.2, SHOULD be used if appropriate. in Section 11.2, SHOULD be used if appropriate.
HELLO messages are generated independently on each MANET interface of HELLO messages MAY be scheduled independently for each MANET
a node. HELLO messages MAY be scheduled independently for each MANET
interface, or, interface parameters permitting, using the same interface, or, interface parameters permitting, using the same
schedule for all MANET interfaces of a node. schedule for all MANET interfaces of a router.
4.3.2. HELLO Message Content 4.3.2. HELLO Message Content
Each HELLO message sent over a MANET interface need not contain all Each HELLO message sent on a MANET interface need not contain all of
of the information appropriate to that MANET interface, however: the information appropriate to that MANET interface, however:
o A HELLO message MUST contain all of the addresses in the Local o A HELLO message MUST contain all of the addresses in the Local
Interface Set of the node to which the MANET interface belongs. Interface Set of the router to which the MANET interface belongs.
o Within every time interval of length REFRESH_INTERVAL, the HELLO o For each MANET interface, within every time interval of length
messages sent on each MANET interface of a node MUST collectively equal to the corresponding parameter REFRESH_INTERVAL, the HELLO
include: messages sent MUST collectively include:
* All of the relevant information in the Link Set of the * All of the relevant information in the Link Set of the
Interface Information Base of that MANET interface. Interface Information Base of that MANET interface.
* All of the relevant information in the Node Information Base of * All of the relevant information in the Neighbor Information
that node. Base of that router.
This applies to otherwise purely responsive nodes as well as to This applies to otherwise purely responsive routers as well as to
proactive nodes. In either case it means that all information proactive routers. In either case it means that all information
appropriate to that MANET interface will have always been appropriate to that MANET interface will have always been
transmitted, in one or more HELLO messages, since the time transmitted, in one or more HELLO messages, since the time
REFRESH_INTERVAL ago. REFRESH_INTERVAL ago. Note that this rule applies at all times,
not just to times at which HELLO messages are sent. In
considering whether to include information in a HELLO message, the
sender MUST consider all times up to when it may send its next
HELLO message on that MANET interface.
o A HELLO message MUST include a VALIDITY_TIME message TLV that o A HELLO message MUST include a VALIDITY_TIME Message TLV, as
indicates the length of time for which the message content is to specified in [timetlv], that indicates the length of time for
be considered valid, and included in the receiving node's which the message content is to be considered valid, and is
Interface Information Base. therefore to be included in the receiving router's Interface
Information Base.
o A periodically generated HELLO message SHOULD include an o A periodically generated HELLO message SHOULD include an
INTERVAL_TIME message TLV that indicates the current value of INTERVAL_TIME Message TLV, as specified in [timetlv], that
HELLO_INTERVAL for that MANET interface, i.e. the period within indicates the current value of HELLO_INTERVAL for that MANET
which a further HELLO message is guaranteed to be sent on that interface, i.e. the period within which a further HELLO message is
MANET interface. guaranteed to be sent on that MANET interface.
o Additional information may be added by a protocol using this o Additional information may be added by a protocol using this
protocol using the TLV mechanisms described in [packetbb]. For protocol using the TLV mechanisms described in [RFC5444]. For
example, if multipoint relays (MPRs) are to be calculated example, if multipoint relays (MPRs) are to be calculated
similarly to as in OLSR [RFC3626] and signaled to neighbors, then similarly to as in [RFC3626] and signaled to neighbors, then this
this information may be added to HELLO messages using an address information may be added to HELLO messages using an Address Block
block TLV. TLV.
4.3.3. HELLO Message Processing 4.3.3. HELLO Message Processing
All HELLO messages received by a node are used to update: All HELLO messages received by a router are used to update:
o The Interface Information Base for the MANET interface on which o The Interface Information Base for the MANET interface on which
that HELLO message is received. that HELLO message is received.
o The Node Information Base. o The Neighbor Information Base.
Specifically: Specifically:
o The node ensures that there is a single Neighbor Tuple o The router ensures that there is a single Neighbor Tuple
corresponding to the originator of that HELLO message. corresponding to the originator of that HELLO message.
o If a Link Tuple corresponding to the link on which that HELLO o If a Link Tuple corresponding to the link on which that HELLO
message was received exists, then its duration is extended, message was received exists, then the duration for which that Link
otherwise such a Link Tuple is created. If the HELLO message Tuple is kept is extended, otherwise such a Link Tuple is created.
indicates that the receiving MANET interface has been heard, then If the HELLO message indicates that the receiving MANET interface
the link is considered symmetric, or its duration as symmetric is has been heard, then the link is considered symmetric, or the
duration for which that Link Tuple is kept as symmetric is
extended. If the HELLO message indicates that the receiving MANET extended. If the HELLO message indicates that the receiving MANET
interface is lost, then the link is no longer considered interface is lost, then the link is no longer considered
symmetric. In this case one or more Lost Neighbor Tuples may be symmetric. In this case one or more Lost Neighbor Tuples may be
created. created.
o If the link on which the HELLO message is received is symmetric, o If the link on which the HELLO message is received is symmetric,
then any symmetrically advertised neighbors in the HELLO message then any symmetrically advertised neighbor addresses in the HELLO
are added to the 2-Hop Set for the receiving interface, or if message are added to the 2-Hop Set for the receiving interface, or
already present, the durations of the corresponding 2-Hop Tuples if already present, the duration for which the corresponding 2-Hop
are extended. Tuples are kept are extended.
In all cases the processing takes account of unexpected and erroneous In all cases the processing takes into account unexpected and
information in the HELLO message, maintaining the constraints erroneous information in the HELLO message, maintaining the
specified in Appendix C. constraints specified in Appendix B.
4.4. Link Quality 4.4. Link Quality
Some links in a MANET may be marginal, e.g. due to adverse wireless 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 propagation. In order to avoid using such marginal links, a link
quality is associated with each link in the Link Set, and links with quality value is recorded with each link in the Link Set. A MANET
insufficient link quality are considered lost. Modifying the link router considers links for which an insufficient link quality is
quality of a link is OPTIONAL. If link quality is not to be modified recorded to be lost. Modifying the recorded link quality of a link
in the Link Set is OPTIONAL. If link quality is not to be modified
it MUST be set to indicate an always usable quality link. Link it MUST be set to indicate an always usable quality link. Link
quality information is only used locally, it is not used in quality information is only used locally, it is not used in
signaling, and nodes may interoperate whether they are using the signaling, and routers may interoperate whether they are using the
same, different, or no, link quality information. same, different, or no, link quality information. Link quality
information is thus not equivalent to a link metric.
5. Protocol Parameters and Constants 5. Protocol Parameters and Constants
The parameters and constants used in this specification are described The parameters and constants used in this specification are described
in this section. in this section.
5.1. Interface Parameters 5.1. Interface Parameters
The interface parameters used by this specification may be classified The interface parameters used by this specification may be classified
into the following four categories: into the following four categories:
skipping to change at page 15, line 25 skipping to change at page 18, line 20
o Message intervals o Message intervals
o Information validity times o Information validity times
o Link quality o Link quality
o Jitter o Jitter
These are detailed in the following sections. These are detailed in the following sections.
Different MANET interfaces (on the same or on different nodes) MAY Different MANET interfaces (on the same or on different routers) MAY
employ different interface parameter values, and may change their employ different interface parameter values, and MAY change their
interface parameter values dynamically, subject to the constraints interface parameter values dynamically, subject to the constraints
given in this section. A particular case is where all MANET given in this section. A particular case is where all MANET
interfaces on all MANET nodes within a given MANET employ the same interfaces on all MANET routers within a given MANET employ the same
set of interface parameter values. set of interface parameter values.
5.1.1. Message Intervals 5.1.1. Message Intervals
The following interface parameters regulate HELLO message The following interface parameters regulate HELLO message
transmissions over a given MANET interface. transmissions over a given MANET interface.
HELLO messages serve two principal functions: HELLO messages serve two principal functions:
o To advertise this node's own addresses to its 1-hop neighbors. o To advertise this router's interface addresses to its 1-hop
The frequency of these advertisements is regulated by the neighbors. The frequency of these advertisements is regulated by
interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL. the interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.
o To advertise this node's knowledge of each of its 1-hop neighbors. o To advertise this router's knowledge of each of its 1-hop
The frequency of the advertisement of each such neighbor is neighbors. The frequency of the advertisement of each such
regulated by the interface parameter REFRESH_INTERVAL. neighbor is regulated by the interface parameter REFRESH_INTERVAL.
Specifically, these parameters are as follows: Specifically, these parameters are as follows:
HELLO_INTERVAL - is the maximum time between the transmission of two HELLO_INTERVAL - is the maximum time between the transmission of two
successive HELLO messages on this MANET interface. If using successive HELLO messages on this MANET interface. If using
periodic transmission of HELLO messages, these SHOULD be at a periodic transmission of HELLO messages, these SHOULD be at a
separation of HELLO_INTERVAL, possibly modified by jitter as separation of HELLO_INTERVAL, possibly modified by jitter as
specified in [RFC5148]. specified in [RFC5148].
HELLO_MIN_INTERVAL - is the minimum interval between transmission of HELLO_MIN_INTERVAL - is the minimum interval between transmission of
two successive HELLO messages, on this MANET interface. (This two successive HELLO messages, on this MANET interface. (This
minimum interval MAY be modified by jitter, as defined in minimum interval MAY be modified by jitter, as defined in
[RFC5148].) [RFC5148].)
REFRESH_INTERVAL - is the maximum interval between advertisements in REFRESH_INTERVAL - is the maximum interval between advertisements in
a HELLO message of each 1-hop neighbor address and its status. In a HELLO message of each 1-hop neighbor address and its status. In
all intervals of length REFRESH_INTERVAL, a node MUST include all all intervals of length REFRESH_INTERVAL, a router MUST include
1-hop neighbor information which it is specified as sending in at all 1-hop neighbor information that it is specified as sending in
least one HELLO message on this MANET interface. at least one HELLO message on this MANET interface.
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o HELLO_INTERVAL > 0 o HELLO_INTERVAL > 0
o HELLO_MIN_INTERVAL >= 0 o HELLO_MIN_INTERVAL >= 0
o HELLO_INTERVAL >= HELLO_MIN_INTERVAL o HELLO_INTERVAL >= HELLO_MIN_INTERVAL
o REFRESH_INTERVAL >= HELLO_INTERVAL o REFRESH_INTERVAL >= HELLO_INTERVAL
o If INTERVAL_TIME message TLVs as defined in [timetlv] are included o If INTERVAL_TIME Message TLVs as defined in [timetlv] are included
in HELLO messages, then HELLO_INTERVAL MUST be representable as in HELLO messages, then HELLO_INTERVAL MUST be representable as
described in [timetlv]. described in [timetlv].
If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute
neighbor advertisements between HELLO messages in any manner, subject its neighbor advertisements between HELLO messages in any manner,
to the constraints above. subject to the constraints above.
For a node to employ this protocol in a purely responsive manner on a For a router to employ this protocol in a purely responsive manner on
MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be a MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be
set to a value such that a responsive HELLO message is always set to a value such that a responsive HELLO message is always
expected in a shorter period than this value. expected in a shorter period than this value.
If a router has more than one MANET interface, then, even if the
router configures different values of HELLO_INTERVAL on each
interface, the router SHOULD configure the same value of
HELLO_MIN_INTERVAL on all interfaces on which responsive HELLO
messages may be sent.
5.1.2. Information Validity Times 5.1.2. Information Validity Times
The following interface parameters manage the validity time of link The following interface parameters manage the validity time of link
information: information:
L_HOLD_TIME - is the period of advertisement, on this MANET L_HOLD_TIME - is the period of advertisement, on this MANET
interface, of former 1-hop neighbor addresses as lost in HELLO interface, of former 1-hop neighbor addresses as lost in HELLO
messages, allowing recipients of these HELLO messages to messages, allowing recipients of these HELLO messages to
accelerate removal of information from their Link Sets. accelerate removal of this information from their Link Sets.
L_HOLD_TIME can be set to zero if accelerated information removal L_HOLD_TIME MAY be set to zero, if accelerated information removal
is not required. is not required.
H_HOLD_TIME - is used as the value in the VALIDITY_TIME message TLV H_HOLD_TIME - is used as the value in the VALIDITY_TIME Message TLV
included in all HELLO messages on this MANET interface. included in all HELLO messages on this MANET interface.
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o L_HOLD_TIME >= 0 o L_HOLD_TIME >= 0
o H_HOLD_TIME >= REFRESH_INTERVAL o H_HOLD_TIME >= REFRESH_INTERVAL
o If HELLO messages can be lost then both SHOULD be significantly o If HELLO messages can be lost then both parameters SHOULD be
greater than REFRESH_INTERVAL. significantly greater than REFRESH_INTERVAL.
o H_HOLD_TIME MUST be representable as described in [timetlv]. o H_HOLD_TIME MUST be representable as described in [timetlv].
5.1.3. Link Quality 5.1.3. Link Quality
The following interface parameters manage the usage of link quality The following interface parameters manage the usage of link quality
(see Section 4.4): (see Section 14):
HYST_ACCEPT - is the link quality threshold at or above which a link HYST_ACCEPT - is the link quality threshold at or above which a link
becomes usable, if it was not already so. becomes usable, if it was not already so.
HYST_REJECT - is the link quality threshold below which a link HYST_REJECT - is the link quality threshold below which a link
becomes unusable, if it was not already so. becomes unusable, if it was not already so.
INITIAL_QUALITY - is the initial quality of a newly identified link. INITIAL_QUALITY - is the initial quality of a newly identified link.
INITIAL_PENDING - if true, then a newly identified link is INITIAL_PENDING - if true, then a newly identified link is
skipping to change at page 17, line 45 skipping to change at page 21, line 5
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1 o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1
o 0 <= INITIAL_QUALITY <= 1. o 0 <= INITIAL_QUALITY <= 1.
o If link quality is not updated, then INITIAL_QUALITY >= o If link quality is not updated, then INITIAL_QUALITY >=
HYST_ACCEPT. HYST_ACCEPT.
o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING == false. o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false.
o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING == true. o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true.
5.1.4. Jitter 5.1.4. Jitter
If jitter, as defined in [RFC5148], is used then these parameters are If jitter, as defined in [RFC5148], is used then these parameters are
as follows: as follows:
HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for periodically generated HELLO messages on this MANET interface. for periodically generated HELLO messages on this MANET interface.
HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for externally triggered HELLO messages on this MANET interface. for externally triggered HELLO messages on this MANET interface.
For constraints on these interface parameters see [RFC5148]. For constraints on these interface parameters see [RFC5148].
5.2. Node Parameters 5.2. Router Parameters
The two node parameters defined by this specification are in the The two router parameters defined by this specification are in the
category of information validity time. category of information validity time.
5.2.1. Information Validity Time 5.2.1. Information Validity Time
The following node parameter manages the validity time of lost The following router parameter manages the validity time of lost
symmetric 1-hop neighbor information: symmetric 1-hop neighbor information:
N_HOLD_TIME - is used as the period during which former 1-hop N_HOLD_TIME - is used as the period during which former 1-hop
neighbor addresses are advertised as lost in HELLO messages, neighbor addresses are advertised as lost in HELLO messages,
allowing recipients of these HELLO messages to accelerate removal allowing recipients of these HELLO messages to accelerate removal
of information from their 2-Hop Sets. N_HOLD_TIME can be set to of this information from their 2-Hop Sets. N_HOLD_TIME MAY be set
zero if accelerated information removal is not required. to zero, if accelerated information removal is not required.
I_HOLD_TIME - is the period for which a recently used local I_HOLD_TIME - is the period for which a recently used local
interface address is recorded. interface address is recorded.
The following constraints applies to these node parameters: The following constraints applies to these router parameters:
o N_HOLD_TIME >= 0 o N_HOLD_TIME >= 0
o I_HOLD_TIME >= 0 o I_HOLD_TIME >= 0
5.3. Parameter Change Constraints 5.3. Parameter Change Constraints
This section presents guidelines, applicable if protocol parameters This section presents guidelines, applicable if protocol parameters
are changed dynamically. are changed dynamically.
skipping to change at page 21, line 7 skipping to change at page 23, line 16
* If HT_MAXJITTER changes, then externally triggered HELLO * If HT_MAXJITTER changes, then externally triggered HELLO
messages on this MANET interface MAY be rescheduled. messages on this MANET interface MAY be rescheduled.
5.4. Constants 5.4. Constants
The constant C (time granularity) is used as specified in [timetlv]. The constant C (time granularity) is used as specified in [timetlv].
6. Local Information Base 6. Local Information Base
A node maintains a Local Information Base that records information A router maintains a Local Information Base that records information
about its interfaces (MANET and non-MANET). Each interface MUST have about its interfaces (MANET and non-MANET). Each interface MUST have
at least one address, and MAY have more than one address. at least one address, and MAY have more than one address.
The Local Information Base is not modified by signaling. If a node's The Local Information Base is not modified by signaling. If a
interface configuration changes, then the Local Information Base MUST router's interface configuration changes, then the Local Information
reflect these changes. This MAY also result in signaling to Base MUST reflect these changes. This MAY also result in signaling
advertise these changes. to advertise these changes.
Interfaces and addresses MAY be excluded from the Local Information
Base, and hence from HELLO messages, if they are not to be used for
routing.
6.1. Local Interface Set 6.1. Local Interface Set
A node's Local Interface Set records its local interfaces. It A router's Local Interface Set records its local interfaces. It
consists of Local Interface Tuples, one per interface: consists of Local Interface Tuples, one per interface:
(I_local_iface_addr_list, I_manet) (I_local_iface_addr_list, I_manet)
where: where:
I_local_iface_addr_list is an unordered list of the addresses of I_local_iface_addr_list is an unordered list of the addresses of
this interface. this interface.
I_manet is a boolean flag, describing if this interface is a MANET I_manet is a boolean flag, describing if this interface is a MANET
interface. 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 6.2. Removed Interface Address Set
A node's Removed Interface Address Set records addresses which were A router's Removed Interface Address Set records addresses which were
recently local interface addresses. If a node's interface addresses recently local interface addresses. If a router's interface
are immutable then this set is always empty and MAY be omitted. It addresses are immutable then this set is always empty and MAY be
consists of Removed Interface Address Tuples, one per address: omitted. It consists of Removed Interface Address Tuples, one per
address:
(IR_local_iface_addr, IR_time) (IR_local_iface_addr, IR_time)
where: where:
IR_local_iface_addr is a recently used address of an interface of IR_local_iface_addr is a recently used address of an interface of
this node. this router.
IR_time specifies when this Tuple expires and MUST be removed. IR_time specifies when this Tuple expires and MUST be removed.
7. Interface Information Base 7. Interface Information Base
A node maintains an Interface Information Base for each of its MANET A router maintains an Interface Information Base for each of its
interfaces. This records information about links to that MANET MANET interfaces. This records information about links to that MANET
interface and symmetric 2-hop neighbors which can be reached in two interface and symmetric 2-hop neighbors which can be reached in two
hops using those links as the first hop. The Interface Information hops using those links as the first hop. The Interface Information
Base includes the Link Set and the 2-Hop Set. Base includes the Link Set and the 2-Hop Set.
A MANET interface address can be present as of both a 1-hop neighbor A MANET interface address can be present as of both a 1-hop neighbor
and a symmetric 2-hop neighbor. This allows the node with this MANET and a symmetric 2-hop neighbor. This allows the router with this
interface address to be immediately considered as a symmetric 2-hop MANET interface address to be immediately considered as a symmetric
neighbor if it fails to be a symmetric 1-hop neighbor. 2-hop neighbor if it fails to be a symmetric 1-hop neighbor.
An element which specifies a time is considered expired if the
current time is greater than or equal to that time. One such element
in most Tuples when expired indicates that the Tuple itself is
considered expired and MUST be removed when that element so
indicates. Tuples which 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.
7.1. Link Set 7.1. Link Set
A node's Link Set records links from other nodes which are, or A router's Link Set records links from other routers which are, or
recently were, 1-hop neighbors. It consists of Link Tuples, each recently were, 1-hop neighbors. It consists of Link Tuples, each
representing a single link: representing a single link:
(L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time,
L_quality, L_pending, L_lost, L_time) L_quality, L_pending, L_lost, L_time)
where: where:
L_neighbor_iface_addr_list is an unordered list of the addresses of L_neighbor_iface_addr_list is an unordered list of the addresses of
the MANET interface of the 1-hop neighbor; the MANET interface of the 1-hop neighbor;
skipping to change at page 22, line 52 skipping to change at page 25, line 24
L_pending is a boolean flag, describing if a link is considered L_pending is a boolean flag, describing if a link is considered
pending (i.e. a candidate, but not yet established, link); pending (i.e. a candidate, but not yet established, link);
L_lost is a boolean flag, describing if a link is considered lost L_lost is a boolean flag, describing if a link is considered lost
due to link quality; due to link quality;
L_time specifies when this Tuple expires and MUST be removed. L_time specifies when this Tuple expires and MUST be removed.
The status of the link, as obtained through HELLO message exchange, The status of the link, as obtained through HELLO message exchange,
and also taking link quality into account is denoted L_status. and also taking link quality into account, is denoted L_status.
L_status can take the values PENDING, HEARD, SYMMETRIC and LOST. The L_status can take the values PENDING, HEARD, SYMMETRIC and LOST. The
values LOST, SYMMETRIC and HEARD are defined in Section 17.3. The values LOST, SYMMETRIC and HEARD are defined in Section 17.5. The
value PENDING is never used in a message, it is only used locally by value PENDING is never used in a HELLO message, it is only used
a node, and any value distinct from LOST, SYMMETRIC and HEARD may be locally by a router, and any value distinct from LOST, SYMMETRIC and
used. HEARD may be used.
L_status is defined by: L_status is defined by:
1. If L_pending is true, then L_status = PENDING; 1. If L_pending = true, then L_status := PENDING;
2. otherwise, if L_lost is true, then L_status = LOST; 2. otherwise, if L_lost = true, then L_status := LOST;
3. otherwise, if L_SYM_time is not expired, then L_status = 3. otherwise, if L_SYM_time is not expired, then L_status :=
SYMMETRIC; SYMMETRIC;
4. otherwise, if L_HEARD_time is not expired, then L_status = HEARD; 4. otherwise, if L_HEARD_time is not expired, then L_status :=
HEARD;
5. otherwise, L_status = LOST. 5. otherwise, L_status := LOST.
7.2. 2-Hop Set 7.2. 2-Hop Set
A node's 2-Hop Set records symmetric 2-hop neighbors, and the A router's 2-Hop Set records symmetric 2-hop neighbor interface
symmetric links to symmetric 1-hop neighbors through which the addresses, and the symmetric links to symmetric 1-hop neighbors
symmetric 2-hop neighbors can be reached. It consists of 2-Hop through which the symmetric 2-hop neighbors can be reached. It
Tuples, each representing a single interface address of a symmetric consists of 2-Hop Tuples, each representing a single interface
2-hop neighbor, and a single MANET interface of a symmetric 1-hop address of a symmetric 2-hop neighbor, and a single MANET interface
neighbor. of a symmetric 1-hop neighbor.
(N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time) (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)
where: where:
N2_neighbor_iface_addr_list is an unordered list of the addresses of N2_neighbor_iface_addr_list is an unordered list of the addresses of
the MANET interface of the symmetric 1-hop neighbor from which the MANET interface of the symmetric 1-hop neighbor from which
this information was received; this information was received;
N2_2hop_iface_addr is an address of an interface of a symmetric N2_2hop_iface_addr is an address of an interface of a symmetric
2-hop neighbor which has a symmetric link (using any MANET 2-hop neighbor which has a symmetric link (using any MANET
interface) to the indicated symmetric 1-hop neighbor; interface) to the indicated symmetric 1-hop neighbor;
N2_time specifies when this Tuple expires and MUST be removed. N2_time specifies when this Tuple expires and MUST be removed.
8. Node Information Base 8. Neighbor Information Base
Each node maintains a Node Information Base that records information Each router maintains a Neighbor Information Base that records
about addresses of current and recently symmetric 1-hop neighbors. information about addresses of current and recently symmetric 1-hop
neighbors.
8.1. Neighbor Set 8.1. Neighbor Set
A node's Neighbor Set records all interface addresses of each 1-hop A router's Neighbor Set records all interface addresses of each 1-hop
neighbor. It consists of Neighbor Tuples, each representing a single neighbor. It consists of Neighbor Tuples, each representing a single
1-hop neighbor: 1-hop neighbor:
(N_neighbor_iface_addr_list, N_symmetric) (N_neighbor_iface_addr_list, N_symmetric)
where: where:
N_neighbor_iface_addr_list is an unordered list of the interface N_neighbor_iface_addr_list is an unordered list of the interface
addresses of a 1-hop neighbor; addresses of a 1-hop neighbor;
N_symmetric is a boolean flag, describing if this is a symmetric N_symmetric is a boolean flag, describing if this is a symmetric
1-hop neighbor. 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 8.2. Lost Neighbor Set
A node's Lost Neighbor Set records addresses of all interfaces of A router's Lost Neighbor Set records addresses of all interfaces of
nodes which recently were symmetric 1-hop neighbors, but are now routers which recently were symmetric 1-hop neighbors, but are now
advertised as lost. It consists of Lost Neighbor Tuples, each advertised as lost. It consists of Lost Neighbor Tuples, each
representing a single such address: representing a single such address:
(NL_neighbor_iface_addr, NL_time) (NL_neighbor_iface_addr, NL_time)
where: where:
NL_neighbor_iface_addr is an address of an interface of a node which NL_neighbor_iface_addr is an address of an interface of a router
recently was a symmetric 1-hop neighbor of this node; which recently was a symmetric 1-hop neighbor of this router;
NL_time specifies when this Tuple expires and MUST be removed. NL_time specifies when this Tuple expires and MUST be removed.
9. Local Information Base Changes 9. Local Information Base Changes
The Local Information Base MUST change to respond to changes in the The Local Information Base MUST change to respond to changes in the
node's local interface configuration. The node MUST update its router's local interface configuration. The router MUST update its
Interface and Node Information Bases in response to such changes. If Interface Information Base and Neighbor Information Base in response
any changes in the Interface and Node Information Bases satisfy any to such changes. If any changes in the Interface Information Base or
of the conditions described in Section 13, then those changes must be the Neighbor Information Base satisfy any of the conditions described
applied immediately, unless noted otherwise. in Section 13, then those changes must be applied immediately, unless
noted otherwise.
A node MAY transmit HELLO messages in response to these changes. A router MAY transmit HELLO messages in response to these changes.
9.1. Adding an Interface 9.1. Adding an Interface
If an interface is added to the node then this is indicated by the 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 addition of a Local Interface Tuple to the Local Interface Set. If
the new interface is a MANET interface then an initially empty the new interface is a MANET interface then an initially empty
Interface Information Base MUST be created for this new MANET Interface Information Base MUST be created for this new MANET
interface. The actions in Section 9.3 MUST be taken for each address interface. The actions in Section 9.3 MUST be taken for each address
of this added interface. A HELLO message MAY be sent on all MANET 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 MANET interfaces, it SHOULD be sent on the new interface if it is a MANET
interface. If using scheduled messages, then a message schedule MUST interface. If using scheduled messages, then a message schedule MUST
be established on a new MANET interface. be established on a new MANET interface.
9.2. Removing an Interface 9.2. Removing an Interface
If an interface is removed from the node, then this MUST result in If an interface is removed from the router, then this MUST result in
changes to the Local Information Base and the Node Information Base changes to the Local Information Base and to the Neighbor Information
as follows: Base as follows:
1. Identify the Local Interface Tuple that corresponds to the 1. Identify the Local Interface Tuple that corresponds to the
interface to be removed. interface to be removed.
2. For each address (henceforth removed address) in the 2. For each address (henceforth removed address) in the
I_local_iface_addr_list of that Local Interface Tuple, create a I_local_iface_addr_list of that Local Interface Tuple, create a
Removed Interface Address Tuple with: Removed Interface Address Tuple with:
* IR_local_iface_addr = removed address; * IR_local_iface_addr := removed address;
* IR_time := current time + I_HOLD_TIME.
* IR_time = current time + I_HOLD_TIME.
3. Remove that Local Interface Tuple from the Local Interface Set. 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 4. If the interface to be removed is a MANET interface (i.e. with
I_manet == true) then: I_manet = true) then:
1. Remove the Interface Information Base for that MANET 1. Remove the Interface Information Base for that MANET
interface; interface;
2. All Neighbor Tuples for which none of the addresses in its 2. All Neighbor Tuples for which none of the addresses in its
N_neighbor_iface_addr_list are found in any N_neighbor_iface_addr_list are contained in any
L_neighbor_iface_addr_list in any remaining Link Set, are L_neighbor_iface_addr_list in any remaining Link Set, are
removed. removed.
If a node removes the Local Interface Tuple that contains the If a router removes the Local Interface Tuple that contains the
interface address that is used to define the node's originator interface address which is used to define the router's originator
address, as defined in [packetbb], then the node MAY change address, as defined in [RFC5444], then the router MAY change
originator address. originator address. If this interface address may now be used by
another router (e.g. if the address was taken from a prefix no longer
delegated to this router, or if the address was assigned with an
expiration timer, and not renewed before expiration) then this router
MUST change originator address.
If the removed interface is the last MANET interface of the node, If the removed interface is the last MANET interface of the router,
then there will be no remaining Interface Information Bases, and the then there will be no remaining Interface Information Bases, and the
node will longer participate in this protocol. router will longer participate in this protocol.
After removing the interface and making these changes, a HELLO After removing the interface and making these changes, a HELLO
message MAY be sent on all remaining MANET interfaces. message MAY be sent on all remaining MANET interfaces.
9.3. Adding an Address to an Interface 9.3. Adding an Address to an Interface
If an address is added to an interface then this is indicated by the If an address is added to an interface then this is indicated by the
addition of an address to the appropriate I_local_iface_addr_list. addition of an address to the appropriate I_local_iface_addr_list.
The following changes MUST be made to the Information Bases: The following changes MUST be made to the Information Bases:
1. The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list 1. The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list
contains the added address, are removed. contains the added address, are removed.
2. Any Link Tuples, in any Link Set, whose 2. Any Link Tuples, in any Link Set, whose
L_neighbor_iface_addr_list contains: L_neighbor_iface_addr_list contains:
* the added address; OR * the added address; OR
* any address in the N_neighbor_iface_addr_list of the removed * any address in the N_neighbor_iface_addr_list of any removed
Neighbor Tuples, if any Neighbor Tuple
are removed; apply Section 13.2, but not Section 13.3.
are removed; apply Section 13.1, but not Section 13.3.
3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr is the 3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr = the added
added address, are removed. address, are removed.
4. Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address, 4. Any 2-Hop Tuples whose N2_2hop_iface_addr = the added address,
are removed. are removed.
After adding the address and making these changes, a HELLO message After adding the address and making these changes, a HELLO message
MAY be sent on all MANET interfaces. MAY be sent on all MANET interfaces.
9.4. Removing an Address from an Interface 9.4. Removing an Address from an Interface
If an address (henceforth removed address) is removed from an If an address (henceforth removed address) is removed from an
interface then: interface then:
skipping to change at page 27, line 23 skipping to change at page 29, line 33
2. If this is the only address of that interface (the only address 2. If this is the only address of that interface (the only address
in the corresponding I_local_iface_addr_list) then remove that in the corresponding I_local_iface_addr_list) then remove that
interface as specified in Section 9.2. interface as specified in Section 9.2.
3. Otherwise: 3. Otherwise:
1. Remove the removed address from this I_local_iface_addr_list. 1. Remove the removed address from this I_local_iface_addr_list.
2. Create a Removed Interface Address Tuple with: 2. Create a Removed Interface Address Tuple with:
+ IR_local_iface_addr = removed address; + IR_local_iface_addr := removed address;
+ IR_time = current time + I_HOLD_TIME. + IR_time := current time + I_HOLD_TIME.
If a node removes the interface address that is used to define the If a router removes the interface address that is used to define the
node's originator address, as defined in [packetbb], then the node router's originator address, as defined in [RFC5444], then the router
MAY change originator address. MAY change originator address. If this interface address may now be
used by another router then this router MUST change originator
address.
After removing the address and making these changes, a HELLO message After removing the address and making these changes, a HELLO message
MAY be sent on all MANET interfaces. MAY be sent on all MANET interfaces.
10. Packets and Messages 10. Packets and Messages
The packet and message format used by this protocol is defined in The packet and message format used by this protocol is defined in
[packetbb], which is used with the following considerations: [RFC5444], which is used with the following considerations:
o This protocol specifies one message type, the HELLO message. o This protocol specifies one Message Type, the HELLO message.
o HELLO message header options MAY be used as specified by a o A HELLO message MAY use any combination of Message Header options.
protocol which uses this neighborhood discovery protocol.
o HELLO messages MUST NOT be forwarded. o HELLO messages MUST NOT be forwarded.
o HELLO messages MAY be included in multi-message packets as o HELLO messages MAY be included in multi-message packets as
specified in [packetbb]. specified in [RFC5444].
o Packet header options MAY be used as specified by a protocol which
uses this neighborhood discovery protocol.
o Received HELLO messages MUST be parsed in accordance with o Received HELLO messages MUST be parsed in accordance with
[packetbb]. A HELLO message which is not in conformance with [RFC5444]. A HELLO message which is not in conformance with
[packetbb] MUST be discarded. [RFC5444] MUST be discarded. A HELLO message may also be
discarded for other reasons, see Section 12.1.
o This protocol specifies three address block TLVs. It also uses o This protocol specifies three Address Block TLVs. It also uses
two message TLVs defined in [timetlv]. These five TLV types are two Message TLVs defined in [timetlv]. These five TLV Types are
all defined only with Type Extension == 0. TLVs of other types, all defined only with Type Extension = 0. TLVs of other types,
and of these types but without Type Extension == 0, are ignored by and of these types but without Type Extension = 0, are ignored by
this protocol. All references in this protocol to, for example, a this protocol. All references in this protocol to, for example,
TLV with Type == LINK_STATUS, are to be considered as referring to an Address Block TLV with Type = LINK_STATUS, are to be considered
a TLV with Type == LINK_STATUS and Type Extension == 0. as referring to an Address Block TLV with Type = LINK_STATUS and
Type Extension = 0.
10.1. HELLO Messages 10.1. HELLO Messages
A HELLO message MUST contain: A HELLO message MUST contain:
o A VALIDITY_TIME message TLV as specified in [timetlv], o A VALIDITY_TIME Message TLV as specified in [timetlv],
representing H_HOLD_TIME for the transmitting MANET interface. representing H_HOLD_TIME for the transmitting MANET interface.
The options included in [timetlv] for representing zero and The options included in [timetlv] for representing zero and
infinite times MUST NOT be used. infinite times MUST NOT be used.
A HELLO message which is transmitted periodically SHOULD contain, and A HELLO message which is transmitted periodically SHOULD contain, and
otherwise MAY contain: otherwise MAY contain:
o An INTERVAL_TIME message TLV as specified in [timetlv], o An INTERVAL_TIME Message TLV as specified in [timetlv],
representing HELLO_INTERVAL for the transmitting MANET interface. representing HELLO_INTERVAL for the transmitting MANET interface.
The options included in [timetlv] for representing zero and The options included in [timetlv] for representing zero and
infinite times MUST NOT be used. infinite times MUST NOT be used.
A HELLO message MAY contain: A HELLO message MAY contain:
o One or more address blocks, each with an associated TLV block. o Other Message TLVs.
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 10.1.1. Address Blocks
All addresses in a node's Local Interface Set (i.e. in any All addresses in a router's Local Interface Set (i.e. in any
I_local_iface_addr_list) MUST be included in the address blocks in I_local_iface_addr_list) MUST be included in the Address Blocks in
all generated HELLO messages with the following exception. If the all generated HELLO messages with the following exception. If the
MANET interface on which the HELLO message is to be sent has a single MANET interface on which the HELLO message is to be sent has a single
interface address with maximum prefix length then that address MAY be interface address with maximum prefix length, then that address MAY
omitted. All addresses of the node's interfaces included in an be omitted from being included in an Address Block, provided that
address block MUST be associated with a TLV with Type == LOCAL_IF, as this address is included as the sending address of the IP datagram in
defined in Table 1. which the HELLO message is included. All addresses of the router's
interfaces included in an Address Block MUST be associated with an
Address Block TLV with Type = LOCAL_IF, as defined in Table 1.
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
| LOCAL_IF | 1 octet | Specifies that the address is an address | | LOCAL_IF | 1 octet | Specifies that the address is an address |
| | | associated with the interface on which the | | | | associated with the interface on which the |
| | | message was sent (THIS_IF), another | | | | message was sent (THIS_IF) or another |
| | | interface of the sending node (OTHER_IF), or | | | | interface of the sending router (OTHER_IF). |
| | | an unspecified interface of the sending node |
| | | (UNSPEC_IF). |
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
Table 1 Table 1: LOCAL_IF TLV definition
Note that the value UNSPEC_IF is not used by this protocol. It is
provided for an expected alternative use of this TLV.
Address blocks MAY contain current or recently lost 1-hop neighbors' Address Blocks MAY contain current or recently lost 1-hop neighbors'
interface addresses, each of which is associated with address block interface addresses, each of which is associated with Address Block
TLVs as described in Table 2. TLVs as described in Table 2.
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
| LINK_STATUS | 1 octet | Specifies the status of the link from | | LINK_STATUS | 1 octet | Specifies the status of the link from |
| | | the indicated address (LOST, SYMMETRIC | | | | the indicated address (LOST, SYMMETRIC |
| | | or HEARD). | | | | or HEARD). |
| | | |
| OTHER_NEIGHB | 1 octet | Specifies that the address is | | OTHER_NEIGHB | 1 octet | Specifies that the address is |
| | | (SYMMETRIC) or was (LOST) of an | | | | (SYMMETRIC) or was (LOST) of an |
| | | interface of a symmetric 1-hop neighbor | | | | interface of a symmetric 1-hop neighbor |
| | | of the node transmitting the HELLO | | | | of the router transmitting the HELLO |
| | | message. | | | | message. |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
Table 2 Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition
A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value == An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or
LOST) also performs the function of a TLV with Type == OTHER_NEIGHB Value = LOST also performs the function of an Address Block TLV with
and the same value. The latter SHOULD NOT also be included. If a Type = OTHER_NEIGHB and the same value. The latter SHOULD NOT also
TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with be included. If an Address Block TLV with Type = LINK_STATUS and
a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter Value = SYMMETRIC is combined with an Address Block TLV with Type =
MUST be ignored, and SHOULD NOT be included. See Appendix A. OTHER_NEIGHB and Value = LOST then the latter MUST be ignored, and
SHOULD NOT be included. See Appendix A.
Other addresses MAY be included in address blocks, but MUST NOT be Other addresses MAY be included in Address Blocks, but MUST NOT be
associated with any of the TLVs specified in this section. associated with any of the Address Block TLVs specified in this
specification.
11. HELLO Message Generation 11. HELLO Message Generation
Each MANET interface MUST generate HELLO messages according to the Each MANET interface MUST generate HELLO messages according to the
specification in this section. HELLO message generation and specification in this section. HELLO messages are generated for each
HELLO interface independently. HELLO message generation and
scheduling MUST be according to the interface parameters for that scheduling MUST be according to the interface parameters for that
MANET interface and MAY be independent for each MANET interface or, MANET interface, and MAY be independent for each MANET interface or,
interface parameters permitting, MANET interfaces MAY use the same interface parameters permitting, MANET interfaces MAY use the same
schedule. schedule.
If transmitting periodic HELLO messages then, following a HELLO If transmitting periodic HELLO messages then, following a HELLO
message transmission on a MANET interface, another HELLO message MUST message transmission on a MANET interface, another HELLO message MUST
be transmitted on the same MANET interface after an interval not be transmitted on the same MANET interface after an interval not
greater than HELLO_INTERVAL. Two successive HELLO message greater than HELLO_INTERVAL. Two successive HELLO message
transmissions on the same MANET interface MUST be separated by at transmissions on the same MANET interface MUST be separated by at
least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1. least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.
11.1. HELLO Message Specification 11.1. HELLO Message Specification
HELLO messages are generated independently on each MANET interface. HELLO messages are generated independently on each MANET interface.
All addresses in any I_local_iface_addr_list MUST be included, except All addresses in any I_local_iface_addr_list MUST be included, except
that: that:
o If the interface on which the HELLO message is to be sent has a o If the interface on which the HELLO message is to be sent has a
single interface address with maximum prefix length then that single interface address with maximum prefix length then that
interface address MAY be omitted. interface 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 addresses MUST be associated with a TLV with Type All such included addresses MUST be associated with an Address Block
== LOCAL_IF and value according to the following: TLV included with Type := LOCAL_IF and Value according to the
following:
o If the address is of the sending interface, then Value == THIS_IF. o If the address is an address of the sending interface, then Value
:= THIS_IF.
o Otherwise, Value == OTHER_IF. o Otherwise, Value := OTHER_IF.
The following addresses of current or former 1-hop neighbors MAY be The following addresses of current or former 1-hop neighbors MAY be
included in any HELLO message: included in any HELLO message:
o Addresses of MANET interfaces of 1-hop neighbors from the Link Set o Addresses of MANET interfaces of 1-hop neighbors from the Link Set
of the Interface Information Base for this MANET interface. of the Interface Information Base for this MANET interface, other
than those from Link Tuples with L_status = PENDING.
o Other addresses of symmetric 1-hop neighbors from the Neighbor Set o Other addresses of symmetric 1-hop neighbors from the Neighbor Set
of this node's Node Information Base. of this router's Neighbor Information Base.
o Addresses of MANET interfaces of previously symmetric or heard o Addresses of MANET interfaces of previously symmetric or heard
1-hop neighbors connected on this MANET interface from the Link 1-hop neighbors connected on this MANET interface from the Link
Set of the Interface Information Base for this MANET interface. Set of the Interface Information Base for this MANET interface.
(These are advertised for a period equal to this interface's (These are advertised for a period equal to this interface's
L_HOLD_TIME after loss.) L_HOLD_TIME after loss.)
o Other addresses of previously symmetric 1-hop neighbors from the o Other addresses of previously symmetric 1-hop neighbors from the
Lost Neighbor Set of this node's Node Information Base. (These Lost Neighbor Set of this router's Neighbor Information Base.
are advertised for a period equal to N_HOLD_TIME after loss.) (These are advertised for a period equal to N_HOLD_TIME after
loss.)
Each such address MUST be associated with one or more appropriate Each such address MUST be associated with one or more appropriate
TLVs, respecting the parameter REFRESH_INTERVAL for each association Address Block TLVs, respecting the parameter REFRESH_INTERVAL for
for each MANET interface. Specifically: each association for each MANET interface. Specifically:
1. For each address (henceforth linked address) which appears in a 1. For each address (henceforth linked address) which is contained
Link Tuple in the Link Set for this MANET interface, for which in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set
L_status does not equal PENDING, include the linked address with for this MANET interface, for which L_status != PENDING, include
an associated TLV with: the linked address with an associated Address Block TLV with:
* Type = LINK_STATUS; AND * Type := LINK_STATUS; AND
* Value = L_status. * Value := L_status.
2. For each address (henceforth neighbor address) which appears in 2. For each address (henceforth neighbor address) which is contained
an N_neighbor_iface_addr_list in a Neighbor Tuple with in an N_neighbor_iface_addr_list in a Neighbor Tuple with
N_symmetric == true, and which has not already been included with N_symmetric = true, and which has not already been included with
an associated TLV with (Type == LINK_STATUS and Value == an associated Address Block TLV with Type = LINK_STATUS and Value
SYMMETRIC), include the neighbor address with an associated TLV = SYMMETRIC, include the neighbor address with an associated
with: Address Block TLV with:
* Type = OTHER_NEIGHB; AND * Type := OTHER_NEIGHB; AND
* Value = SYMMETRIC. * Value := SYMMETRIC.
3. For each Lost Neighbor Tuple whose NL_neighbor_iface_addr 3. For each Lost Neighbor Tuple whose NL_neighbor_iface_addr
(henceforth lost address) has not already been included, include (henceforth lost address) has not already been included, include
the lost address with an associated TLV with: the lost address with an associated Address Block TLV with:
* Type = OTHER_NEIGHB; AND * Type := OTHER_NEIGHB; AND
* Value = LOST. * Value := LOST.
If any such addresses have been added 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 address) have
changed since that address was last reported on this MANET interface,
then that address, and the indicated TLVs, MUST be included in the
HELLO message.
If a 1-hop neighbor address is specified with more than one If a 1-hop neighbor address is specified with more than one
associated TLV, then these TLVs MAY be independently included or associated Address Block TLV, then these Address Block TLVs MAY be
excluded from each HELLO message. Each such TLV MUST be included independently included or excluded from each HELLO message. Each
associated with that address in a HELLO message sent on that MANET such Address Block TLV MUST be included associated with that address
interface in every interval of length equal to that MANET interface's in a HELLO message sent on that MANET interface in every interval of
parameter REFRESH_INTERVAL. TLVs associated with the same address length equal to that MANET interface's parameter REFRESH_INTERVAL.
included in the same HELLO message MAY be applied to the same or Address Block TLVs associated with the same address included in the
different copies of that address. same HELLO message MAY be applied to the same or different copies of
that address.
11.2. HELLO Message Transmission 11.2. HELLO Message Transmission
HELLO messages are transmitted in the packet/message format specified HELLO messages are transmitted in the packet/message format specified
by [packetbb] using the "LL-MANET-Routers" multicast address by [RFC5444] using the "LL-MANET-Routers" multicast address specified
specified by [manet-iana] as destination IP address, using either the by [manet-iana] as destination IP address, using either the "manet"
"manet" UDP port, or the "manet" IP protocol number specified in UDP port, or the "manet" IP protocol number specified in
[manet-iana]. [manet-iana].
11.2.1. HELLO Message Jitter 11.2.1. HELLO Message Jitter
HELLO messages MAY be sent using periodic message generation or HELLO messages MAY be sent using periodic message generation or
externally triggered message generation. If using data link and externally triggered message generation. If using data link and
physical layers which are subject to packet loss due to collisions, physical layers which are subject to packet loss due to collisions,
HELLO messages SHOULD be jittered as described in [RFC5148]. HELLO messages SHOULD be jittered as described in [RFC5148].
Internally triggered message generation (such as due to a change in Internally triggered message generation (such as due to a change in
skipping to change at page 33, line 38 skipping to change at page 35, line 12
MAXJITTER. These interface parameters may be dynamic, and are MAXJITTER. These interface parameters may be dynamic, and are
specified by: specified by:
o For periodic message generation: HP_MAXJITTER. o For periodic message generation: HP_MAXJITTER.
o For externally triggered message generation: HT_MAXJITTER. o For externally triggered message generation: HT_MAXJITTER.
When HELLO message generation is delayed in order that a HELLO When HELLO message generation is delayed in order that a HELLO
message is not sent within HELLO_MIN_INTERVAL of the previous HELLO message is not sent within HELLO_MIN_INTERVAL of the previous HELLO
message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
be reduced by jitter, with maximum reduction HP_MAXJITTER. In this be reduced by jitter, with maximum reduction HP_MAXJITTER, as
case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL. described in [RFC5148]. In this case HP_MAXJITTER MUST NOT be
greater than HELLO_MIN_INTERVAL.
12. HELLO Message Processing 12. HELLO Message Processing
On receiving a HELLO message, a node MUST first check if any address On receiving a HELLO message, a router MUST first check if the
associated with a TLV with Type == LOCAL_IF is one of the receiving message is invalid for processing by this router, as defined in
node's current or recently used interface addresses (i.e. is in any Section 12.1. Otherwise the receiving router MUST update its
I_local_iface_addr_list in the Local Interface Set or is equal to any appropriate Interface Information Base and its Neighbor Information
IR_local_iface_addr in the Removed Interface Address Set). If so Base as specified in Section 12.3 to Section 12.6. These updates
then the HELLO message MUST be discarded. 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 MUST be
applied immediately, unless noted otherwise.
Otherwise the receiving node MUST update its appropriate Interface All message processing, including determination of whether a message
Information Base and its Node Information Base according to this is invalid, considers only TLVs with Type Extension = 0. TLVs with
section. Section 12.1 to Section 12.4 MUST be performed in the order any other type extension are ignored. All references to, for
presented. If any changes satisfy any of the conditions described in example, a TLV with Type = LINK_STATUS refer to a TLV with Type =
Section 13 then the indicated consequences MUST be applied LINK_STATUS and Type Extension = 0.
immediately, unless noted otherwise.
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 message has a <msg-hop-limit> field in its <msg-header> with a
value other than one. (Note that the message need not have a
<msg-hop-limit> field.)
o The message has a <msg-hop-count> field in its <msg-header> with a
value other than zero. (Note that the message need not 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, and these Message TLVs
indicate different validity times, as specified by [timetlv].
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 (including different copies of an 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 (the local address) associated with an Address Block
TLV with Type = LOCAL_IF is one of the receiving router's current
or recently used interface addresses (i.e. the local address is
contained in any I_local_iface_addr_list in the Local Interface
Set or the local address = 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 Any address (including different copies of an address, 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 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 (including different copies of an address, 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.
An invalid message MUST be silently discarded, without updating the
router's Information Bases. A router MAY recognize additional
reasons for identifying that a message is badly formed, and discard
such messages.
12.2. Definitions
For the purpose of this section, note the following definitions: For the purpose of this section, note the following definitions:
o "validity time" is calculated from the VALIDITY_TIME message TLV o "validity time" is calculated from the Message TLV with Type =
of the HELLO message as specified in [timetlv]. All information VALIDITY_TIME of the HELLO message as specified in [timetlv].
in the HELLO message has the same validity time. (Note that, as specified by Section 12.1, there must be such a
Message TLV, and if there is more than one, they must indicate the
same validity time.) All information in the HELLO message has the
same validity time.
o "Receiving Address List" is the I_local_iface_addr_list o "Receiving Address List" is the I_local_iface_addr_list
corresponding to the MANET interface on which the HELLO message corresponding to the MANET interface on which the HELLO message
was received was received
o "Sending Address List" is the list of the addresses contained in o "Sending Address List" is the list of the addresses contained in
the HELLO message with an associated TLV with Type == LOCAL_IF and the HELLO message with an associated Address Block TLV with Type =
Value == THIS_IF. If the Sending Address List is otherwise empty, LOCAL_IF and Value = THIS_IF. If the Sending Address List is
then the Sending Address List contains a single address (with otherwise empty, then the Sending Address List contains a single
maximum prefix length) equal to the sending address of the IP address (with maximum prefix length) equal to the sending address
datagram in which the HELLO message was included. of the IP datagram in which the HELLO message was included.
o "Neighbor Address List" is the Sending Address List, plus the o "Neighbor Address List" is the Sending Address List, plus the
addresses contained in the HELLO message with an associated TLV addresses contained in the HELLO message with an associated
with Type == LOCAL_IF and Value == OTHER_IF. Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF.
o EXPIRED indicates that a timer is set to a value clearly preceding o EXPIRED indicates that a timer is set to a value clearly preceding
the current time (e.g. current time - 1). the current time (e.g. current time - 1).
o "Removed Address List" is a list of addresses created by this o "Removed Address List" is a list of addresses created by this
HELLO message processing which were formerly reported as local by HELLO message processing which were formerly reported as local by
the node originating the HELLO message, but which are not included the router originating the HELLO message, but which are not
in the Neighbor Address List. This list is initialized as empty. included in the Neighbor Address List. This list is initialized
as empty.
o "Lost Address List" is a subset of the Removed Address List o "Lost Address List" is a subset of the Removed Address List
containing addresses which were formerly considered as symmetric. containing addresses which were formerly considered as symmetric.
This list is initialized as empty. This list is initialized as empty.
12.1. Updating the Neighbor Set 12.3. Updating the Neighbor Set
On receiving a HELLO message, the node MUST update its Neighbor Set On receiving a HELLO message, the router MUST update its Neighbor Set
and populate the Removed Address List and Lost Address List: and populate the Removed Address List and Lost Address List:
1. Find all Neighbor Tuples (hereafter matching Neighbor Tuples) 1. Find all Neighbor Tuples (hereafter matching Neighbor Tuples)
where: where:
* N_neighbor_iface_addr_list contains at least one address in * N_neighbor_iface_addr_list contains at least one address in
the Neighbor Address List. the Neighbor Address List.
2. If there are no matching Neighbor Tuples, then: 2. If there are no matching Neighbor Tuples, then:
1. Create a new Neighbor Tuple with: 1. Create a new Neighbor Tuple with:
+ N_neighbor_iface_addr_list = Neighbor Address List; + N_neighbor_iface_addr_list := Neighbor Address List;
+ N_symmetric = false. + N_symmetric := false.
3. If there is one matching Neighbor Tuple, then: 3. If there is one matching Neighbor Tuple, then:
1. If the N_neighbor_iface_addr_list of the matching Neighbor 1. If the matching Neighbor Tuple's N_neighbor_iface_addr_list
Tuple is not equal to the Neighbor Address List, then: != Neighbor Address List, then:
1. For each address (henceforth removed address) which is in 1. For each address (henceforth removed address) which is
the N_neighbor_iface_addr_list, but not in the Neighbor contained in that N_neighbor_iface_addr_list, but is not
Address List: contained in the Neighbor Address List:
1. Add the removed address to the Removed Address List. 1. Add the removed address to the Removed Address List.
2. If N_symmetric == true, then add the removed address 2. If N_symmetric = true, then add the removed address
to the Lost Address List. to the Lost Address List.
2. Update the matching Neighbor Tuple by: 2. Update the matching Neighbor Tuple by:
- N_neighbor_iface_addr_list = Neighbor Address List. - N_neighbor_iface_addr_list := Neighbor Address List.
4. If there are two or more matching Neighbor Tuples, then: 4. If there are two or more matching Neighbor Tuples, then:
1. For each address (henceforth removed address) which is in the 1. For each address (henceforth removed address) which is
N_neighbor_iface_addr_list of any of the matching Neighbor contained in the N_neighbor_iface_addr_list of any of the
Tuples: matching Neighbor Tuples:
1. Add the removed address to the Removed Address List. 1. Add the removed address to the Removed Address List.
2. If N_symmetric == true, then add the removed address to 2. If N_symmetric = true, then add the removed address to
the Lost Address List. the Lost Address List.
2. Replace the matching Neighbor Tuples by a single Neighbor 2. Replace the matching Neighbor Tuples by a single Neighbor
Tuple with: Tuple with:
+ N_neighbor_iface_addr_list = Neighbor Address List; + N_neighbor_iface_addr_list := Neighbor Address List;
+ N_symmetric = false + N_symmetric := false
12.2. Updating the Lost Neighbor Set 12.4. Updating the Lost Neighbor Set
On receiving a HELLO message, a node MUST update its Lost Neighbor On receiving a HELLO message, a router MUST update its Lost Neighbor
Set: Set:
1. For each address (henceforth lost address) in the Lost Address 1. For each address (henceforth lost address) which is contained in
List, if no Lost Neighbor Tuple with NL_neighbor_iface_addr == the Lost Address List, if no Lost Neighbor Tuple with
lost address exists, then add a Lost Neighbor Tuple with: NL_neighbor_iface_addr = lost address exists, then add a Lost
Neighbor Tuple with:
* NL_neighbor_iface_addr = lost address; * NL_neighbor_iface_addr := lost address;
* NL_time = current time + N_HOLD_TIME. * NL_time := current time + N_HOLD_TIME.
12.3. Updating the Link Set 12.5. Updating the Link Set
On receiving a HELLO message, a node MUST update its Link Set for the On receiving a HELLO message, a router MUST update its Link Set for
MANET interface on which the HELLO message is received: the MANET interface on which the HELLO message is received:
1. Remove all addresses in the Removed Address List from the 1. Remove all addresses in the Removed Address List from the
L_neighbor_iface_addr_list of all Link Tuples. L_neighbor_iface_addr_list of all Link Tuples.
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now 2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now
empty; apply Section 13.1, but not Section 13.3. empty; apply Section 13.2, but not Section 13.3.
3. Find all Link Tuples (hereafter matching Link Tuples) where: 3. Find all Link Tuples (hereafter matching Link Tuples) where:
* L_neighbor_iface_addr_list contains one or more addresses in * L_neighbor_iface_addr_list contains one or more addresses in
the Sending Address List. the Sending Address List.
4. If there is more than one matching Link Tuple, then remove them 4. If there is more than one matching Link Tuple, then remove them
all; apply Section 13.1, but not Section 13.3. all; apply Section 13.2, but not Section 13.3.
5. If no matching Link Tuples remain, then create a new matching 5. If no matching Link Tuples remain, then create a new matching
Link Tuple with: Link Tuple with:
* L_neighbor_iface_addr_list = empty; * L_neighbor_iface_addr_list := empty;
* L_HEARD_time = EXPIRED; * L_HEARD_time := EXPIRED;
* L_SYM_time = EXPIRED; * L_SYM_time := EXPIRED;
* L_quality = INITIAL_QUALITY;
* L_pending = INITIAL_PENDING; * L_quality := INITIAL_QUALITY;
* L_lost = false; * L_pending := INITIAL_PENDING;
* L_time = current time + validity time. * L_lost := false;
* L_time := current time + validity time.
6. The matching Link Tuple, existing or new, is then modified as 6. The matching Link Tuple, existing or new, is then modified as
follows: follows:
1. If the node finds any address (henceforth receiving address) 1. If the router finds any address (henceforth receiving
in the Receiving Address List in an address block in the address) in the Receiving Address List in an Address Block in
HELLO message, then the Link Tuple is modified as follows: the HELLO message, then the Link Tuple is modified as
follows:
1. If any receiving address in the HELLO message is 1. If any receiving address in the HELLO message is
associated with a TLV with Type == LINK_STATUS and (Value associated with an Address Block TLV with Type =
== HEARD or Value == SYMMETRIC) then: LINK_STATUS and with Value = HEARD or Value = SYMMETRIC
then:
- L_SYM_time = current time + validity time. - L_SYM_time := current time + validity time.
2. Otherwise if any receiving address in the HELLO message 2. Otherwise if any receiving address in the HELLO message
is associated with a TLV with Type == LINK_STATUS and is associated with an Address Block TLV with Type =
Value == LOST then: LINK_STATUS and Value = LOST then:
1. if L_SYM_time has not expired, then: 1. if L_SYM_time has not expired, then:
1. L_SYM_time = EXPIRED. 1. L_SYM_time := EXPIRED.
2. if L_status == HEARD or SYMMETRIC, then: 2. if L_status = HEARD or L_status = SYMMETRIC,
then:
* L_time = current time + L_HOLD_TIME. * L_time := current time + L_HOLD_TIME.
2. L_neighbor_iface_addr_list = Sending Address List. 2. L_neighbor_iface_addr_list := Sending Address List.
3. L_HEARD_time = max(current time + validity time, L_SYM_time). 3. L_HEARD_time := max(current time + validity time,
L_SYM_time).
4. If L_status == PENDING, then: 4. If L_status = PENDING, then:
+ L_time = max(L_time, L_HEARD_time). + L_time := max(L_time, L_HEARD_time).
5. Otherwise if L_status == HEARD or SYMMETRIC, then: 5. Otherwise if L_status = HEARD or L_status = SYMMETRIC, then:
+ L_time = max(L_time, L_HEARD_time + L_HOLD_TIME). + L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
12.4. Updating the 2-Hop Set 12.6. Updating the 2-Hop Set
On receiving a HELLO message a node MUST update its 2-Hop Set for the On receiving a HELLO message a router MUST update its 2-Hop Set for
MANET interface on which the HELLO message was received: the MANET interface on which the HELLO message was received:
1. Remove all addresses in the Removed Address List from the 1. Remove all addresses in the Removed Address List from the
N2_neighbor_iface_addr_list of all 2-Hop Tuples. N2_neighbor_iface_addr_list of all 2-Hop Tuples.
2. If the Link Tuple with L_neighbor_iface_addr_list == Sending 2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending
Address List has L_status == SYMMETRIC then: Address List, has L_status = SYMMETRIC then:
1. For each address (henceforth 2-hop address) in an address 1. For each address (henceforth 2-hop address) in an Address
block of the HELLO message, which is not in the Neighbor Block of the HELLO message, where:
Address List, in any I_local_iface_addr_list, or equal to any
IR_local_iface_addr:
1. If the 2-hop address has an associated TLV with: + 2-hop address is not contained in the Neighbor Address
List;
- Type == LINK_STATUS and Value == SYMMETRIC; OR + 2-hop address is not contained in any
I_local_iface_addr_list; AND
+ 2-hop address != any IR_local_iface_addr
- Type == OTHER_NEIGHB and Value == SYMMETRIC, 4. If 2-hop address has an associated Address Block TLV
with:
- Type = LINK_STATUS and Value = SYMMETRIC; OR
- Type = OTHER_NEIGHB and Value = SYMMETRIC,
then, if there is no 2-Hop Tuple such that: then, if there is no 2-Hop Tuple such that:
- N2_neighbor_iface_addr_list contains one or more - N2_neighbor_iface_addr_list contains one or more
addresses in the Sending Address List; AND addresses in the Sending Address List; AND
- N2_2hop_iface_addr == 2-hop address. - N2_2hop_iface_addr = 2-hop address.
then create a 2-Hop Neighbor Tuple with: then create a 2-Hop Neighbor Tuple with:
- N2_2hop_iface_addr = 2-hop address. - N2_2hop_iface_addr := 2-hop address.
This 2-Hop Tuple (existing or new) is then modified as This 2-Hop Tuple (existing or new) is then modified as
follows: follows:
- N2_neighbor_iface_addr_list = Sending Address List; - N2_neighbor_iface_addr_list := Sending Address List;
- N2_time = current time + validity time. - N2_time := current time + validity time.
2. Otherwise if the 2-hop address has a TLV with: 5. Otherwise if the 2-hop address has an Address Block TLV
with:
- Type == LINK_STATUS and (Value == LOST or Value == - Type = LINK_STATUS and Value = LOST or Value = HEARD;
HEARD); OR OR
- Type == OTHER_NEIGHB and Value == LOST; - Type = OTHER_NEIGHB and Value =o LOST;
then remove all 2-Hop Tuples with: then remove all 2-Hop Tuples with:
- N2_neighbor_iface_addr_list contains one or more - N2_neighbor_iface_addr_list contains one or more
addresses in the Sending Address List; AND addresses in the Sending Address List; AND
- N2_2hop_iface_addr == 2-hop address. - N2_2hop_iface_addr = 2-hop address.
13. Other Information Base Changes 13. Other Information Base Changes
The Interface and Node Information Bases MUST be changed when some The Interface and Neighbor Information Bases MUST be changed when
events occur. These events may result from HELLO message processing, some events occur. These events may result from HELLO message
or may be otherwise generated (e.g. expiry of timers or link quality processing, or may be otherwise generated (e.g. expiry of timers or
changes). link quality changes).
Events which cause changes in the Information Bases are: Events which cause changes in the Information Bases are:
o A Link Tuple's state changes from symmetric, or the Link Tuple is o A Link Tuple's L_status changes to symmetric.
removed.
o A Link Tuple's state changes to symmetric. o A Link Tuple's L_status changes from symmetric, or the Link Tuple
is removed.
o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed. o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed.
o Local interface address changes, as specified in Section 9. o Local interface address changes, as specified in Section 9.
o Link quality changes, as specified in Section 14. o Link quality changes, as specified in Section 14.
A node MAY report updated information in response to any of these If a Link Tuple is removed, or if L_status changes from symmetric and
L_HEARD_time expires, then Section 13.2 MUST be performed before
Section 13.3 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 changes in HELLO message(s), subject to the constraints in
Section 11. Section 11.
A node which transmits HELLO messages in response to such changes A router which transmits HELLO messages in response to such changes
SHOULD transmit a HELLO message: SHOULD transmit a HELLO message:
o On all MANET interfaces, if the Neighbor Set changes such as to o On all MANET interfaces, if the Neighbor Set changes such as to
indicate the change in symmetry of any 1-hop neighbors (including indicate the change in symmetry of any 1-hop neighbors (including
addition or removal of symmetric 1-hop neighbors). addition or removal of symmetric 1-hop neighbors).
o Otherwise, on all those MANET interfaces whose Link Set changes o Otherwise, on all those MANET interfaces whose Link Set changes
such as to indicate a change in status of any 1-hop neighbors 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 (including the addition or removal of any 1-hop neighbors, other
than those considered pending). than those considered pending).
13.1. Link Tuple Not Symmetric 13.1. Link Tuple Symmetric
If for any Link Tuple with L_status == SYMMETRIC: If, for any Link Tuple which does not have L_status = SYMMETRIC:
o L_status := SYMMETRIC;
(this includes a newly created Link Tuple which is immediately
updated to have L_status := SYMMETRIC) then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list, set:
* N_symmetric := true.
2. Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is
contained in that N_neighbor_iface_addr_list.
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 L_status changes to any other value; OR
o the Link Tuple is removed; o the Link Tuple is removed;
then: then:
1. All 2-Hop Tuples for the same MANET interface with: 1. All 2-Hop Tuples for the same MANET interface with:
* N2_neighbor_iface_addr_list contains one or more addresses in * N2_neighbor_iface_addr_list contains one or more addresses in
L_neighbor_iface_addr_list; L_neighbor_iface_addr_list;
are removed. are removed.
2. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 2. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list: L_neighbor_iface_addr_list:
1. If there are no remaining Link Tuples for any MANET interface 1. If there are no remaining Link Tuples for any MANET interface
with: where:
+ L_neighbor_iface_addr_list contained in + L_neighbor_iface_addr_list is contained in
N_neighbor_iface_addr_list; AND N_neighbor_iface_addr_list; AND
+ L_status == SYMMETRIC; + L_status = SYMMETRIC;
then modify the Neighbor Tuple by: then modify the Neighbor Tuple by:
1. N_symmetric = false. 1. N_symmetric := false.
2. For each address (henceforth neighbor address) in 2. For each address (henceforth neighbor address) in
N_neighbor_iface_addr_list, add a Lost Neighbor Tuple N_neighbor_iface_addr_list, add a Lost Neighbor Tuple
with: with:
- NL_neighbor_iface_addr = neighbor address; - NL_neighbor_iface_addr := neighbor address;
- NL_time = current time + N_HOLD_TIME.
13.2. Link Tuple Symmetric
If, for any Link Tuple which does not have L_status == SYMMETRIC:
o L_status changes to SYMMETRIC;
(this includes a newly created Link Tuple which is immediately
updated to have L_status == SYMMETRIC) then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list includes
L_neighbor_iface_addr_list, set:
* N_symmetric = true.
2. Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is - NL_time := current time + N_HOLD_TIME.
included in that N_neighbor_iface_addr_list.
13.3. Link Tuple Heard Timeout 13.3. Link Tuple Heard Timeout
If, for any Link Tuple: If, for any Link Tuple:
o L_HEARD_time expires; OR o L_HEARD_time expires; OR
o the Link Tuple is removed; o the Link Tuple is removed;
then: then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list, if no Link Tuples for any MANET L_neighbor_iface_addr_list, if no Link Tuples for any MANET
interface remain with: interface remain where:
* L_neighbor_iface_addr_list contained in * L_neighbor_iface_addr_list is contained in
N_neighbor_iface_addr_list; AND N_neighbor_iface_addr_list; AND
* L_HEARD_time is not expired; * L_HEARD_time is not expired;
then remove the Neighbor Tuple. then remove the Neighbor Tuple.
14. Link Quality 14. Link Quality
Link quality is a mechanism whereby a node MAY take considerations Link quality is a mechanism whereby a router MAY take considerations
other than message exchange into account for determining when a link other than message exchange into account for determining when a link
is and is not a candidate for being considered as HEARD or SYMMETRIC. is and is not a candidate for being considered as HEARD or SYMMETRIC.
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.
For deployments where no link quality is used, the considerations in For deployments where no link quality is used, the considerations in
Section 14.1 apply. For deployments were link quality is used, the Section 14.1 apply. For deployments where link quality is used, the
general principles of link quality usage are described in general principles of link quality usage are described in
Section 14.2. Section 14.3 and Section 14.4 detail link quality Section 14.2. Section 14.3 and Section 14.4 detail link quality
functioning. functioning.
Link quality is used only locally by a node, and nodes may fully
interoperate whether they are using the same, different or no link
quality methods.
14.1. Deployment Without Link Quality 14.1. Deployment Without Link Quality
In order for a node to not employ link quality, the node MUST define: In order for a router to not employ link quality, the router MUST
define:
o INITIAL_PENDING = false; o INITIAL_PENDING := false;
o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define
INITIAL_QUALITY = 1). INITIAL_QUALITY := 1).
14.2. Basic Principles of Link Quality 14.2. Basic Principles of Link Quality
To enable link quality usage, the L_quality value of a Link Tuple is 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, 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 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 these flags, the link status to advertise for that Link Tuple is
determined as described in Section 7.1. determined as described in Section 7.1.
The use of two thresholds implements link hysteresis, whereby a link The use of two thresholds implements link hysteresis, whereby a link
which has HYST_REJECT <= L_quality < HYST_ACCEPT may be either which has HYST_REJECT <= L_quality < HYST_ACCEPT may be either
accepted or rejected (depending on which threshold it has most accepted or rejected (depending on which threshold it has most
recently crossed, or if neither the value of INITIAL_QUALITY). With recently crossed, or, if neither, on the value of parameter
appropriate values of these parameters, this prevents over-rapid INITIAL_PENDING). With appropriate values of these parameters, this
changes of link status. prevents over-rapid changes of link status.
The basic principles of link quality usage are as follows: The basic principles of link quality usage are as follows:
o A node does not advertise a neighbor interface in any state until o A router does not advertise a neighbor interface in any state
L_quality is acceptable: until L_quality is acceptable:
* If INITIAL_PENDING == true, then this is such that L_quality >= * If INITIAL_PENDING = true, then this is such that L_quality >=
HYST_ACCEPT. HYST_ACCEPT.
* Otherwise this is such that L_quality >= HYST_REJECT. To * Otherwise this is such that L_quality >= HYST_REJECT. To
ensure this, a node MUST NOT define INITIAL_PENDING == false ensure this, a router MUST NOT define INITIAL_PENDING = false
and INITIAL_QUALITY < HYST_REJECT. (A node also MUST NOT and INITIAL_QUALITY < HYST_REJECT. (A router also MUST NOT
define INITIAL_PENDING == true and INITIAL_QUALITY >= define INITIAL_PENDING = true and INITIAL_QUALITY >=
HYST_ACCEPT.) HYST_ACCEPT.)
* A link which is not yet advertised has L_pending == true. A link which is not yet advertised has L_pending = true.
o Once L_quality >= HYST_ACCEPT, the L_pending flag is set false, o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false,
indicating that the link can be advertised. indicating that the link can be advertised.
o A link for which L_pending == false is advertised until its o A link for which L_pending = false is advertised until its
L_quality drops below HYST_REJECT. L_quality drops below HYST_REJECT.
o If a link has L_pending == false and L_quality < HYST_REJECT, the 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 link is LOST and is advertised as such. This link is not
reconsidered as a candidate HEARD or SYMMETRIC link until reconsidered as a candidate HEARD or SYMMETRIC link until
L_quality >= HYST_ACCEPT. L_quality >= HYST_ACCEPT.
o A link which has an acceptable quality may be advertised as HEARD, o A link which has an acceptable quality may be advertised as HEARD,
SYMMETRIC or LOST according to the exchange of HELLO messages. SYMMETRIC or LOST according to the exchange of HELLO messages.
14.3. When Link Quality Changes 14.3. When Link Quality Changes
If L_quality for a link changes, then the following actions MUST be If L_quality for a link changes, then the following actions MUST be
taken: taken:
1. If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is 1. If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is
modified by: modified by:
1. L_pending = false. 1. L_pending := false.
2. L_lost = false. 2. L_lost := false.
3. If L_status == HEARD or L_status == SYMMETRIC, then: 3. If L_status = HEARD or L_status = SYMMETRIC, then:
+ L_time = max(L_time, L_HEARD_time + L_HOLD_TIME) + L_time := max(L_time, L_HEARD_time + L_HOLD_TIME)
2. If L_status is not equal to PENDING, and L_quality < HYST_REJECT 2. If L_status != PENDING, and L_quality < HYST_REJECT then the
then the corresponding Link Tuple is modified by: corresponding Link Tuple is modified by:
1. If L_lost == false, then: 1. If L_lost = false, then:
+ L_lost = true + L_lost := true
+ L_time = min(L_time, current time + L_HOLD_TIME) + L_time := min(L_time, current time + L_HOLD_TIME)
Any appropriate action indicted in Section 13 MUST also be taken. Any appropriate action indicted in Section 13 MUST also be taken.
If L_quality for a link is updated based on HELLO message reception, 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 or on reception of a packet including a HELLO message, then L_quality
MUST be updated prior to the HELLO message processing described in MUST be updated prior to the HELLO message processing described in
Section 12. (If the receipt of the HELLO message, or the packet Section 12. (If the receipt of the HELLO message, or the packet
containing it, creates the Link Tuple then the Link Tuple MUST be containing it, creates the Link Tuple, then the Link Tuple MUST be
created with the appropriately updated L_quality value, rather than created with the appropriately updated L_quality value, rather than
with L_quality = INITIAL_QUALITY.) with L_quality := INITIAL_QUALITY.)
14.4. Updating Link Quality 14.4. Updating Link Quality
A node MAY update link quality based on any information available to A router MAY update link quality based on any information available
it. Particular cases that MAY be used include: to it. Particular cases that MAY be used include:
o Information from the link layer, such as signal to noise ratio or o Information from the link layer, such as signal to noise ratio or
acknowledgement reception and loss information. packet acknowledgement reception and loss information.
o Receipt or loss of packets. If packets include a packet sequence o Receipt or loss of control packets. If control packets include a
number as defined in [packetbb], then packets on a link SHOULD sequential packet sequence number, as defined in [RFC5444], then
have sequential packet sequence numbers, whether or not they link quality can be updated when a control packet is received,
include HELLO messages. Link quality can be updated when a packet whether or not it contains a HELLO message. The link quality may
is received based on, for example, whether the last N out of M then, for example, be based on whether the last N out of M control
packets on the link were received, or a "leaky integrator" packets on the link were received, or may use a "leaky integrator"
tracking packets. tracking packet reception and loss.
o Receipt or loss of HELLO messages. If the maximum interval o Receipt or loss of HELLO messages. If the maximum interval
between HELLO messages is known (such as by inclusion of a message between HELLO messages is known (such as by inclusion in HELLO
TLV with Type == INTERVAL_TIME, as defined in [timetlv], in HELLO messages of a Message TLV with Type := INTERVAL_TIME, as defined
messages) then the loss of HELLO messages can be determined in [timetlv]) then the loss of HELLO messages can be determined
without the need to receive a HELLO message. Note that if this without the need to receive a later HELLO message. Note that if
case is combined with the previous case then care must be taken to this case is combined with the previous case then care must be
avoid "double counting" a lost HELLO message in a lost packet. taken to avoid "double counting" a lost HELLO message in a lost
packet.
15. Proposed Values for Parameters and Constants 15. Proposed Values for Parameters and Constants
This section lists the parameters and constants used in the This section lists the parameters and constants used in the
specification of the protocol, and proposed values of each which may specification of the protocol, and proposed values of each which may
be used when a single value of each is used. be used when a single value of each is used.
15.1. Message Interval Interface Parameters 15.1. Message Interval Interface Parameters
o HELLO_INTERVAL = 2 seconds o HELLO_INTERVAL := 2 seconds
o HELLO_MIN_INTERVAL = HELLO_INTERVAL/4 o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4
o REFRESH_INTERVAL = HELLO_INTERVAL o REFRESH_INTERVAL := HELLO_INTERVAL
15.2. Information Validity Time Interface Parameters 15.2. Information Validity Time Interface Parameters
o H_HOLD_TIME = 3 x REFRESH_INTERVAL o H_HOLD_TIME := 3 x REFRESH_INTERVAL
o L_HOLD_TIME = H_HOLD_TIME o L_HOLD_TIME := H_HOLD_TIME
15.3. Information Validity Time Node Parameters 15.3. Information Validity Time Router Parameters
o N_HOLD_TIME = L_HOLD_TIME o N_HOLD_TIME := L_HOLD_TIME
o I_HOLD_TIME = N_HOLD_TIME o I_HOLD_TIME := N_HOLD_TIME
15.4. Link Quality Interface Parameters 15.4. Link Quality Interface Parameters
If link quality is changed, then parameter values will depend on the If link quality is changed, then parameter values will depend on the
link quality process. If link quality is not changed, then: link quality process. If link quality is not changed, then:
o HYST_ACCEPT = 1 o HYST_ACCEPT := 1
o HYST_REJECT = 0
o INITIAL_QUALITY = 1 o HYST_REJECT := 0
o INITIAL_QUALITY := 1
o INITIAL_PENDING = false o INITIAL_PENDING := false
15.5. Jitter Interface Parameters 15.5. Jitter Interface Parameters
o HP_MAXJITTER = HELLO_INTERVAL/4 o HP_MAXJITTER := HELLO_INTERVAL/4
o HT_MAXJITTER = HP_MAXJITTER o HT_MAXJITTER := HP_MAXJITTER
15.6. Constants 15.6. Constants
o C = 1/1024 second o C := 1/1024 second
16. Security Considerations 16. Security Considerations
The objective of this protocol is to allow each node in the network The objective of this protocol is to allow each router in the network
to acquire information describing its 1-hop and symmetric 2-hop to acquire information describing its 1-hop and symmetric 2-hop
neighborhoods. This is acquired through message exchange between neighborhoods. This is acquired through message exchange between
neighboring nodes. The information is made available through the neighboring routers. The information is made available through the
Interface Information Bases and Node Information Base, describing the Interface Information Bases and Neighbor Information Base, describing
node's 1-hop neighborhood and symmetric 2-hop neighborhood. the router's 1-hop neighborhood and symmetric 2-hop neighborhood.
Under normal circumstances, the information recorded in these Under normal circumstances, the information recorded in these
Information Bases is correct - i.e. corresponds to the actual network Information Bases is correct, i.e. corresponds to the actual network
topology, apart from any changes which have not (yet) been tracked by topology, apart from any changes which have not (yet) been tracked by
the HELLO message exchanges. the HELLO message exchanges.
If some node for some reason, malice or malfunction, injects invalid If a router for some reason, whether malice or malfunction, injects
HELLO messages, incorrect information may be recorded in the invalid HELLO messages, incorrect information may be recorded in
Information Bases. The protocol specification does, however, prevent other routers' Information Bases. The protocol specification does,
inconsistent information from being injected in the protocol sets however, prevent inconsistent information from being injected in the
through the constraints in Appendix C. The exact consequence of protocol sets through the constraints in Appendix B. The exact
information inexactness depends on the use of these Information consequence of information inexactness depends on the use of these
Bases, and should be reflected in the specification of protocols Information Bases, and should be reflected in the specification of
which use information provided by NHDP. protocols which use information provided by NHDP.
This section, therefore, only outlines the ways in which correctly This section, therefore, only outlines the ways in which correctly
formed, but still invalid, HELLO messages may appear. formed, but still invalid, HELLO messages may appear, in
Section 16.1. In addition, in Section 16.2, the security suggestions
in [RFC5444] are considered for applicability.
16.1. Invalid HELLO messages 16.1. Invalid HELLO messages
A correctly formed, but still invalid, HELLO message may take any of A correctly formed, but still invalid, HELLO message may take any of
the following forms. Note that a present or absent address in an the following forms. Note that a present or absent address in an
address block, does not in and by itself cause a problem. It is the Address Block, does not in and by itself cause a problem. It is the
presence, absence, or incorrectness of associated LOCAL_IF, presence, absence, or incorrectness of associated LOCAL_IF,
LINK_STATUS and OTHER_NEIGHB TLVs that causes problems. LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems.
A node may provide false information about its own identity: A router may provide false information about its own identity:
* The HELLO message may contain addresses with an associated * The HELLO message may contain addresses with an associated
LOCAL_IF TLV which do not correspond to addresses of interfaces LOCAL_IF Address Block TLV which do not correspond to addresses
of the node transmitting the HELLO message. of interfaces of the router transmitting the HELLO message.
* The HELLO message may omit addresses, or their associated * The HELLO message may omit addresses, or their associated
LOCAL_IF TLV, of interfaces of the local node transmitting the LOCAL_IF Address Block TLV, of interfaces of the router
HELLO message (other than the allowed omission of the only transmitting the HELLO message (other than the allowed omission
local interface address of the MANET interface over which the of the only local interface address of the MANET interface over
HELLO message is transmitted, if that is the case). which the HELLO message is transmitted, if that is the case).
* The HELLO message may incorrectly specify the LOCAL_IF TLV
value associated with one or more local interface addresses,
indicating incorrectly whether they are associated with the
MANET interface over which the HELLO message is transmitted.
A node may provide false information about the identity of other * The HELLO message may incorrectly specify the LOCAL_IF Address
nodes: Block TLV value associated with one or more local interface
addresses, indicating incorrectly whether they are associated
with the MANET interface over which the HELLO message is
transmitted.
* A present LINK_STATUS TLV may, incorrectly, identify an address A router may provide false information about the identity of other
as being of a MANET interface which is or was heard on the routers:
MANET interface over which the HELLO message is transmitted.
* A consistently absent LINK_STATUS TLV may, incorrectly, fail to * A present LINK_STATUS Address Block TLV may, incorrectly,
identify an address as being of a MANET interface which is or identify an address as being of a MANET interface which is or
was heard on the MANET interface over which the HELLO message was heard on the MANET interface over which the HELLO message
is transmitted. is transmitted.
* A present OTHER_NEIGHB TLV may, incorrectly, identify an * A consistently absent LINK_STATUS Address Block TLV may,
address as being of a node which is or was in the sending incorrectly, fail to identify an address as being of a MANET
node's symmetric 1-hop neighborhood; interface which is or was heard on the MANET interface over
which the HELLO message is transmitted.
* A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail * A present OTHER_NEIGHB Address Block TLV may, incorrectly,
to identify an address as being of a node which is or was in identify an address as being of a router which is or was in the
the sending node's symmetric 1-hop neighborhood; sending router's symmetric 1-hop neighborhood;
* The value of a LINK_STATUS TLV may incorrectly indicate the * A consistently absent OTHER_NEIGHB Address Block TLV may,
status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop incorrectly, fail to identify an address as being of a router
which is or was in the sending router's symmetric 1-hop
neighborhood;
* 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.
* The value of an OTHER_NEIGHB Address Block TLV may incorrectly
indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop
neighbor. neighbor.
* The value of an OTHER_NEIGHB TLV may incorrectly indicate the 16.2. Authentication, Integrity and Confidentiality Suggestions
status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.
The security mechanisms suggested in [RFC5444] with respect to
authentication and integrity can be applied to this neighborhood
discovery protocol, with the following additional considerations:
o As HELLO messages MUST NOT be forwarded, the fields <msg-hop-
count> and <msg-hop-limit> are either omitted, or will always have
the values of 0 and 1, respectively.
o Consequently, a cryptographic signature can be calculated based on
the entire HELLO message, including its Message Header, and
included in a Message TLV of an appropriate type.
o As HELLO messages MUST NOT be forwarded, and in case hop-by-hop
packet level authentication and integrity is ensured by including
an appropriate Packet TLV containing a cryptographic signature
across the entire packet, inclusion of an additional Message TLV
containing a cryptographic signature for the HELLO Message may not
be necessary.
The security mechanisms suggested in [RFC5444] with respect to
confidentiality can be directly applied to this neighborhood
discovery protocol.
17. IANA Considerations 17. IANA Considerations
17.1. Message Types This specification defines one Message Type, which must be allocated
from the "Message Types" repository of [RFC5444], and three Address
Block TLV Types, which must be allocated from the "Message TLV Types"
repository of [RFC5444].
This specification defines one message type, to be allocated from the 17.1. Expert Review: Evaluation Guidelines
0-223 range of the "Message Types" namespace defined in [packetbb],
as specified in Table 3.
+-------+------+------------------+ 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].
17.2. Message Types
This specification defines one Message Type, to be allocated from the
0-223 range of the "Message Types" namespace defined in [RFC5444], as
specified in Table 3.
+-------+------+-----------------+
| Name | Type | Description | | Name | Type | Description |
+-------+------+------------------+ +-------+------+-----------------+
| HELLO | TBD1 | Local signaling. | | HELLO | TBD1 | Local signaling |
+-------+------+------------------+ +-------+------+-----------------+
Table 3 Table 3: Message Type assignment
17.2. Address Block TLV Types 17.3. Message-Type-specific TLV Type Registries
This specification defines three address block TLV types, which must IANA is requested to create a registry for Message-Type-specific
Message TLVs for HELLO messages, in accordance with Section 6.4 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 is requested to create a registry for Message-Type-specific
Address Block TLVs for HELLO messages, in accordance with Section 6.5
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
17.4. Address Block TLV Types
This specification defines three Address Block TLV Types, which must
be allocated from the "Address Block TLV Types" namespace defined in be allocated from the "Address Block TLV Types" namespace defined in
[packetbb]. IANA are requested to make allocations in the 8-127 [RFC5444]. IANA are requested to make allocations in the 0-127 range
range for these types. This will create three new type extension for these types. This will create three new type extension
registries with assignments as specified in Table 4, Table 5 and registries with assignments as specified in Table 6, Table 7 and
Table 6. Specifications of these TLVs are in Section 10.1.1, with Table 8. Specifications of these Address Block TLVs are in
value constants defined in Section 17.3. Section 10.1.1, with value constants defined in Section 17.5.
+----------+------+-----------+-------------------------------------+ +----------+------+-----------+-------------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+----------+------+-----------+-------------------------------------+ +----------+------+-----------+-------------------------------------+
| LOCAL_IF | TBD2 | 0 | Specifies that the address is | | LOCAL_IF | TBD2 | 0 | Specifies that the address is |
| | | | associated with a local interface | | | | | associated with a local interface |
| | | | of the sending node. | | | | | of the sending router |
| | | | |
| | | 1-255 | Expert Review | | | | 1-255 | Expert Review |
+----------+------+-----------+-------------------------------------+ +----------+------+-----------+-------------------------------------+
Table 4 Table 6: Address Block TLV Type assignment: LOCAL_IF
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
| LINK_STATUS | TBD3 | 0 | Specifies the status of the link | | LINK_STATUS | TBD3 | 0 | Specifies the status of the link |
| | | | from the indicated address | | | | | from the indicated address |
| | | | (LOST, SYMMETRIC or HEARD). | | | | | (LOST, SYMMETRIC or HEARD) |
| | | | |
| | | 1-255 | Expert Review | | | | 1-255 | Expert Review |
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
Table 5 Table 7: Address Block TLV Type assignment: LINK_STATUS
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
| OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is | | OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is |
| | | | (SYMMETRIC) or recently was | | | | | (SYMMETRIC) or recently was |
| | | | (LOST) of an interface of a | | | | | (LOST) of an interface of a |
| | | | symmetric 1-hop neighbor of the | | | | | symmetric 1-hop neighbor of the |
| | | | node transmitting the message. | | | | | router transmitting the message |
| | | | |
| | | 1-255 | Expert Review | | | | 1-255 | Expert Review |
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
Table 6 Table 8: Address Block TLV Type assignment: OTHER_NEIGHB
Type extensions indicated as Expert Review SHOULD be allocated as 17.5. LINK_STATUS and OTHER_NEIGHB Values
described in [packetbb], based on Expert Review as defined in
[RFC5226].
17.3. LINK_STATUS and OTHER_NEIGHB Values The values which the LOCAL_IF Address Block TLV can use are the
following:
The values which the LOCAL_IF TLV can use are the following: o THIS_IF := 0
o UNSPEC_IF = 0 o OTHER_IF := 1
o THIS_IF = 1 The values which the LINK_STATUS Address Block TLV can use are the
following:
o OTHER_IF = 2 o LOST := 0
The values which the LINK_STATUS TLV can use are the following: o SYMMETRIC := 1
o LOST = 0 o HEARD := 2
o SYMMETRIC = 1 The values which the OTHER_NEIGHB Address Block TLV can use are the
o HEARD = 2 following:
The values which the OTHER_NEIGHB TLV can use are the following: o LOST := 0
o LOST = 0 o SYMMETRIC := 1
o SYMMETRIC = 1 18. Contributors
18. References This specification is the result of the joint efforts of the
following contributors, listed alphabetically.
18.1. Normative References 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>
19. Acknowledgements
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.
20. References
20.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", RFC 5148, February 2008. considerations in MANETs", RFC 5148, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
an IANA Considerations Section in RFCs", RFC 5226, "Generalized MANET Packet/Message Format", RFC 5444,
BCP 26, May 2008. February 2009.
[packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-13.txt, June 2008.
[timetlv] Clausen, T. and C. Dearlove, "Representing multi-value [timetlv] Clausen, T. and C. Dearlove, "Representing multi-value
time in MANETs", Work In time in MANETs", Work In
Progress draft-ietf-manet-timetlv-04.txt, Progress draft-ietf-manet-timetlv-08.txt,
November 2007. September 2008.
[manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols", [manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
Work In Progress draft-ietf-manet-iana-07.txt, Work In Progress draft-ietf-manet-iana-07.txt,
November 2007. November 2007.
18.2. Informative References 20.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC5449] Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet,
"OSPF Multipoint Relay (MPR) Extension for Ad Hoc
Networks", RFC 5449, February 2009.
Appendix A. Address Block TLV Combinations Appendix A. Address Block TLV Combinations
The algorithm for generating HELLO messages in Section 11 specifies The algorithm for generating HELLO messages in Section 11 specifies
which 1-hop addresses may be included in the address blocks, and with which 1-hop addresses may be included in the Address Blocks, and with
which associated TLVs. These TLVs may have Type == LINK_STATUS or which associated Address Block TLVs. These Address Block TLVs may
Type == OTHER_NEIGHB, or both. TLVs with Type == LINK_STATUS may have Type = LINK_STATUS or Type = OTHER_NEIGHB, or both. Address
have three possible values (Value == HEARD, Value == SYMMETRIC or Block TLVs with Type = LINK_STATUS may have three possible values
Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two (Value = HEARD, Value = SYMMETRIC or Value = LOST), and Address Block
possible values (Value == SYMMETRIC or Value == LOST). When both TLVs of TYPE = OTHER_NEIGHB may have two possible values (Value =
TLVs are associated with the same address only certain combinations SYMMETRIC or Value = LOST). When both Address Block TLVs are
of these TLV values are necessary, and are the only combinations associated with the same 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 generated by the algorithm in Section 11. These combinations are
indicated in Table 7. indicated in Table 9.
Cells labeled with "Yes" indicate the possible combinations which are Cells labeled with "Yes" indicate the possible combinations which are
generated by the algorithm in Section 11. Cells labeled with "No" generated by the algorithm in Section 11. Cells labeled with "No"
indicate combinations not generated by the algorithm in Section 11, indicate combinations not generated by the algorithm in Section 11,
but which are correctly parsed and interpreted by the algorithm in but which are correctly parsed and interpreted by the algorithm in
Section 12. Section 12. The cell labeled with "No*" is actually inconsistent, it
is handled by ignoring the Address Block TLV with Type =
OTHER_NEIGHB.
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | Type == | Type == | Type == | | | Type = | Type = | Type = |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value == | Value == LOST | | | (absent) | Value = | Value = LOST |
| | | SYMMETRIC | | | | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| Type == | No | Yes | Yes | | Type = | No | Yes | Yes |
| LINK_STATUS | | | | | LINK_STATUS | | | |
| (absent) | | | | | (absent) | | | |
| | | | | | Type = | Yes | Yes | Yes |
| Type == | Yes | Yes | Yes |
| LINK_STATUS, | | | | | LINK_STATUS, | | | |
| Value == HEARD | | | | | Value = HEARD | | | |
| | | | | | Type = | Yes | No | No* |
| Type == | Yes | No | No |
| LINK_STATUS, | | | | | LINK_STATUS, | | | |
| Value == | | | | | Value = | | | |
| SYMMETRIC | | | | | SYMMETRIC | | | |
| | | | | | Type = | Yes | Yes | No |
| Type == | Yes | Yes | No |
| LINK_STATUS, | | | | | LINK_STATUS, | | | |
| Value == LOST | | | | | Value = LOST | | | |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
Table 7 Table 9: LINK_STATUS and OTHER_NEIGHB TLV combinations
Appendix B. HELLO Message Example
An example HELLO message, transmitted by an originator node with a
single MANET interface, is as follows. The message uses IPv4 (four
octet) addresses without specified prefix lengths. The message is
transmitted with a full message header (flags octet value is 240)
with a hop limit of 1 and a hop count of 0. The overall message
length is 49 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 TLV with flags octet value 16, indicating
that each has a value. Each has a value length of 1 octet; the
values included (0x64 and 0x58) are time codes representing the
default values of parameters H_HOLD_TIME and HELLO_INTERVAL,
respectively (6 seconds and 2 seconds) assuming the default value of
constant C (1/1024 second).
The message has a single address block containing 5 addresses. The
flags octet value 128 indicates an address head but no address tail.
The head length of 3 octets indicates address mid sections of one
octet each (Mid 0 to Mid 4).
The following TLV block (content length 14 octets) includes two TLVs.
The first is a LOCAL_IF TLV which (with flags octet value 80)
indicates that a single address, with index 0 (i.e. Head:Mid 0) is
the single local interface address of this node (the 1 octet value
THIS_IF indicates that this address is of this interface). The
second is a LINK_STATUS TLV which (with flags octet value 48)
specifies the link status values of all reported neighbors in a
single multivalue TLV which covers the addresses with indexes 1 to 4.
The TLV value length of 4 octets indicates one octet per value per
address. The last four addresses are first and second HEARD, third
SYMMETRIC, and fourth LOST.
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 |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 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| INTERVAL_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 0 | Mid 1 | Mid 2 | Mid 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS |0 0 1 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| 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 is not needed) by the 29 octets:
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 0 0|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 |
+-+-+-+-+-+-+-+-+
Appendix C. Constraints Appendix B. Constraints
Any process which updates the Local Information Base or the Node Any process which updates the Local Information Base or the Neighbor
Information Base MUST ensure that all constraints specified in this Information Base MUST ensure that all constraints specified in this
appendix are maintained. appendix are maintained.
In each Local Interface Tuple: In each Local Interface Tuple:
o I_local_iface_addr_list MUST NOT be empty. o I_local_iface_addr_list MUST NOT be empty.
o I_local_iface_addr_list MUST NOT contain any duplicated addresses. o I_local_iface_addr_list MUST NOT contain any duplicated addresses.
o I_local_iface_addr_list MUST NOT contain any address which is in o I_local_iface_addr_list MUST NOT contain any address which is in
skipping to change at page 59, line 25 skipping to change at page 57, line 8
o N_neighbor_iface_addr_list MUST NOT contain any address which is o N_neighbor_iface_addr_list MUST NOT contain any address which is
in the I_local_iface_addr_list of any Local Interface Tuple or the in the I_local_iface_addr_list of any Local Interface Tuple or the
IR_local_iface_addr of any Removed Interface Address Tuple. IR_local_iface_addr of any Removed Interface Address Tuple.
o N_neighbor_iface_addr_list MUST NOT contain any duplicated o N_neighbor_iface_addr_list MUST NOT contain any duplicated
addresses. addresses.
o N_neighbor_iface_addr_list MUST NOT contain any address which is o N_neighbor_iface_addr_list MUST NOT contain any address which is
in the N_neighbor_iface_addr_list of any other Neighbor Tuple. in the N_neighbor_iface_addr_list of any other Neighbor Tuple.
o If N_symmetric == true, then there MUST be one or more Link Tuples o If N_symmetric is = true, then there MUST be one or more Link
with: Tuples with:
* L_neighbor_iface_addr_list contained in * L_neighbor_iface_addr_list contained in
N_neighbor_iface_addr_list; AND N_neighbor_iface_addr_list; AND
* L_status == SYMMETRIC. * L_status = SYMMETRIC.
o If N_symmetric == false, then there MUST be one or more Link o If N_symmetric is = false, then there MUST be one or more Link
Tuples with: Tuples with:
* L_neighbor_iface_addr_list contained in * L_neighbor_iface_addr_list contained in
N_neighbor_iface_addr_list. N_neighbor_iface_addr_list.
All such Link Tuples MUST NOT have L_status == SYMMETRIC. At All such Link Tuples MUST NOT have L_status = SYMMETRIC. At least
least one such Link Tuple MUST have L_HEARD_time not expired. one such Link Tuple MUST have L_HEARD_time not expired.
In each Lost Neighbor Tuple: In each Lost Neighbor Tuple:
o NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list o NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list
of any Local Interface Tuple or the IR_local_iface_addr of any of any Local Interface Tuple or the IR_local_iface_addr of any
Removed Interface Address Tuple. Removed Interface Address Tuple.
o NL_neighbor_iface_addr MUST NOT equal the NL_neighbor_iface_addr o NL_neighbor_iface_addr MUST NOT equal the NL_neighbor_iface_addr
of any other Lost Neighbor Tuple. of any other Lost Neighbor Tuple.
o NL_neighbor_iface_addr MUST NOT be in the o NL_neighbor_iface_addr MUST NOT be in the
N_neighbor_iface_addr_list of any Neighbor Tuple with N_symmetric N_neighbor_iface_addr_list of any Neighbor Tuple with N_symmetric
== true. = true.
In each 2-Hop Tuple: In each 2-Hop Tuple:
o There MUST be a Link Tuple associated with the same MANET o There MUST be a Link Tuple associated with the same MANET
interface with: interface with:
* L_neighbor_iface_addr_list == N2_neighbor_iface_addr_list; AND * L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
* L_status == SYMMETRIC. * L_status = SYMMETRIC.
o N2_2hop_iface_addr MUST NOT be in the I_local_iface_addr_list of o N2_2hop_iface_addr MUST NOT be in the I_local_iface_addr_list of
any Local Interface Tuple or the IR_local_iface_addr of any any Local Interface Tuple or the IR_local_iface_addr of any
Removed Interface Address Tuple. Removed Interface Address Tuple.
o N2_2hop_iface_addr MUST NOT be the N2_2hop_iface_addr of any other o N2_2hop_iface_addr MUST NOT be the N2_2hop_iface_addr of any other
2-Hop Tuple in the same 2-Hop Set and with the same 2-Hop Tuple in the same 2-Hop Set and with the same
N2_neighbor_iface_addr_list. N2_neighbor_iface_addr_list.
o N2_2hop_iface_addr MUST NOT be in the N2_neighbor_iface_addr_list o N2_2hop_iface_addr MUST NOT be in the N2_neighbor_iface_addr_list
of the same 2-Hop Tuple. of the same 2-Hop Tuple.
Appendix D. Flow and Congestion Control Appendix C. HELLO Message Example
This protocol specifies one message type, the HELLO message. The
maximum size of a HELLO message is proportional to the size of the
originating node's 1-hop neighborhood. HELLO messages MUST NOT be
forwarded.
A node 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 node in the
network employing this protocol.
A node MUST ensure that two successive HELLO messages sent on the An example HELLO message, transmitted by an originator router with a
same MANET interface are separated by at least HELLO_MIN_INTERVAL. single MANET interface, is as follows.
(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 node in the network
employing this protocol.
Appendix E. Contributors The message has full Message Header (four bit flags field value is
15). Its four bit Message Address Length field has value 3 and hence
addresses in the message have length 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 49 octets.
This specification is the result of the joint efforts of the The message contains a Message TLV Block with content length 8 octets
following contributors, listed alphabetically. containing two Message TLVs, of types VALIDITY_TIME and
INTERVAL_TIME. Each uses a Message TLV with flags octet value 16,
indicating that each has a value. Each has a value length of 1
octet; the values included (0x64 and 0x58) are time codes
representing the default values of parameters H_HOLD_TIME and
HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the
default value of constant C (1/1024 second).
o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil> The message has a single Address Block containing 5 addresses. The
flags octet 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).
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> The following Address Block TLV Block (content length 14 octets)
includes two Address Block TLVs. The first is a LOCAL_IF Address
Block TLV which (with flags octet value 80) indicates that a single
address, with index 0 (i.e. Head:Mid 0) is the single local
interface address of this router (the 1 octet value THIS_IF indicates
that this address is of this interface). The second is a LINK_STATUS
Address Block TLV which (with flags octet value 48) specifies the
link status values of all reported neighbors in a single multivalue
Address Block TLV which covers the addresses with indexes 1 to 4.
The Address Block TLV value length of 4 octets indicates one octet
per value per address. The last four addresses have associated link
status, the first and second HEARD, the third SYMMETRIC, and the
fourth LOST.
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org> 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 |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 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| INTERVAL_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 0 | Mid 1 | Mid 2 | Mid 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS |0 0 1 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST |
+-+-+-+-+-+-+-+-+
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil> 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:
o Christopher Dearlove, BAE Systems, UK, 0 1 2 3
<Chris.Dearlove@baesystems.com> 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 |
+-+-+-+-+-+-+-+-+
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> Appendix D. Flow and Congestion Control
Appendix F. Acknowledgements 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.
The authors would like to acknowledge the team behind OLSRv1, A router MUST report its 1-hop neighborhood in HELLO messages on each
specified in RFC3626 for their contributions. 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.
The authors would like to gratefully acknowledge the following people A router MUST ensure that two successive HELLO messages sent on the
for intense technical discussions, early reviews and comments on the same MANET interface are separated by at least HELLO_MIN_INTERVAL.
specification and its components (listed alphabetically): Alan Cullen (If using jitter then this may be reduced to a mean minimum value of
(BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound
Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA), on the control traffic generated by each router in the network
and the entire IETF MANET working group. employing this protocol.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
Christopher Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems ATC
Phone: +44 1245 242194 Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Justin W. Dean Justin W. Dean
Naval Research Laboratory Naval Research Laboratory
Phone: +1 202 767 3397 Phone: +1 202 767 3397
EMail: jdean@itd.nrl.navy.mil EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/ URI: http://pf.itd.nrl.navy.mil/
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 401 change blocks. 
924 lines changed or deleted 1290 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/