Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove
Expires: December 1, 2007 BAE Systems Advanced Technology
Centre
J. Dean
Naval Research Laboratory
The OLSRv2 Design Team
MANET Working Group
May 30, 2007
MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Clausen, et al. Expires December 1, 2007 [Page 1]
Internet-Draft MANET-NHDP May 2007
Abstract
This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8
4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 8
4.2. Information Base Overview . . . . . . . . . . . . . . . . 9
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 10
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 10
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 11
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 12
5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 12
5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 12
5.1.2. Information Validity Times . . . . . . . . . . . . . . 13
5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 14
5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Information Validity Time . . . . . . . . . . . . . . 15
5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 15
5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 17
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 17
7. Interface Information Base . . . . . . . . . . . . . . . . . . 18
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Node Information Base . . . . . . . . . . . . . . . . . . . . 20
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 20
9. Local Information Base Changes . . . . . . . . . . . . . . . . 21
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 21
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 21
9.3. Adding an Address to an Interface . . . . . . . . . . . . 22
9.4. Removing an Address from an Interface . . . . . . . . . . 22
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 23
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 23
10.1.1. Local Interface Block . . . . . . . . . . . . . . . . 23
10.1.2. Neighbor Address Blocks . . . . . . . . . . . . . . . 24
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 26
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 26
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 27
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 27
Clausen, et al. Expires December 1, 2007 [Page 2]
Internet-Draft MANET-NHDP May 2007
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 29
12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 29
12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 31
12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 31
12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 32
13. Other Information Base Changes . . . . . . . . . . . . . . . . 34
13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 34
13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 35
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 36
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 37
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 37
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 38
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 39
15. Proposed Values for Parameters and Constants . . . . . . . . . 40
15.1. Message Interval Interface Parameters . . . . . . . . . . 40
15.2. Information Validity Time Interface Parameters . . . . . . 40
15.3. Information Validity Time Node Parameters . . . . . . . . 40
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 40
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 40
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 40
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
16.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 41
16.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 41
16.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 41
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
17.1. Normative References . . . . . . . . . . . . . . . . . . . 43
17.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 44
Appendix B. HELLO Message Example . . . . . . . . . . . . . . . 45
Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . 47
Appendix D. Security Considerations . . . . . . . . . . . . . . 49
Appendix D.1. Invalid HELLO messages . . . . . . . . . . . . . . . 49
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 51
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 52
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 55
Clausen, et al. Expires December 1, 2007 [Page 3]
Internet-Draft MANET-NHDP May 2007
1. Introduction
This document describes a neighborhood discovery protocol (NHDP) for
a mobile ad hoc network (MANET) [7]. This protocol uses an exchange
of HELLO messages in order that each node can determine the presence
and status of its 1-hop and symmetric 2-hop neighbors. This protocol
is designed to maintain this information in the presence of a dynamic
network topology.
The information maintained by this protocol may be used by other
protocols, such as MANET routing protocols, for determining local
connectivity and node configuration.
This specification describes both the HELLO message exchange, the
messages being defined as instances of the specification [1], and the
information storage required for neighborhood discovery.
This protocol makes no assumptions about the underlying link layer,
other than support of link local multicast. Link layer information
may be used if available and applicable.
This protocol is based on the neighborhood discovery process
contained in the Optimized Link State Routing Protocol (OLSR) [6].
Clausen, et al. Expires December 1, 2007 [Page 4]
Internet-Draft MANET-NHDP May 2007
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5].
The terms "packet", "message", "address", "address block", "TLV", and
"TLV block" in this document are to be interpreted as described in
[1].
Additionally, this document uses the following terminology:
Node - A MANET router which implements this neighborhood discovery
protocol.
Interface - A network device, configured and assigned one or more IP
addresses.
MANET interface - An interface participating in a MANET and using
this neighborhood discovery protocol. A node may have several
MANET interfaces.
Heard - A MANET interface of node X is considered heard on a MANET
interface of a node Y if the latter can receive traffic from the
former.
Link - A pair of MANET interfaces from two different nodes, where at
least one interface is heard by the other.
Symmetric link - A link where both MANET interfaces are heard by the
other.
1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a MANET
interface of node X is heard by a MANET interface of node Y.
Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of
a node Y if a symmetric link exists between a MANET interface on
node X and a MANET interface on node Y.
Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of
a node Y if node X is a symmetric 1-hop neighbor of a symmetric
1-hop neighbor of node Y, but is not node Y itself.
1-hop neighborhood - The 1-hop neighborhood of a node X is the set
of the 1-hop neighbors of node X.
Clausen, et al. Expires December 1, 2007 [Page 5]
Internet-Draft MANET-NHDP May 2007
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.
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.
(This may include nodes in the 1-hop neighborhood, or even in the
symmetric 1-hop neighborhood, of node X.)
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.
Interface parameter - An interface parameter is a boolean or
numerical value, specified separately for each MANET interface of
each node. A node MAY change interface parameter values at any
time, subject to some constraints.
Node parameter - A node parameter is a boolean or numerical value,
specified for each node. A node MAY change node parameter values
at any time, subject to some constraints.
Clausen, et al. Expires December 1, 2007 [Page 6]
Internet-Draft MANET-NHDP May 2007
3. Applicability Statement
This neighborhood discovery protocol supports nodes which each have
one or more interfaces participating in the MANET [7]. It provides
each node with local topology information up to two hops away. This
information is made available to other protocols through Interface
Information Bases and a Node Information Base, described in Section 7
and Section 8.
The protocol is designed to work in networks with a dynamic topology,
and where messages may be lost, such as due to collisions in wireless
networks. If relevant link layer information is available then it
may be used by this protocol.
This protocol is designed to work in a completely distributed manner,
and does not depend on any central entity. It does not require any
changes to the format of IP packets, thus any existing IP protocol
stack can be used as is. It can use the link local multicast address
and MANET UDP port specified in [2].
This protocol uses the packet and message formats specified in [1].
HELLO messages specified by this protocol may be extended using the
TLV mechanisms described in [1]. For example, if multipoint relays
(MPRs) are to be calculated similarly to as in OLSR [6] and signaled
to neighbors, then this information may be added to HELLO messages
using an address block TLV. HELLO messages can also be transmitted
in packets with messages from other protocols that also use [1].
Clausen, et al. Expires December 1, 2007 [Page 7]
Internet-Draft MANET-NHDP May 2007
4. Protocol Overview and Functioning
This protocol specifies local (one hop) signaling that:
o Advertises the presence of a node and its interfaces.
o Discovers links from adjacent nodes.
o Performs bidirectionality checks on the discovered links.
o Advertises discovered links, and whether each is symmetric, to its
1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
o Maintains information bases describing discovered links, their
MANET interface addresses and status, current and former 1-hop
neighbors, and symmetric 2-hop neighbors.
4.1. Nodes and Interfaces
In order for a node to participate in a MANET, it MUST have at least
one, possibly more, MANET interfaces. Each MANET interface:
o Is characterized by a set of interface parameters, defining the
behavior of this interface. Each MANET interface MAY be
individually parameterized to accommodate the characteristics
experienced and the behavior desired on that interface.
o Has an Interface Information Base, recording information regarding
links to this MANET interface and symmetric 2-hop neighbors which
can be reached through such links. Each MANET interface has its
own Interface Information Base.
o Generates and processes HELLO messages, according to the interface
parameters for that interface.
In addition to a set of MANET interfaces as described above, each
node has:
o A Local Information Base, containing the IP addresses of the
interfaces of this node.
o A Node Information Base, recording information regarding current
and recently lost symmetric 1-hop neighbors of this node.
A node may have both MANET interfaces and non-MANET interfaces.
Interfaces of both of these types are recorded in a node's Local
Information Base, which is used, but not updated, by the signaling of
this protocol.
Clausen, et al. Expires December 1, 2007 [Page 8]
Internet-Draft MANET-NHDP May 2007
4.2. Information Base Overview
Each node maintains a Local Information Base, which contains:
o The Local Interface Set, which consists of Local Interface Tuples,
each of which records the addresses of an interface of the node.
Each node maintains, for each of its MANET interfaces, an Interface
Information Base, which contains:
o A Link Set, which consists of Link Tuples, each of which records
information about a current or recently lost link from a MANET
interface of a 1-hop neighbor to this MANET interface. A Link
Tuple for a lost link is maintained for purposes of advertisement
in HELLO messages and hence accelerated removal of this link from
the relevant 1-hop neighbors' Link Sets. Link quality
information, if used and available, may be recorded in a Link
Tuple; if this indicates that a link is of too low quality to be
currently useable, then that link is also treated as lost.
o A 2-Hop Set, which consists of 2-Hop Tuples, each of which records
a MANET interface of a symmetric 1-hop neighbor, and an address of
a symmetric 2-hop neighbor of this node. The former MANET
interface must have a symmetric link to this interface, and the
former node must be a symmetric 1-hop neighbor of the latter node.
The 2-Hop Set is updated by the signaling of this protocol, but is
not itself reported in that signaling.
Each node maintains a Node Information Base, which contains:
o The Neighbor Set, which consists of Neighbor Tuples, each of which
records all interface addresses of a 1-hop neighbor. There MUST
be a current link from a MANET interface of this 1-hop neighbor to
a MANET interface of this node, although this link MAY be
currently considered as lost due to insufficient link quality.
Neighbor Tuples are maintained in the Neighbor Set as long as
there are corresponding current Link Tuples in the Link Set. A
Neighbor Tuple allows all addresses of all interfaces of a 1-hop
neighbors to be associated with each other, including addresses of
interfaces not represented in the Link Set. Neighbor Tuples allow
all addresses of interfaces of symmetric 1-hop neighbors to be
included in HELLO messages on all MANET interfaces of this node.
o The Lost Neighbor Set, which consists of Lost Neighbor Tuples,
each of which records an address of an interface of a recently
lost symmetric 1-hop neighbor. Lost Neighbor Tuples allow
advertising such addresses as lost, in order that these addresses
can be removed from other nodes' 2-Hop Sets.
Clausen, et al. Expires December 1, 2007 [Page 9]
Internet-Draft MANET-NHDP May 2007
These sets are used for describing the protocol in this document. An
implementation of this protocol MAY maintain this information in the
indicated form, or in any other organization which offers access to
this information.
This protocol contains a signaling mechanism for maintaining the
Interface Information Bases and the Node Information Base. If
information from the link layer, or any other source, is available
and appropriate, it may be used to update these. Such updates are
subject to the constraints specified in Appendix C.
Some links in a MANET may be marginal, e.g. due to adverse wireless
propagation. In order to avoid using such marginal links, a link
quality is associated with each link in the Link Set, and links with
insufficient link quality are considered lost. Modifying the link
quality of a link is OPTIONAL. If link quality is not to be modified
it MUST be set to indicate an always usable quality link. Link
quality information is only used locally, it is not used in
signaling, and nodes may interoperate whether they are using the
same, different, or no, link quality information.
4.3. Signaling Overview
Signaling consists of a single type of message, known as a HELLO
message. Each node generates HELLO messages for each of its MANET
interfaces. Each HELLO message identifies that MANET interface, and
reports the other interfaces of the node. Each HELLO message
includes information from the Link Set of the Interface Information
Base of the MANET interface, and from the Node Information Base of
the node.
4.3.1. HELLO Message Generation
HELLO messages are generated by a node for each of its MANET
interfaces, and MAY be sent:
o Proactively, at a regular interval, known as HELLO_INTERVAL.
HELLO_INTERVAL may be fixed, or may be dynamic. For example
HELLO_INTERVAL may be backed off due to congestion or network
stability.
o As a response to a change in the node itself, or its 1-hop
neighborhood, for example on first becoming active or in response
to a new, broken, or changed status link.
o In a combination of these proactive and responsive mechanisms.
Jittering of HELLO message generation and transmission, as described
Clausen, et al. Expires December 1, 2007 [Page 10]
Internet-Draft MANET-NHDP May 2007
in Section 11.2, MAY be used if appropriate.
HELLO messages are generated independently on each MANET interface of
a node. HELLO messages MAY be scheduled independently for each MANET
interface, or, interface parameters permitting, using the same
schedule for all MANET interfaces of a node.
4.3.2. HELLO Message Content
Each HELLO message sent over a MANET interface need not contain all
of the information appropriate to that MANET interface, however:
o A HELLO message MUST contain all of the addresses in the Local
Interface Set of the node to which the MANET interface belongs.
o Within every time interval of length REFRESH_INTERVAL, the HELLO
messages sent on each MANET interface of a node must collectively
include:
* All of the information in the Link Set of the Interface
Information Base of that MANET interface (other than link
quality and information relating to pending links).
* All of the information in the Node Information Base of that
node.
This applies to otherwise purely responsive nodes as well as
proactive nodes. In either case it means that all information
appropriate to that MANET interface will have always been
transmitted, in one or more HELLO messages, since the time
REFRESH_INTERVAL ago.
o A HELLO message MUST include a VALIDITY_TIME message TLV that
indicates the length of time for which the message content is to
be considered valid, and included in the receiving node's
Interface Information Base.
o A periodically generated HELLO message SHOULD include an
INTERVAL_TIME message TLV that indicates the current value of
HELLO_INTERVAL for that MANET interface, i.e. the period within
which a further HELLO message is guaranteed to be sent on that
MANET interface.
Clausen, et al. Expires December 1, 2007 [Page 11]
Internet-Draft MANET-NHDP May 2007
5. Protocol Parameters and Constants
The parameters and constants used in this specification are described
in this section.
5.1. Interface Parameters
The interface parameters used by this specification may be classified
into the following four categories:
o Message intervals
o Information validity times
o Link quality
o Jitter
These are detailed in the following sections.
Different MANET interfaces (on the same or on different nodes) MAY
employ different interface parameter values, and may change their
interface parameter values dynamically, subject to the constraints
given in this section. A particular case is where all MANET
interfaces on all MANET nodes within a given MANET employ the same
set of interface parameter values.
5.1.1. Message Intervals
The following interface parameters regulate HELLO message
transmissions over a given MANET interface.
HELLO messages serve two principal functions:
o To advertise this nodes own addresses to its 1-hop neighbors. The
frequency of these advertisements is regulated by the interface
parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.
o To advertise this nodes knowledge of each of its 1-hop neighbors.
The frequency of the advertisement of each such neighbor is
regulated by the interface parameter REFRESH_INTERVAL.
Specifically, these parameters are as follows:
HELLO_INTERVAL - is the maximum time between the transmission of two
successive HELLO messages on this MANET interface. If using
periodic transmission of HELLO messages, these SHOULD be at a
separation of HELLO_INTERVAL, possibly modified by jitter as
Clausen, et al. Expires December 1, 2007 [Page 12]
Internet-Draft MANET-NHDP May 2007
specified in [4].
HELLO_MIN_INTERVAL - is the minimum interval between transmission of
two successive HELLO messages, on this MANET interface. (This
minimum interval MAY be modified by jitter, as defined in [4].)
REFRESH_INTERVAL - is the maximum interval between advertisements 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
1-hop neighbor information which it is specified as sending in at
least one HELLO message on this MANET interface.
The following constraints apply to these interface parameters:
o HELLO_INTERVAL > 0
o HELLO_MIN_INTERVAL >= 0
o HELLO_INTERVAL >= HELLO_MIN_INTERVAL
o REFRESH_INTERVAL >= HELLO_INTERVAL
o If INTERVAL_TIME TLVs as defined in [3] are included in HELLO
messages, then HELLO_INTERVAL MUST be representable as described
in [3].
If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its
neighbor advertisements between HELLO messages in any manner, subject
to the constraints above.
For a node to employ this protocol in a purely responsive manner on a
MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be
set to a value such that a responsive HELLO message is always
expected in a shorter period than this.
5.1.2. Information Validity Times
The following interface parameters manage the validity time of link
information:
L_HOLD_TIME - is the period of advertisement, on this MANET
interface, of former 1-hop neighbor addresses as lost in HELLO
messages, allowing recipients of these HELLO messages to
accelerate removal of information from their Link Sets.
L_HOLD_TIME can be set to zero if accelerated information removal
is not required.
Clausen, et al. Expires December 1, 2007 [Page 13]
Internet-Draft MANET-NHDP May 2007
H_HOLD_TIME - is used as the value in the VALIDITY_TIME TLV included
in all HELLO messages on this MANET interface.
The following constraints apply to these interface parameters:
o L_HOLD_TIME >= 0
o H_HOLD_TIME >= REFRESH_INTERVAL
o If HELLO messages can be lost then both SHOULD be significantly
greater than REFRESH_INTERVAL.
o H_HOLD_TIME MUST be representable as described in [3].
5.1.3. Link Quality
The following interface parameters manage the usage of link quality:
HYST_ACCEPT - is the link quality threshold at or above which a link
becomes usable, if it was not already so.
HYST_REJECT - is the link quality threshold below which a link
becomes unusable, if it was not already so.
INITIAL_QUALITY - is the initial quality of a newly identified link.
INITIAL_PENDING - if true, then a newly identified link is
considered pending, and is not usable until the link quality has
reached or exceeded the HYST_ACCEPT threshold.
The following constraints apply to these interface parameters:
o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1
o 0 <= INITIAL_QUALITY <= 1.
o If link quality is not updated, then INITIAL_QUALITY >=
HYST_ACCEPT.
o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING == false.
o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING == true.
5.1.4. Jitter
If jitter, as defined in [4], is used then these parameters are as
follows:
Clausen, et al. Expires December 1, 2007 [Page 14]
Internet-Draft MANET-NHDP May 2007
HP_MAXJITTER - represents the value of MAXJITTER used in [4] for
periodically generated HELLO messages on this MANET interface.
HT_MAXJITTER - represents the value of MAXJITTER used in [4] for
externally triggered HELLO messages on this MANET interface.
For constraints on these interface parameters see [4].
5.2. Node Parameters
Only one node parameter is defined by this specification, in the
category of information validity time.
5.2.1. Information Validity Time
The following node parameter manages the validity time of lost
symmetric 1-hop neighbor information:
N_HOLD_TIME - is used as the period during which former 1-hop
neighbor addresses are advertised as lost in HELLO messages,
allowing recipients of these HELLO messages to accelerate removal
of information from their 2-Hop Sets. N_HOLD_TIME can be set to
zero if accelerated information removal is not required.
The following constraint applies to this node parameter:
o N_HOLD_TIME >= 0
5.3. Parameter Change Constraints
This section presents guidelines, applicable if protocol parameters
are changed dynamically.
HELLO_INTERVAL
* If the HELLO_INTERVAL for a MANET interface increases, then the
next HELLO message on this MANET interface MUST be generated
according to the previous, shorter, HELLO_INTERVAL. Additional
subsequent HELLO messages MAY be generated according to the
previous, shorter, HELLO_INTERVAL.
* If the HELLO_INTERVAL for a MANET interface decreases, then the
following HELLO messages on this MANET interface SHOULD be
generated according to this current, shorter, HELLO_INTERVAL.
Clausen, et al. Expires December 1, 2007 [Page 15]
Internet-Draft MANET-NHDP May 2007
REFRESH_INTERVAL
* If the REFRESH_INTERVAL for a MANET interface increases, then
the content of subsequent HELLO messages must be organized such
that the specification of the old value of REFRESH_INTERVAL is
satisfied for a further period equal to the old value of
REFRESH_INTERVAL.
* If the REFRESH_INTERVAL for a MANET interface decreases, then
it MAY be necessary to reschedule HELLO message generation on
that MANET interface, in order that the specification of
REFRESH_INTERVAL is satisfied from the time of change.
HYST_ACCEPT and HYST_REJECT
* If HYST_ACCEPT or HYST_REJECT changes, then the appropriate
actions for link quality change, as specified in Section 14.3
MUST be taken.
L_HOLD_TIME
* If L_HOLD_TIME changes, then L_time for all relevant Link
Tuples SHOULD be changed.
N_HOLD_TIME
* If N_HOLD_TIME changes, then NL_time for all relevant Lost
Neighbor Tuples SHOULD be changed.
HP_MAXJITTER
* If HP_MAXJITTER changes, then the periodic HELLO message
schedule on this MANET interface MAY be changed.
HT_MAXJITTER
* If HT_MAXJITTER changes, then externally triggered HELLO
messages on this MANET interface MAY be rescheduled.
5.4. Constants
The constant C is used as specified in [3].
Clausen, et al. Expires December 1, 2007 [Page 16]
Internet-Draft MANET-NHDP May 2007
6. Local Information Base
A node maintains a Local Information Base that records information
about its local interfaces (MANET interfaces or otherwise). Each
such interface MUST have at least one address, and MAY have more than
one address. All addresses have an associated prefix length, which
is included with all addresses in the Local Information Base. If an
address otherwise does not have a prefix length then it is considered
to be equal to the address length. Two addresses are considered
equal if and only if their associated prefix lengths are also equal.
The Local Information Base is not modified by this protocol. This
protocol MAY respond to changes of this Local Information Base which
MUST reflect corresponding changes in the node's interface
configuration.
6.1. Local Interface Set
A node's Local Interface Set records its local interfaces. It
consists of Local Interface Tuples, one per interface:
(I_local_iface_addr_list, I_manet)
where:
I_local_iface_addr_list is a list of the addresses of this
interface.
I_manet is a boolean flag, describing if this interface is a MANET
interface.
Clausen, et al. Expires December 1, 2007 [Page 17]
Internet-Draft MANET-NHDP May 2007
7. Interface Information Base
A node maintains an Interface Information Base for each of its MANET
interfaces. This records information about links to that MANET
interface and symmetric 2-hop neighbors which can be reached in two
hops using those links as the first hop. The Interface Information
Base includes the Link Set and the 2-Hop Set.
A MANET interface address can be present in both the Link Set and as
of a symmetric 2-hop neighbor. This allows the node with this MANET
interface address to be immediately considered as a symmetric 2-hop
neighbor if it fails to be a symmetric 1-hop neighbor.
All addresses MUST have an associated prefix length, which is
included in all addresses in the Interface Information Base. Prefix
lengths are indicated in HELLO messages using the PREFIX_LENGTH TLV
specified in [1]; if an address has no such TLV, then its prefix
length is equal to the address length. Two addresses are considered
equal if and only if their associated prefix lengths are also equal.
7.1. Link Set
A node's Link Set records links from other nodes which are, or
recently were, 1-hop neighbors. It consists of Link Tuples, each
representing a single link:
(L_neighbor_iface_addr_list, L_HEARD_time,
L_SYM_time, L_quality, L_pending, L_lost, L_time)
where:
L_neighbor_iface_addr_list is a list of the addresses of the MANET
interface of the 1-hop neighbor;
L_HEARD_time is the time until which the MANET interface of the
1-hop neighbor would be considered heard if not considering link
quality;
L_SYM_time is the time until which the link to the 1-hop neighbor
would be considered symmetric if not considering link quality;
L_quality is a dimensionless number between 0 (inclusive) and 1
(inclusive) describing the quality of a link; a greater value of
L_quality indicating a higher quality link;
Clausen, et al. Expires December 1, 2007 [Page 18]
Internet-Draft MANET-NHDP May 2007
L_pending is a boolean flag, describing if a link is considered
pending (i.e. a candidate, but not yet established, link);
L_lost is a boolean flag, describing if a link is considered lost
due to link quality;
L_time specifies when this Tuple expires and MUST be removed.
The status of the link, as obtained through HELLO message exchange,
and also taking link quality into account, denoted L_status, is
defined by:
1. If L_pending is true, then L_status = PENDING;
2. otherwise, if L_lost is true, then L_status = LOST;
3. otherwise, if L_SYM_time is not expired, then L_status =
SYMMETRIC;
4. otherwise, if L_HEARD_time is not expired, then L_status = HEARD;
5. otherwise, L_status = LOST.
7.2. 2-Hop Set
A node's 2-Hop Set records symmetric 2-hop neighbors, and the
symmetric links to symmetric 1-hop neighbors through which the
symmetric 2-hop neighbors can be reached. It consists of 2-Hop
Tuples, each representing a single interface address of a symmetric
2-hop neighbor, and a single MANET interface of a symmetric 1-hop
neighbor.
(N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)
where:
N2_neighbor_iface_addr_list is a list of the addresses of the MANET
interface of the symmetric 1-hop neighbor from which this
information was received;
N2_2hop_iface_addr is an address of an interface of a symmetric
2-hop neighbor which has a symmetric link (using any MANET
interface) to the indicated symmetric 1-hop neighbor;
N2_time specifies when this Tuple expires and MUST be removed.
Clausen, et al. Expires December 1, 2007 [Page 19]
Internet-Draft MANET-NHDP May 2007
8. Node Information Base
Each node maintains a Node Information Base that records information
about addresses of current and recently symmetric 1-hop neighbors.
All addresses MUST have an associated prefix length, which is
included in all addresses in the Node Information Base. Prefix
lengths are indicated in HELLO messages using the PREFIX_LENGTH TLV
specified in [1]; if an address has no such TLV, then its prefix
length is equal to the address length. Two addresses are considered
equal if and only if their associated prefix lengths are also equal.
8.1. Neighbor Set
A node's Neighbor Set records all interface addresses of each 1-hop
neighbor. It consists of Neighbor Tuples, each representing a single
1-hop neighbor:
(N_neighbor_iface_addr_list, N_symmetric)
where:
N_neighbor_iface_addr_list is a list of the interface addresses of a
1-hop neighbor;
N_symmetric is a boolean flag, describing if this is a symmetric
1-hop neighbor.
8.2. Lost Neighbor Set
A node's Lost Neighbor Set records addresses of all interfaces of
nodes which recently were symmetric 1-hop neighbors, but are now
advertised as lost. It consists of Lost Neighbor Tuples, each
representing a single such address:
(NL_neighbor_iface_addr, NL_time)
where:
NL_neighbor_iface_addr is an address of an interface of a node which
recently was a symmetric 1-hop neighbor of this node;
NL_time specifies when this Tuple expires and MUST be removed.
Clausen, et al. Expires December 1, 2007 [Page 20]
Internet-Draft MANET-NHDP May 2007
9. Local Information Base Changes
The Local Information Base MUST change to respond to changes in the
node's interfaces. The node MUST update its Interface and Node
Information Bases in response to such changes. If any changes in the
Interface and Node Information Bases satisfy any of the conditions
described in Section 13, then those changes must be applied
immediately, unless noted otherwise.
A node MAY transmit HELLO messages in response to these changes.
9.1. Adding an Interface
If an interface is added to the node then this is indicated by the
addition of a Local Interface Tuple to the Local Interface Set. If
the new interface is a MANET interface then an initially empty
Interface Information Base MUST be created for this new MANET
interface. The actions in Section 9.3 MUST be taken for each address
of the 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
interface. If using scheduled messages, then a message schedule MUST
be established on a new MANET interface.
9.2. Removing an Interface
If a MANET interface is removed from the node, then this MUST result
in removal of information from the Local Information Base and the
Neighborhood Information Base as follows:
1. Remove the Local Interface Tuple that corresponds to the
interface to be removed from the Local Interface Set.
2. If the interface to be removed is a MANET interface (i.e. with
I_manet == true) then:
1. Remove the Interface Information Base for that MANET
interface;
2. All Neighbor Tuples for which none of the addresses in its
N_neighbor_iface_addr_list are found in any
L_neighbor_iface_addr_list in any remaining Link Set, are
removed.
If a node removes the Local Interface Tuple that contains the
interface address that is used to define the node's originator
address, as defined in [1], then the node MAY change originator
address.
Clausen, et al. Expires December 1, 2007 [Page 21]
Internet-Draft MANET-NHDP May 2007
If the removed interface is the last MANET interface of the node,
then there will be no remaining Interface Information Bases, and the
node will longer participate in this protocol.
A HELLO message MAY be sent on all remaining MANET interfaces.
9.3. Adding an Address to an Interface
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.
The following changes MUST be made to the Information Bases:
1. The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list
contains the added address, are removed.
2. Any Link Tuples, in any Link Set, whose
L_neighbor_iface_addr_list contains:
* the added address; OR
* any address in the N_neighbor_iface_addr_list of the removed
Neighbor Tuples, if any
are removed; apply Section 13.1, but not Section 13.3.
3. Any Lost Neighbor Tuples whose NL_neighb_iface_addr is the added
address, are removed.
4. Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address,
are removed.
A HELLO message MAY be sent on all MANET interfaces.
9.4. Removing an Address from an Interface
If an address is removed from an interface then this is indicated by
the removal of an address from the appropriate
I_local_iface_addr_list. If this list is now empty then the
corresponding Local Interface Tuple MUST be removed.
If a node removes the interface address that is used to define the
node's originator address, as defined in [1], then the node MAY
change originator address.
A HELLO message MAY be sent on all MANET interfaces.
Clausen, et al. Expires December 1, 2007 [Page 22]
Internet-Draft MANET-NHDP May 2007
10. Packets and Messages
The packet and message format used by this protocol is defined in
[1], which is used with the following considerations:
o This protocol specifies one message type, the HELLO message.
o HELLO message header options MAY be used as specified by a
protocol which uses this neighborhood discovery protocol.
o HELLO messages MUST NOT be forwarded.
o HELLO messages MAY be included in multi-message packets as
specified in [1].
o Packet header options MAY be used as specified by a protocol which
uses this neighborhood discovery protocol.
10.1. HELLO Messages
A HELLO message MUST contain:
o A VALIDITY_TIME message TLV as specified in [3], representing
H_HOLD_TIME for the transmitting MANET interface.
o An address block, with an associated TLV block, known as the Local
Interface Block, as specified in Section 10.1.1.
A HELLO message which is transmitted periodically SHOULD contain, and
otherwise MAY contain:
o An INTERVAL_TIME message TLV as specified in [3], representing
HELLO_INTERVAL for the transmitting MANET interface.
A HELLO message MAY contain:
o One or more address blocks, each with an associated TLV block,
known as Neighbor Address Blocks, as specified in Section 10.1.2.
o Other message TLVs.
10.1.1. Local Interface Block
The first address block, plus following TLV block, in a HELLO message
is known as the Local Interface Block. The Local Interface Block is
not distinguished in any way other than by being the first address
block in the HELLO message.
Clausen, et al. Expires December 1, 2007 [Page 23]
Internet-Draft MANET-NHDP May 2007
The Local Interface Block MUST contain all of the addresses in that
node's Local Interface Set. Those addresses, if any, which correspond
to interfaces other than the MANET interface for which the HELLO
message is transmitted MUST be associated with a corresponding TLV
with Type == OTHER_IF as specified in Table 1. Addresses of the
MANET interface on which the HELLO message is transmitted MUST NOT be
associated with such a TLV.
Note that a Local Interface Block MAY include more than one address
for each MANET interface, and hence a HELLO message MAY contain more
than one address without an OTHER_IF TLV.
+--------------+-----------------+----------------------------------+
| Name | Value Length | Description |
+--------------+-----------------+----------------------------------+
| OTHER_IF | 0 bits | Specifies that the address, in |
| | | the Local Interface Block of the |
| | | message, is an address |
| | | associated with an interface |
| | | other than the MANET interface |
| | | on which the message is |
| | | transmitted |
+--------------+-----------------+----------------------------------+
Table 1
10.1.2. Neighbor Address Blocks
Address blocks, each with a following TLV block, in a HELLO message,
after the Local Interface Block, are known as Neighbor Address
Blocks. These Neighbor Address Blocks are not distinguished in any
way other than by not being the first address block in the HELLO
message. A HELLO message MAY contain no Neighbor Address Blocks.
A Neighbor Address Block contains current or recently lost 1-hop
neighbors' interface addresses, each of which is associated with
address block TLVs as described in Table 2. Other addresses MAY be
included in Neighbor Address Blocks, but MUST NOT be associated with
any of the TLVs specified in Table 2.
Clausen, et al. Expires December 1, 2007 [Page 24]
Internet-Draft MANET-NHDP May 2007
+--------------+-----------------+----------------------------------+
| Name | Value Length | Description |
+--------------+-----------------+----------------------------------+
| LINK_STATUS | 8 bits | Specifies the status of the link |
| | | from the indicated address |
| | | (LOST, SYMMETRIC or HEARD) |
| | | |
| OTHER_NEIGHB | 8 bits | Specifies that the address is |
| | | (SYMMETRIC) or was (LOST) of an |
| | | interface of a symmetric 1-hop |
| | | neighbor of the node |
| | | transmitting the HELLO message |
+--------------+-----------------+----------------------------------+
Table 2
A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value ==
LOST) also performs the function of a TLV with Type == OTHER_IF and
the same value. The latter SHOULD NOT also be included. If a TLV
with Type == LINK_STATUS and Value == SYMMETRIC is combined with a
TLV with Type == OTHER_IF and Value == LOST then the latter MUST be
ignored, and SHOULD NOT be included. See Appendix A.
Clausen, et al. Expires December 1, 2007 [Page 25]
Internet-Draft MANET-NHDP May 2007
11. HELLO Message Generation
Each MANET interface MUST generate HELLO messages according to the
specification in this section. HELLO message generation and
scheduling MUST be according to the interface parameters for that
MANET interface and MAY be independent for each MANET interface or,
interface parameters permitting, MANET interfaces MAY use the same
schedule.
If transmitting periodic HELLO messages then, following a HELLO
message transmission on a MANET interface, another HELLO message MUST
be transmitted on the same MANET interface after an interval not
greater than HELLO_INTERVAL. Two successive HELLO message
transmissions on the same MANET interface MUST be separated by at
least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.
11.1. HELLO Message Specification
HELLO messages are generated independently on each MANET interface.
A HELLO message MUST include a Local Interface Block, as specified in
Section 10.1.1, as its first address block.
Other addresses which MUST be included in Neighbor Address Blocks, as
specified in Section 10.1.2, in HELLO messages sent over a given
MANET interface are:
o Addresses of MANET interfaces of 1-hop neighbors from the Link Set
of the Interface Information Base for this MANET interface.
o Other addresses of symmetric 1-hop neighbors from the Neighbor Set
of this node's Node Information Base.
o Addresses of MANET interfaces of previously symmetric or heard
1-hop neighbors connected on this MANET interface from the Link
Set of the Interface Information Base for this MANET interface.
(These are advertised for a period equal to this interface's
L_HOLD_TIME after loss.)
o Other addresses of previously symmetric 1-hop neighbors from the
Lost Neighbor Set of this node's Node Information Base. (These
are advertised for a period equal to N_HOLD_TIME after loss.)
The addresses, and their associated TLVs, which may be included in
any HELLO message sent on this MANET interface (respecting
REFRESH_INTERVAL for this MANET interface) are:
Clausen, et al. Expires December 1, 2007 [Page 26]
Internet-Draft MANET-NHDP May 2007
1. For each address (henceforth linked address) which appears in a
Link Tuple in the Link Set for this MANET interface, for which
L_status does not equal PENDING, include the linked address with
an associated TLV with:
* Type = LINK_STATUS; AND
* Value = L_status.
2. For each address (henceforth neighbor address) which appears in
an N_neighbor_iface_addr_list in a Neighbor Tuple with
N_symmetric == true, and which has not already been included with
an associated TLV with (Type == LINK_STATUS and Value ==
SYMMETRIC), include the neighbor address with an associated TLV
with:
* Type = OTHER_NEIGHB; AND
* Value = SYMMETRIC.
3. For each Lost Neighbor Tuple whose NL_neighbor_iface_addr
(henceforth lost address) has not already been included, include
the lost address with an associated TLV with:
* Type = OTHER_NEIGHB; AND
* Value = LOST.
If an address is specified with more than one associated TLV, then
these TLVs MAY be independently included or excluded from each HELLO
message. Each such TLV MUST be included associated with that address
in a HELLO message sent on that MANET interface in every interval of
length equal to that MANET interface's parameter REFRESH_INTERVAL.
TLVs associated with the same address included in the same HELLO
message MAY be applied to the same or different copies of that
address.
11.2. HELLO Message Transmission
HELLO messages are transmitted in the packet/message format specified
by [1] using the "LL MANET Routers" multicast address specified by
[2] as destination IP address, using the MANET UDP port specified in
[2].
11.2.1. HELLO Message Jitter
HELLO messages MAY be sent using periodic message generation or
externally triggered message generation. If using data link and
Clausen, et al. Expires December 1, 2007 [Page 27]
Internet-Draft MANET-NHDP May 2007
physical layers which are subject to packet loss due to collisions,
HELLO messages SHOULD be jittered as described in [4].
Internally triggered message generation (such as due to a change in
local interfaces) MAY be treated as if externally generated message
generation, or MAY be not jittered.
HELLO messages MUST NOT be forwarded, and thus message forwarding
jitter does not apply to HELLO messages.
Each form of jitter described in [4] requires a parameter MAXJITTER.
These interface parameters may be dynamic, and are specified by:
o For periodic message generation: HP_MAXJITTER, which MUST be
significantly less than HELLO_INTERVAL.
o For externally triggered message generation: HT_MAXJITTER. If
HELLO messages are also periodically generated, then HT_MAXJITTER
also MUST be significantly less than HELLO_INTERVAL.
When HELLO message generation is delayed in order that a HELLO
message is not sent within HELLO_MIN_INTERVAL of the previous HELLO
message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
be reduced by jitter, with maximum reduction HP_MAXJITTER. In this
case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL.
Clausen, et al. Expires December 1, 2007 [Page 28]
Internet-Draft MANET-NHDP May 2007
12. HELLO Message Processing
On receiving a HELLO message, a node MUST first check if any address
in its Local Interface Block is one of its interface addresses (i.e.
is in any I_local_iface_addr_list in the Local Interface Set). If so
then the HELLO message MUST be discarded.
Otherwise the receiving node MUST update its appropriate Interface
Information Base and its Node Information Base according to this
section. If any changes satisfy any of the conditions described in
Section 13 then the indicated consequences MUST be applied
immediately, unless noted otherwise.
For the purpose of this section, note the following definitions:
o "validity time" is calculated from the VALIDITY_TIME TLV of the
HELLO message as specified in [3].
o "Receiving Address List" is the I_local_iface_addr_list
corresponding to the MANET interface on which the HELLO message
was received
o "Neighbor Address List" is the list of the addresses contained in
the Local Interface Block of the HELLO message.
o "Sending Address List" is the list of the addresses contained in
the Local Interface Block of the HELLO message which do not have
an associated TLV with Type == OTHER_IF.
o EXPIRED indicates that a timer is set to a value clearly preceding
the current time (e.g. current time - 1).
o "Removed Address List" is a list of addresses created by this
HELLO message processing which were formerly reported as local by
the node originating the HELLO message, but which are not included
in the Neighbor Address List. This list is initialized as empty.
o "Lost Address List" is a subset of the Removed Address List
containing addresses which were formerly considered as symmetric.
This list is initialized as empty.
12.1. Updating the Neighbor Set
On receiving a HELLO message, the node MUST update its Neighbor Set
and populate the Removed Address List and Lost Address List:
1. Find all Neighbor Tuples (hereafter matching Neighbor Tuples)
where:
Clausen, et al. Expires December 1, 2007 [Page 29]
Internet-Draft MANET-NHDP May 2007
* N_neighbor_iface_addr_list contains at least one address in
the Neighbor Address List.
2. If there are no matching Neighbor Tuples, then:
1. Create a new Neighbor Tuple with:
+ N_neighbor_iface_addr_list = Neighbor Address List;
+ N_symmetric = false.
3. If there is one matching Neighbor Tuple, then:
1. If the N_neighbor_iface_addr_list of the matching Neighbor
Tuple is not equal to the Neighbor Address List, then:
1. For each address (henceforth removed address) which is in
the N_neighbor_iface_addr_list, but not in the Neighbor
Address List:
1. Add the removed address to the Removed Address List.
2. If N_symmetric == true, then add the removed address
to the Lost Address List.
2. Update the matching Neighbor Tuple by:
- N_neighbor_iface_addr_list = Neighbor Address List.
4. If there are two or more matching Neighbor Tuples, then:
1. For each address (henceforth removed address) which is in the
N_neighbor_iface_addr_list of any of the matching Neighbor
Tuples:
1. Add the removed address to the Removed Address List.
2. If N_symmetric == true, then add the removed address to
the Lost Address List.
2. Replace the matching Neighbor Tuples by a single Neighbor
Tuple with:
+ N_neighbor_iface_addr_list = Neighbor Address List;
+ N_symmetric = false
Clausen, et al. Expires December 1, 2007 [Page 30]
Internet-Draft MANET-NHDP May 2007
12.2. Updating the Lost Neighbor Set
On receiving a HELLO message, a node MUST update its Lost Neighbor
Set:
1. For each address (henceforth lost address) in the Lost Neighbor
List, if no 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_time = current time + N_HOLD_TIME.
12.3. Updating the Link Set
On receiving a HELLO message, a node MUST update its Link Set for the
MANET interface on which the HELLO message is received:
1. Remove all addresses in the Removed Address List from the
L_neighbor_iface_addr_list of all Link Tuples.
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now
empty; apply Section 13.1, but not Section 13.3.
3. Find all Link Tuples (hereafter matching Link Tuples) where:
* L_neighbor_iface_addr_list contains one or more addresses in
the Sending Address List.
4. If there is more than one matching Link Tuple, then remove them
all; apply Section 13.1, but not Section 13.3.
5. If no matching Link Tuples remain, then create a new matching
Link Tuple with:
* L_neighbor_iface_addr_list = empty;
* L_HEARD_time = EXPIRED;
* L_SYM_time = EXPIRED;
* L_quality = INITIAL_QUALITY;
* L_pending = INITIAL_PENDING;
* L_lost = false;
Clausen, et al. Expires December 1, 2007 [Page 31]
Internet-Draft MANET-NHDP May 2007
* L_time = current time + validity time.
6. The matching Link Tuple, existing or new, is then modified as
follows:
1. If the MANET interface finds any address (henceforth
receiving address) in the Receiving Address List in a
Neighbor Address Block in the HELLO message, then the Link
Tuple is modified as follows:
1. If any receiving address in the HELLO message is
associated with a TLV with Type == LINK_STATUS and (Value
== HEARD or Value == SYMMETRIC) then:
- L_SYM_time = current time + validity time.
2. Otherwise if any receiving address in the HELLO message
is associated with a TLV with Type == LINK_STATUS and
Value == LOST then:
1. if L_SYM_time has not expired, then:
1. L_SYM_time = EXPIRED.
2. if L_status == HEARD or SYMMETRIC, then:
* L_time = current time + L_HOLD_TIME.
2. L_neighbor_iface_addr_list = Sending Address List.
3. L_HEARD_time = max(current time + validity time, L_SYM_time).
4. If L_status == PENDING, then:
+ L_time = max(L_time, L_HEARD_time).
5. Otherwise if L_status == HEARD or SYMMETRIC, then:
+ L_time = max(L_time, L_HEARD_time + L_HOLD_TIME).
12.4. Updating the 2-Hop Set
On receiving a HELLO message a node MUST update its 2-Hop Set for the
MANET interface on which the HELLO message was received:
1. Remove all addresses in the Removed Address List from the
N2_neighbor_iface_addr_list of all 2-Hop Tuples.
Clausen, et al. Expires December 1, 2007 [Page 32]
Internet-Draft MANET-NHDP May 2007
2. If the Link Tuple with L_neighbor_iface_addr_list == Sending
Address List has L_STATUS == SYMMETRIC then:
1. For each address (henceforth 2-hop address) in a Neighbor
Address Block of the HELLO message, which is not in the
Neighbor Address List or in any I_local_iface_addr_list:
1. If the 2-hop address has an associated 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:
- N2_neighbor_iface_addr_list contains one or more
addresses in the Sending Address List; AND
- N2_2hop_iface_addr == 2-hop address.
then create a 2-Hop Neighbor Tuple with:
- N2_2hop_iface_addr = 2-hop address.
This 2-Hop Tuple (existing or new) is then modified as
follows:
- N2_neighbor_iface_addr_list = Sending Address List;
- N2_time = current time + validity time.
2. Otherwise if the 2-hop address has a TLV with:
- Type == LINK_STATUS and (Value == LOST or Value ==
HEARD); OR
- Type == OTHER_NEIGHB and Value == LOST;
then remove all 2-Hop Tuples with:
- N2_neighbor_iface_addr_list contains one or more
addresses in the Sending Address List; AND
- N2_2hop_iface_addr == 2-hop address.
Clausen, et al. Expires December 1, 2007 [Page 33]
Internet-Draft MANET-NHDP May 2007
13. Other Information Base Changes
The Interface and Node Information Bases MUST be changed when some
events occur. These events may result from HELLO message processing,
or may be otherwise generated (e.g. expiry of timers or link quality
changes).
Events which cause changes in the Information Bases are:
o A Link Tuple's state changes from symmetric, or the Link Tuple is
removed.
o A Link Tuple's state changes to symmetric.
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 Link quality changes, as specified in Section 14.
A node MAY report updated information in response to any of these
changes in HELLO message(s), subject to the constraints in
Section 11.
A node which transmits HELLO messages in response to such changes
SHOULD transmit a HELLO message:
o On all MANET interfaces, if the Neighbor Set changes such as to
indicate the change in symmetry of any 1-hop neighbors (including
addition or removal of symmetric 1-hop neighbors).
o Otherwise, on all those MANET interfaces whose Link Set changes
such as to indicate a change in status of any 1-hop neighbors
(including the addition or removal of any 1-hop neighbors, other
than those considered pending).
13.1. Link Tuple Not Symmetric
If for any Link Tuple with L_status == SYMMETRIC:
o L_status changes to any other value; OR
o the Link Tuple is removed;
then:
1. All 2-Hop Tuples for the same MANET interface with:
Clausen, et al. Expires December 1, 2007 [Page 34]
Internet-Draft MANET-NHDP May 2007
* N2_neighbor_iface_addr_list contains one or more addresses in
L_neighbor_iface_addr_list;
are removed.
2. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list:
1. If there are no remaining Link Tuples for any MANET interface
with:
+ L_neighbor_iface_addr_list contained in
N_neighbor_iface_addr_list; AND
+ L_status == SYMMETRIC;
then modify the Neighbor Tuple by:
1. N_symmetric = false.
2. For each address (henceforth neighbor address) in
N_neighbor_iface_addr_list, add a Lost Neighbor Tuple
with:
- 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 LN_neighbor_iface_addr is
included in that N_neighbor_iface_addr_list.
Clausen, et al. Expires December 1, 2007 [Page 35]
Internet-Draft MANET-NHDP May 2007
13.3. Link Tuple Heard Timeout
If, for any Link Tuple:
o L_HEARD_time expires; OR
o the Link Tuple is removed;
then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list, if no Link Tuples for any MANET
interface remain with:
* L_neighbor_iface_addr_list contained in
N_neighbor_iface_addr_list;
* L_HEARD_time is not expired;
then remove the Neighbor Tuple.
Clausen, et al. Expires December 1, 2007 [Page 36]
Internet-Draft MANET-NHDP May 2007
14. Link Quality
Link quality is a mechanism whereby a node MAY take considerations
other than message exchange into account for determining when a link
is and is not a candidate for being considered as HEARD or SYMMETRIC.
For deployments where no link quality is used, the considerations in
Section 14.1 apply. For deployments were link quality is used, the
general principles of link quality usage are described in
Section 14.2. Section 14.3 and Section 14.4 detail link quality
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
In order for a node to not employ link quality, the node MUST define:
o INITIAL_PENDING = false;
o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define
INITIAL_QUALITY = 1).
14.2. Basic Principles of Link Quality
To enable link quality usage, the L_quality value of a Link Tuple is
used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT,
to set the flags L_pending and L_lost of that Link Tuple. Based on
these flags, the link status to advertise for that Link Tuple is
determined as described in Section 7.1.
The use of two thresholds implements link hysteresis, whereby a link
which has HYST_REJECT <= L_quality < HYST_ACCEPT may be either
accepted or rejected (depending on which threshold it has most
recently crossed, or if neither the value of INITIAL_QUALITY). With
appropriate values of these parameters, this prevents over-rapid
changes of link status.
The basic principles of link quality usage are as follows:
o A node does not advertise a neighbor interface in any state until
L_quality is acceptable:
* If INITIAL_PENDING == true, then this is such that L_quality >=
HYST_ACCEPT.
Clausen, et al. Expires December 1, 2007 [Page 37]
Internet-Draft MANET-NHDP May 2007
* Otherwise this is such that L_quality >= HYST_REJECT. To
ensure this, a node MUST NOT define INITIAL_PENDING == false
and INITIAL_QUALITY < HYST_REJECT. (A node also MUST NOT
define INITIAL_PENDING == true and INITIAL_QUALITY >=
HYST_ACCEPT.)
* A link which is not yet advertised has L_pending == true.
o Once L_quality >= HYST_ACCEPT, the L_pending flag is set false,
indicating that the link can be advertised.
o A link for which L_pending == false is advertised until its
L_quality drops below HYST_REJECT.
o If a link has L_pending == false and L_quality < HYST_REJECT, the
link is LOST and is advertised as such. This link is not
reconsidered as a candidate HEARD or SYMMETRIC link until
L_quality >= HYST_ACCEPT.
o A link which has an acceptable quality may be advertised as HEARD,
SYMMETRIC or LOST according to the exchange of HELLO messages.
14.3. When Link Quality Changes
If L_quality for a link changes, then the following actions MUST be
taken:
1. If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is
modified by:
1. L_pending = false.
2. L_lost = false.
3. If L_status == HEARD or L_status == SYMMETRIC, then:
+ 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
then the corresponding Link Tuple is modified by:
1. If L_lost == false, then:
+ L_lost = true
+ L_time = min(L_time, current time + L_HOLD_TIME)
Any appropriate action indicted in Section 13 MUST also be taken.
Clausen, et al. Expires December 1, 2007 [Page 38]
Internet-Draft MANET-NHDP May 2007
If L_quality for a link is updated based on HELLO message reception,
or on reception of a packet including a HELLO message, then L_quality
MUST be updated prior to the HELLO message processing described in
Section 12. (If the receipt of the HELLO message, or the packet
containing it, creates the Link Tuple then instead the Link Tuple
MUST be created with the updated, from INITIAL_QUALITY, L_quality
value.)
14.4. Updating Link Quality
A node MAY update link quality based on any information available to
it. Particular cases that MAY be used include:
o Information from the link layer, such as signal to noise ratio.
o Receipt or loss of packets. If packets include a packet sequence
number as defined in [1], then packets on a link SHOULD have
sequential packet sequence numbers, whether or not they include
HELLO messages. Link quality can be updated when a packet is
received based on, for example, whether the last N out of M
packets on the link were received, or a "leaky integrator"
tracking packets.
o Receipt or loss of HELLO messages. If the maximum interval
between HELLO messages is known (such as by inclusion of a message
TLV with Type == INTERVAL_TIME, as defined in [3], in HELLO
messages) then the loss of HELLO messages can be determined
without the need to receive a HELLO message. Note that if this
case is combined with the previous case then care must be taken to
avoid "double counting" a lost HELLO message in a lost packet.
Clausen, et al. Expires December 1, 2007 [Page 39]
Internet-Draft MANET-NHDP May 2007
15. Proposed Values for Parameters and Constants
This section lists the parameters and constants used in the
specification of the protocol, and proposed values of each which may
be used when a single value of each is used.
15.1. Message Interval Interface Parameters
o HELLO_INTERVAL = 2 seconds
o HELLO_MIN_INTERVAL = HELLO_INTERVAL/4
o REFRESH_INTERVAL = HELLO_INTERVAL
15.2. Information Validity Time Interface Parameters
o H_HOLD_TIME = 3 x REFRESH_INTERVAL
o L_HOLD_TIME = H_HOLD_TIME
15.3. Information Validity Time Node Parameters
o N_HOLD_TIME = L_HOLD_TIME
15.4. Link Quality Interface Parameters
If link quality is changed, then parameter values will depend on the
link quality process. If link quality is not changed, then:
o HYST_ACCEPT = 1
o HYST_REJECT = 0
o INITIAL_QUALITY = 1
o INITIAL_PENDING = false
15.5. Jitter Interface Parameters
o HP_MAXJITTER = HELLO_INTERVAL/4
o HT_MAXJITTER = HP_MAXJITTER
15.6. Constants
o C = 0.0625 second (1/16 second)
Clausen, et al. Expires December 1, 2007 [Page 40]
Internet-Draft MANET-NHDP May 2007
16. IANA Considerations
16.1. Message Types
This specification defines one message type, which must be allocated
from the "Assigned Message Types" repository of [1].
+--------------+------+--------------------------------------+
| Name | Type | Description |
+--------------+------+--------------------------------------+
| HELLO | TBD | Local signaling |
+--------------+------+--------------------------------------+
16.2. TLV Types
This specification defines three Address Block TLV types, which must
be allocated from the "Assigned Address Block TLV Types" repository
of [1].
+--------------+------+---------------------------------------------+
| Name | Type | Description |
+--------------+------+---------------------------------------------+
| OTHER_IF | TBD | Specifies that the address, in the Local |
| | | Interface Block, is an address associated |
| | | with an interface other than the MANET |
| | | interface on which the message is |
| | | transmitted |
| | | |
| LINK_STATUS | TBD | Specifies the status of the link from the |
| | | indicated address (LOST, SYMMETRIC or |
| | | HEARD) |
| | | |
| OTHER_NEIGHB | TBD | Specifies that the address is (SYMMETRIC) |
| | | or recently was (LOST) of an interface of a |
| | | symmetric 1-hop neighbor of the node |
| | | transmitting the message |
+--------------+------+---------------------------------------------+
16.3. LINK_STATUS and OTHER_NEIGHB Values
The values which the LINK_STATUS TLV can use are the following:
o LOST = 0
o SYMMETRIC = 1
o HEARD = 2
Clausen, et al. Expires December 1, 2007 [Page 41]
Internet-Draft MANET-NHDP May 2007
The values which the OTHER_NEIGHB TLV can use are the following:
o LOST = 0
o SYMMETRIC = 1
Clausen, et al. Expires December 1, 2007 [Page 42]
Internet-Draft MANET-NHDP May 2007
17. References
17.1. Normative References
[1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized
MANET Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-04.txt, January 2007.
[2] Chakeres, I., "Internet Assigned Numbers Authority (IANA)
Allocations for the Mobile Ad hoc Networks (MANET) Working
Group", Work In Progress draft-ietf-manet-iana-04.txt, May 2007.
[3] Clausen, T. and C. Dearlove, "Representing multi-value time in
MANETs", Work In Progress draft-ietf-manet-timetlv-00.txt,
April 2007.
[4] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", Work In
Progress draft-ietf-manet-jitter-00.txt, April 2007.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
17.2. Informative References
[6] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003.
[7] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET):
Routing Protocol Performance Issues and Evaluation
Considerations", RFC 2501, January 1999.
Clausen, et al. Expires December 1, 2007 [Page 43]
Internet-Draft MANET-NHDP May 2007
Appendix A. Address Block TLV Combinations
The algorithm for generating HELLO messages in Section 11 specifies
which addresses may be included in the address blocks after the Local
Interface Block, and with which associated TLVs. These TLVs may have
Type == LINK_STATUS or Type == OTHER_NEIGHB, or both. TLVs with Type
== LINK_STATUS may have three possible values (Value == HEARD, Value
== SYMMETRIC or Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may
have two possible values (Value == SYMMETRIC or Value == LOST). When
both TLVs are associated with the same address only certain
combinations of these TLV values are necessary, and are the only
combinations generated by the algorithm in Section 11. These
combinations are indicated in Table 5.
Cells labeled with "Yes" indicate the possible combinations which are
generated by the algorithm in Section 11. Cells labeled with "No"
indicate combinations not generated by the algorithm in Section 11,
but which are correctly parsed and interpreted by the algorithm in
Section 12.
+----------------+----------------+----------------+----------------+
| | Type == | Type == | Type == |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value == | Value == LOST |
| | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+
| Type == | No | Yes | Yes |
| LINK_STATUS | | | |
| (absent) | | | |
| | | | |
| Type == | Yes | Yes | Yes |
| LINK_STATUS, | | | |
| Value == HEARD | | | |
| | | | |
| Type == | Yes | No | No |
| LINK_STATUS, | | | |
| Value == | | | |
| SYMMETRIC | | | |
| | | | |
| Type == | Yes | Yes | No |
| LINK_STATUS, | | | |
| Value == LOST | | | |
+----------------+----------------+----------------+----------------+
Table 5
Clausen, et al. Expires December 1, 2007 [Page 44]
Internet-Draft MANET-NHDP May 2007
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 prefix TLVs. The message is transmitted
with a full message header (message semantics octet is 0) with a hop
limit of 1 and a hop count of 0. The overall message length is 50
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 semantics value 4, indicating
that no start and stop indexes are included, and each has a value
length of 1 octet. The values included (0x68 and 0x50) are time
codes representing the default values of parameters H_HOLD_TIME and
HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming a
default value of constant C (0.0625 second).
The first address block contains 1 local interface address. The
semantics octet value 2 indicates no address tail, and the head
length of 4 octets indicates no address mid sections. This address
block has no TLVs (TLV block content length 0 octets).
The second, and last, address block contains 4 neighbor interface
addresses. The semantics octet value 2 indicates no address tail,
the head length of 3 octets indicates address mid sections of one
octet each. The following TLV block (content length 7 octets)
includes one LINK_STATUS TLV which reports the link status values of
all reported neighbors in a single multivalue TLV: the first two
addresses are HEARD, the third address is SYMMETRIC and the fourth
address is LOST. The TLV semantics value of 20 indicates, in
addition to that this is a multivalue TLV, that no start and stop
indexes are included, since values for all addresses are included.
The TLV value length of 4 octets indicates one octet per value per
address.
Clausen, et al. Expires December 1, 2007 [Page 45]
Internet-Draft MANET-NHDP May 2007
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 1 1 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clausen, et al. Expires December 1, 2007 [Page 46]
Internet-Draft MANET-NHDP May 2007
Appendix C. Constraints
Any process which updates the Local Information Base or the
Neighborhood Information Base MUST ensure that all constraints
specified in this appendix are maintained.
In each Local Interface Tuple:
o I_local_iface_addr_list MUST NOT be empty.
o I_local_iface_addr_list MUST NOT contain any address which is in
the I_local_iface_addr_list of any other Local Interface Tuple.
In each Link Tuple:
o L_neighbor_iface_addr_list MUST NOT be empty.
o L_neighbor_iface_addr_list MUST NOT contain any address which is
in the I_local_iface_addr_list of any Local Interface Tuple.
o L_neighbor_iface_addr_list MUST NOT contain any address which is
in the L_neighbor_iface_addr_list of any other Link Tuple in the
same Link Set.
o If L_HEARD_time has not expired then there MUST be a Neighbor
Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list.
o L_HEARD_time MUST NOT be greater than L_time.
o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are
expired).
o L_quality MUST NOT be less than 0 or greater than 1.
o If L_quality >= HYST_ACCEPT then L_pending MUST be false.
o If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST.
o L_pending MUST NOT be set to true if it is currently false.
In each Neighbor Tuple:
o N_neighbor_iface_addr_list MUST NOT contain any address which is
in the I_local_iface_addr_list of any Local Interface Tuple.
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.
Clausen, et al. Expires December 1, 2007 [Page 47]
Internet-Draft MANET-NHDP May 2007
o If N_symmetric == true, then there MUST be one or more Link Tuples
with:
* L_neighbor_iface_addr_list contained in
N_neighbor_iface_addr_list; AND
* L_status == SYMMETRIC.
o If N_symmetric == false, then there MUST be one or more Link
Tuples with:
* L_neighbor_iface_addr_list contained in
N_neighbor_iface_addr_list.
All such Link Tuples MUST NOT have L_status == SYMMETRIC. At
least one such Link Tuple MUST have L_HEARD_time not expired.
In each Lost Neighbor Tuple:
o NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list
of any Local Interface Tuple.
o NL_neighbor_iface_addr MUST NOT equal the NL_neighbor_iface_addr
of any other Lost Neighbor Tuple.
o NL_neighbor_iface_addr MUST NOT be in the
N_neighbor_iface_addr_list of any Neighbor Tuple with N_symmetric
== true.
In each 2-Hop Tuple:
o There MUST be a Link Tuple associated with the same MANET
interface with:
* L_neighbor_iface_addr_list == N2_neighbor_iface_addr_list; AND
* L_status == SYMMETRIC.
o N2_2hop_iface_addr MUST NOT be in the I_local_iface_addr_list of
any Local Interface Tuple.
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
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.
Clausen, et al. Expires December 1, 2007 [Page 48]
Internet-Draft MANET-NHDP May 2007
Appendix D. Security Considerations
The objective of this protocol is to allow each node in the network
to acquire information describing its 1-hop and symmetric 2-hop
neighborhoods. This is acquired through message exchange between
neighboring nodes. The information is made available through a
collection of sets, describing the node's 1-hop neighborhood and
symmetric 2-hop neighborhood.
Under normal circumstances, the information recorded in these sets is
correct - i.e. corresponds to the actual network topology, apart from
any changes which have not (yet) been tracked by the HELLO message
exchanges.
If some node for some reason, malice or malfunction, injects invalid
HELLO messages, incorrect information may be recorded in the sets
maintained. The protocol specification does, however, prevent
inconsistent information from being injected in the protocol sets
through the constraints in Appendix C. The exact consequence of
information inexactness depends on the use of these sets, and should
be reflected in the specification of protocols which use information
provided by NHDP.
This appendix, therefore, only outlines the ways in which correctly
formed, but still invalid, HELLO messages may appear.
Appendix D.1. Invalid HELLO messages
A correctly formed, but still invalid, HELLO message may take any of
the following forms:
A node may provide false information about its own identity:
* The Local Interface Block of the HELLO message may contain
addresses which do not correspond to addresses of interfaces of
the node transmitting the HELLO message.
* The Local Interface Block of the HELLO message may omit
addresses of interfaces of the local node transmitting the
HELLO message.
* The Local Interface Block may contain additional OTHER_IF TLVs,
indicating incorrectly that an address is associated with an
interface other than that over which the HELLO message is
transmitted.
* The Local Interface Block may omit OTHER_IF TLVs, thereby
indicating incorrect addresses associated with the MANET
Clausen, et al. Expires December 1, 2007 [Page 49]
Internet-Draft MANET-NHDP May 2007
interface over which the HELLO message is transmitted.
A node may provide false information about the identity of other
nodes:
* A present or absent address in a Neighbor Block, does not in
and by itself cause a problem. It is the presence, absence, or
incorrectness of associated LINK_STATUS and OTHER_NEIGHB TLVs
that causes problems.
* A present LINK_STATUS TLV may, incorrectly, identify an address
as being of a MANET interface which is or was heard on the
MANET interface over which the HELLO message is transmitted.
* A consistently absent LINK_STATUS TLV may, incorrectly, fail to
identify an address as being of a MANET interface which is or
was heard on the MANET interface over which the HELLO message
is transmitted.
* A present OTHER_NEIGHB TLV may, incorrectly, identify an
address as being of a node which is or was in the sending
node's symmetric 1-hop neighborhood;
* A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail
to identify an address as being of a node which is or was in
the sending node's symmetric 1-hop neighborhood;
* The value of a LINK_STATUS TLV may incorrectly indicate the
status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop
neighbor.
* The value of an OTHER_NEIGHB TLV may incorrectly indicate the
status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.
Clausen, et al. Expires December 1, 2007 [Page 50]
Internet-Draft MANET-NHDP May 2007
Appendix E. Flow and Congestion Control
This protocol specifies one message type, the HELLO message. The
maximum size of a HELLO message is proportional to the size of the
originating 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
same MANET interface are separated by at least HELLO_MIN_INTERVAL.
(If using jitter then this may be reduced to a mean minimum value of
HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound
on the control traffic generated by each node in the network
employing this protocol.
Clausen, et al. Expires December 1, 2007 [Page 51]
Internet-Draft MANET-NHDP May 2007
Appendix F. Contributors
This specification is the result of the joint efforts of the
following contributors -- listed alphabetically.
o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, Hitachi Labs Europe, France,
<Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, PCRI, France, <T.Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK,
<Chris.Dearlove@baesystems.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
Clausen, et al. Expires December 1, 2007 [Page 52]
Internet-Draft MANET-NHDP May 2007
Appendix G. 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: Joe Macker (NRL), Alan Cullen (BAE
Systems), and the entire IETF MANET working group.
Clausen, et al. Expires December 1, 2007 [Page 53]
Internet-Draft MANET-NHDP May 2007
Authors' Addresses
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Christopher M. Dearlove
BAE Systems Advanced Technology Centre
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Justin W. Dean
Naval Research Laboratory
Phone: +1 202 767 3397
Email: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/
The OLSRv2 Design Team
MANET Working Group
Clausen, et al. Expires December 1, 2007 [Page 54]
Internet-Draft MANET-NHDP May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Clausen, et al. Expires December 1, 2007 [Page 55]
