draft-ietf-manet-nhdp-04.txt   draft-ietf-manet-nhdp-05.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, France
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: December 31, 2007 BAE Systems Advanced Technology Expires: June 8, 2008 BAE Systems Advanced Technology
Centre 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
June 29, 2007 December 6, 2007
MANET Neighborhood Discovery Protocol (NHDP) MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-04 draft-ietf-manet-nhdp-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 December 31, 2007. This Internet-Draft will expire on June 8, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8
4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 8 4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 9
4.2. Information Base Overview . . . . . . . . . . . . . . . . 9 4.2. Information Base Overview . . . . . . . . . . . . . . . . 9
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 9
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 10 4.2.2. Interface Information Bases . . . . . . . . . . . . . 10
4.2.3. Node Information Base . . . . . . . . . . . . . . . . 10
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 11
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 11
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 11 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 11
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 12 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 12
5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 12 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 12 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 14
5.1.2. Information Validity Times . . . . . . . . . . . . . . 13 5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 14
5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 14
5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. Information Validity Times . . . . . . . . . . . . . . 15
5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 15 5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Information Validity Time . . . . . . . . . . . . . . 15 5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 15 5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 17
5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Information Validity Time . . . . . . . . . . . . . . 17
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 17 5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 17
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 17 5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Interface Information Base . . . . . . . . . . . . . . . . . . 18 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 19
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 19
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 19
8. Node Information Base . . . . . . . . . . . . . . . . . . . . 20 7. Interface Information Base . . . . . . . . . . . . . . . . . . 21
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 20 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Local Information Base Changes . . . . . . . . . . . . . . . . 21 8. Node Information Base . . . . . . . . . . . . . . . . . . . . 23
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 21 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 21 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 23
9.3. Adding an Address to an Interface . . . . . . . . . . . . 22 9. Local Information Base Changes . . . . . . . . . . . . . . . . 24
9.4. Removing an Address from an Interface . . . . . . . . . . 22 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 24
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 23 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 24
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 23 9.3. Adding an Address to an Interface . . . . . . . . . . . . 25
10.1.1. Local Interface Block . . . . . . . . . . . . . . . . 24 9.4. Removing an Address from an Interface . . . . . . . . . . 25
10.1.2. Neighbor Address Blocks . . . . . . . . . . . . . . . 24 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 27
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 26 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 27
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 26 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 28
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 27 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 30
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 27 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 30
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 29 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 32
12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 29 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 32
12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 31 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 33
12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 31 12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 34
12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 32 12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 35
13. Other Information Base Changes . . . . . . . . . . . . . . . . 34 12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 35
13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 34 12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 37
13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 35 13. Other Information Base Changes . . . . . . . . . . . . . . . . 39
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 36 13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 39
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 40
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 37 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 41
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 37 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 38 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 42
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 39 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 42
15. Proposed Values for Parameters and Constants . . . . . . . . . 40 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 43
15.1. Message Interval Interface Parameters . . . . . . . . . . 40 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 44
15.2. Information Validity Time Interface Parameters . . . . . . 40 15. Proposed Values for Parameters and Constants . . . . . . . . . 45
15.3. Information Validity Time Node Parameters . . . . . . . . 40 15.1. Message Interval Interface Parameters . . . . . . . . . . 45
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 40 15.2. Information Validity Time Interface Parameters . . . . . . 45
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 40 15.3. Information Validity Time Node Parameters . . . . . . . . 45
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 40 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 45
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 45
16.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 41 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 46
16.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 41 16. Security Considerations . . . . . . . . . . . . . . . . . . . 47
16.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 42 16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 47
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
17.1. Normative References . . . . . . . . . . . . . . . . . . . 43 17.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 49
17.2. Informative References . . . . . . . . . . . . . . . . . . 43 17.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 49
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 44 17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 50
Appendix B. HELLO Message Example . . . . . . . . . . . . . . . 45 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . 47 18.1. Normative References . . . . . . . . . . . . . . . . . . . 51
Appendix D. Security Considerations . . . . . . . . . . . . . . 49 18.2. Informative References . . . . . . . . . . . . . . . . . . 51
Appendix D.1. Invalid HELLO messages . . . . . . . . . . . . . . . 49 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 52
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 51 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 53
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 52 Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 56
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 53 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 55 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . . . 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) [8]. This protocol uses an exchange a mobile ad hoc network (MANET) [8]. This protocol uses an exchange
of HELLO messages in order that each node can determine the presence 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 and status of its 1-hop and symmetric 2-hop neighbors.
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 This neighborhood information is recorded in the form of Information
protocols, such as MANET routing protocols, for determining local Bases. These may be used by other protocols, such as MANET routing
connectivity and node configuration. protocols, for determining local connectivity and node configuration.
This protocol is designed to maintain this information in the
presence of a dynamic network topology.
This specification describes both the HELLO message exchange, the This specification describes both the HELLO message exchange, the
messages being defined as instances of the specification [1], and the messages being defined as instances of the specification [1], and the
information storage required for neighborhood discovery. information storage required for neighborhood discovery.
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 multicast. Link layer information other than support of link local broadcast or multicast. Link layer
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) [7]. contained in the Optimized Link State Routing Protocol (OLSR) [7].
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5]. document are to be interpreted as described in RFC2119 [5].
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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 node. A node MAY change interface 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, Node parameter - A node parameter is a boolean or numerical value,
specified for each node. A node MAY change node parameter values specified for each node. A node MAY change node parameter values
at any time, subject to some constraints. at any time, subject to some constraints.
3. Applicability Statement 3. Applicability Statement
This neighborhood discovery protocol supports nodes which each have This protocol:
one or more interfaces participating in the MANET [8]. 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, o Is applicable to networks, especially wireless networks, in which
and where messages may be lost, such as due to collisions in wireless unknown neighbors (i.e. other nodes with which direct
networks. If relevant link layer information is available then it communication can be established) can be reached by local
may be used by this protocol. broadcast or multicast packets.
This protocol is designed to work in a completely distributed manner, o Is designed to work in networks with a dynamic topology, and in
and does not depend on any central entity. It does not require any which messages may be lost, such as due to collisions in wireless
changes to the format of IP packets, thus any existing IP protocol networks.
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]. o Supports nodes that each have one or more participating MANET
HELLO messages specified by this protocol may be extended using the interfaces. The set of a node's interfaces may change over time.
TLV mechanisms described in [1]. For example, if multipoint relays Each interface may have one or more interface addresses, and these
(MPRs) are to be calculated similarly to as in OLSR [7] and signaled may also be dynamically changing.
to neighbors, then this information may be added to HELLO messages
using an address block TLV. HELLO messages can also be transmitted o Does not require any changes to the format of IP datagrams, thus
in packets with messages from other protocols that also use [1]. any existing IP protocol stack can be used as is.
o Can use the link local multicast address and either the "manet"
UDP port or the "manet" IP protocol number specified in [2].
o Uses the packet and message formats specified in [1]. Such
packets may contain messages specified by this protocol as well as
other protocols.
o Specifies signaling using HELLO messages. The necessary contents
of these messages are defined in this specification, and may be
extended using the TLV mechanisms described in [1].
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
not depend on any central entity.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
This protocol specifies local (one hop) signaling that: The objective of this protocol is, for each node:
o To identify other nodes with which bidirectional links can be
established (symmetric 1-hop neighbors).
o To agree on the status of such links with the corresponding
symmetric 1-hop neighbor.
o To find the node's symmetric 2-hop neighbors.
o To record this information in Information Bases that can be used
by other protocols, of which this neighborhood discovery protocol
may be a part.
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 node and its interfaces.
o Discovers links from adjacent nodes. o Discovers links from adjacent nodes.
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.
o Maintains information bases describing discovered links, their This specification defines, in turn:
MANET interface addresses and status, current and former 1-hop
neighbors, and symmetric 2-hop neighbors. o Parameters and constants used by the protocol. Parameters used by
this protocol may be, where appropriate, specific to a MANET
interface. This protocol allows all parameters to be changed
dynamically.
o The Information Bases describing local interfaces, discovered
links and their status, current and former 1-hop neighbors, and
symmetric 2-hop neighbors.
o The format of the HELLO message that is used for local signaling.
o The generation of HELLO messages from some of the information in
the Information Bases.
o The updating of the Information Bases according to received HELLO
messages and other events.
4.1. Nodes and Interfaces 4.1. Nodes and Interfaces
In order for a node to participate in a MANET, it MUST have at least In order for a node to participate in a MANET, it MUST have at least
one, possibly more, MANET interfaces. Each MANET interface: 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 interface. Each MANET interface MAY be behavior of this MANET interface. Each MANET interface MAY be
individually parameterized to accommodate the characteristics individually parameterized.
experienced and the behavior desired on that interface.
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. Each MANET interface has its can be reached through such links.
own Interface Information Base.
o Generates and processes HELLO messages, according to the interface o Generates and processes HELLO messages, according to the interface
parameters for that 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: node has:
o A Local Information Base, containing the IP addresses of the o A Local Information Base, containing the addresses of the
interfaces of this node. interfaces (MANET and non-MANET) of this node. The contents of
this Information Base are not changed by signaling.
o A Node Information Base, recording information regarding current o A Node Information Base, recording information regarding current
and recently lost symmetric 1-hop neighbors of this node. and recently lost 1-hop neighbors of this node.
A node may have both MANET interfaces and non-MANET interfaces. A node 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 node'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
sections. These 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.
4.2.1. Local Information Base
Each node maintains a Local Information Base, which contains: Each node 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 of the node. each of which records the addresses of an interface (MANET or non-
MANET) of the node.
o The Removed Interface Address Set, which consists of Removed
Interface Address Tuples, each of which records a recently used
address of an interface (MANET or non-MANET) of the node.
4.2.2. Interface Information Bases
Each node maintains, for each of its MANET interfaces, an Interface Each node maintains, for each of its MANET interfaces, an Interface
Information Base, which contains: Information Base, which contains:
o A Link Set, which consists of Link Tuples, each of which records o A Link Set, which records information about current and recently
information about a current or recently lost link from a MANET lost links between this interface and MANET interfaces of 1-hop
interface of a 1-hop neighbor to this MANET interface. A Link neighbors. The Link Set consists of Link Tuples, each of which
Tuple for a lost link is maintained for purposes of advertisement contains information about a single link. Recently lost links are
in HELLO messages and hence accelerated removal of this link from recorded so that they can be advertised in HELLO messages,
the relevant 1-hop neighbors' Link Sets. Link quality accelerating their removal from relevant 1-hop neighbors' Link
information, if used and available, may be recorded in a Link Sets. Link quality information, if used and available, is
Tuple; if this indicates that a link is of too low quality to be recorded in Link Tuples and may indicate that links are treated as
currently useable, then that link is also treated as lost. lost.
o A 2-Hop Set, which consists of 2-Hop Tuples, each of which records o A 2-Hop Set, which records the existence of bidirectional links
a MANET interface of a symmetric 1-hop neighbor, and an address of between symmetric 1-hop neighbors of this MANET interface and
a symmetric 2-hop neighbor of this node. The former MANET other nodes (symmetric 2-hop neighbors). The 2-Hop Set consists
interface must have a symmetric link to this interface, and the of 2-Hop Tuples, each of which records an interface address of a
former node must be a symmetric 1-hop neighbor of the latter node. symmetric 2-hop neighbor, and all interface addresses of the
The 2-Hop Set is updated by the signaling of this protocol, but is corresponding symmetric 1-hop neighbor. The 2-Hop Set is updated
not itself reported in that signaling. by the signaling of this protocol, but is not itself reported in
that signaling.
4.2.3. Node Information Base
Each node maintains a Node Information Base, which contains: Each node maintains a Node Information Base, which contains:
o The Neighbor Set, which consists of Neighbor Tuples, each of which o The Neighbor Set, which records 1-hop neighbors, each of which
records all interface addresses of a 1-hop neighbor. There MUST must be currently heard, although this may be over a link with
be a current link from a MANET interface of this 1-hop neighbor to insufficient link quality. The Neighbor Set consists of Neighbor
a MANET interface of this node, although this link MAY be Tuples, each of which records all interface addresses (whether
currently considered as lost due to insufficient link quality. directly linked or not) of a single 1-hop neighbor. Neighbor
Neighbor Tuples are maintained in the Neighbor Set as long as Tuples are maintained as long as there are corresponding current
there are corresponding current Link Tuples in the Link Set. A Link Tuples.
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, o The Lost Neighbor Set, which records recently lost symmetric 1-hop
each of which records an address of an interface of a recently neighbors. The Lost Neighbor Set consists of Lost Neighbor
lost symmetric 1-hop neighbor. Lost Neighbor Tuples allow Tuples, each of which records an interface address of such a
advertising such addresses as lost, in order that these addresses neighbor. These are recorded so that they can be advertised in
can be removed from other nodes' 2-Hop Sets. HELLO messages, accelerating their removal from other nodes' 2-Hop
Sets.
These sets are used for describing the protocol in this document. An 4.3. Signaling Overview
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 This protocol contains a signaling mechanism for maintaining the
Interface Information Bases and the Node Information Base. If Interface Information Bases and the Node 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 be used to update these. Such updates are and appropriate, it may also be used to update these Information
subject to the constraints specified in Appendix C. Bases. 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 Signaling consists of a single type of message, known as a HELLO
message. Each node generates HELLO messages for each of its MANET message. Each node generates HELLO messages on each of its MANET
interfaces. Each HELLO message identifies that MANET interface, and interfaces. Each HELLO message identifies that MANET interface, and
reports the other interfaces of the node. Each HELLO message reports the other interfaces (MANET and non-MANET) of the node. Each
includes information from the Link Set of the Interface Information HELLO message includes information from the Link Set of the Interface
Base of the MANET interface, and from the Node Information Base of Information Base of the MANET interface, and from the Node
the node. Information Base.
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 node 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 node 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, MAY 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 are generated independently on each MANET interface of
a node. 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 node.
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 over a MANET interface need not contain all
of the information appropriate to that MANET interface, however: of 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 node to which the MANET interface belongs.
o Within every time interval of length REFRESH_INTERVAL, the HELLO o Within every time interval of length REFRESH_INTERVAL, the HELLO
messages sent on each MANET interface of a node must collectively messages sent on each MANET interface of a node MUST collectively
include: include:
* All of the information in the Link Set of the Interface * All of the relevant information in the Link Set of the
Information Base of that MANET interface (other than link Interface Information Base of that MANET interface.
quality and information relating to pending links).
* All of the information in the Node Information Base of that * All of the relevant information in the Node Information Base of
node. that node.
This applies to otherwise purely responsive nodes as well as This applies to otherwise purely responsive nodes as well as to
proactive nodes. In either case it means that all information proactive nodes. 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.
o A HELLO message MUST include a VALIDITY_TIME message TLV that o A HELLO message MUST include a VALIDITY_TIME message TLV that
indicates the length of time for which the message content is to indicates the length of time for which the message content is to
be considered valid, and included in the receiving node's be considered valid, and included in the receiving node's
Interface Information Base. 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 that indicates the current value of
HELLO_INTERVAL for that MANET interface, i.e. the period within HELLO_INTERVAL for that MANET interface, i.e. the period within
which a further HELLO message is guaranteed to be sent on that which a further HELLO message is guaranteed to be sent on that
MANET interface. MANET interface.
o Additional information may be added by a protocol using thsi
protocol using the TLV mechanisms described in [1]. For example,
if multipoint relays (MPRs) are to be calculated similarly to as
in OLSR [7] and signaled to neighbors, then this information may
be added to HELLO messages using an address block TLV.
4.3.3. HELLO Message Processing
All HELLO messages received by a node are used to update:
o The Interface Information Base for the MANET interface on which
that HELLO message is received.
o The Node Information Base.
Specifically:
o The node ensures that there is a single Neighbor Tuple
corresponding to the originator of that HELLO message.
o If a Link Tuple corresponding to the link on which that HELLO
message was received exists, then its duration is extended,
otherwise such a Link Tuple is created. If the HELLO message
indicates that the receiving MANET interface has been heard, then
the link is considered symmetric, or its duration as symmetric is
extended. If the HELLO message indicates that the receiving MANET
interface is lost, then the link is no longer considered
symmetric. In this case one or more Lost Neighbor Tuples may be
created.
o If the link on which the HELLO message is received is symmetric,
then any symmetrically advertised neighbors in the HELLO message
are added to the 2-Hop Set for the receiving interface, or if
already present, the durations of the corresponding 2-Hop Tuples
are extended.
In all cases the processing takes account of unexpected and erroneous
information in the HELLO message, maintaining the constraints
specified in Appendix C.
4.4. Link Quality
Some links in a MANET may be marginal, e.g. due to adverse wireless
propagation. In order to avoid using such marginal links, a link
quality 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.
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 12, line 39 skipping to change at page 14, line 39
interfaces on all MANET nodes within a given MANET employ the same interfaces on all MANET nodes 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 nodes own addresses to its 1-hop neighbors. The o To advertise this node's own addresses to its 1-hop neighbors.
frequency of these advertisements is regulated by the interface The frequency of these advertisements is regulated by the
parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL. interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.
o To advertise this nodes knowledge of each of its 1-hop neighbors. o To advertise this node's knowledge of each of its 1-hop neighbors.
The frequency of the advertisement of each such neighbor is The frequency of the advertisement of each such neighbor is
regulated by the interface parameter REFRESH_INTERVAL. 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 [4]. specified in [4].
skipping to change at page 13, line 26 skipping to change at page 15, line 26
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 TLVs as defined in [3] are included in HELLO o If INTERVAL_TIME message TLVs as defined in [3] are included in
messages, then HELLO_INTERVAL MUST be representable as described HELLO messages, then HELLO_INTERVAL MUST be representable as
in [3]. described in [3].
If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its
neighbor advertisements between HELLO messages in any manner, subject neighbor advertisements between HELLO messages in any manner, subject
to the constraints above. to the constraints above.
For a node to employ this protocol in a purely responsive manner on a For a node to employ this protocol in a purely responsive manner on a
MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be 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. expected in a shorter period than this.
skipping to change at page 14, line 5 skipping to change at page 16, line 5
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 information from their Link Sets.
L_HOLD_TIME can be set to zero if accelerated information removal L_HOLD_TIME can 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 TLV included H_HOLD_TIME - is used as the value in the VALIDITY_TIME message TLV
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 SHOULD be significantly
greater than REFRESH_INTERVAL. greater than REFRESH_INTERVAL.
skipping to change at page 15, line 15 skipping to change at page 17, line 15
HP_MAXJITTER - represents the value of MAXJITTER used in [4] for HP_MAXJITTER - represents the value of MAXJITTER used in [4] for
periodically generated HELLO messages on this MANET interface. periodically generated HELLO messages on this MANET interface.
HT_MAXJITTER - represents the value of MAXJITTER used in [4] for HT_MAXJITTER - represents the value of MAXJITTER used in [4] for
externally triggered HELLO messages on this MANET interface. externally triggered HELLO messages on this MANET interface.
For constraints on these interface parameters see [4]. For constraints on these interface parameters see [4].
5.2. Node Parameters 5.2. Node Parameters
Only one node parameter is defined by this specification, in the The two node 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 node 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 information from their 2-Hop Sets. N_HOLD_TIME can be set to
zero if accelerated information removal is not required. zero if accelerated information removal is not required.
The following constraint applies to this node parameter: I_HOLD_TIME - is the period for which a recently used local
interface address is recorded.
The following constraints applies to these node parameters:
o N_HOLD_TIME >= 0 o N_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.
HELLO_INTERVAL HELLO_INTERVAL
* If the HELLO_INTERVAL for a MANET interface increases, then the * If the HELLO_INTERVAL for a MANET interface increases, then the
next HELLO message on this MANET interface MUST be generated next HELLO message on this MANET interface MUST be generated
according to the previous, shorter, HELLO_INTERVAL. Additional according to the previous, shorter, HELLO_INTERVAL. Additional
subsequent HELLO messages MAY be generated according to the subsequent HELLO messages MAY be generated according to the
previous, shorter, HELLO_INTERVAL. previous, shorter, HELLO_INTERVAL.
* If the HELLO_INTERVAL for a MANET interface decreases, then the * If the HELLO_INTERVAL for a MANET interface decreases, then the
following HELLO messages on this MANET interface SHOULD be following HELLO messages on this MANET interface MUST be
generated according to this current, shorter, HELLO_INTERVAL. generated according to this current, shorter, HELLO_INTERVAL.
REFRESH_INTERVAL REFRESH_INTERVAL
* If the REFRESH_INTERVAL for a MANET interface increases, then * If the REFRESH_INTERVAL for a MANET interface increases, then
the content of subsequent HELLO messages must be organized such the content of subsequent HELLO messages must be organized such
that the specification of the old value of REFRESH_INTERVAL is that the specification of the old value of REFRESH_INTERVAL is
satisfied for a further period equal to the old value of satisfied for a further period equal to the old value of
REFRESH_INTERVAL. REFRESH_INTERVAL.
skipping to change at page 16, line 27 skipping to change at page 18, line 28
HYST_ACCEPT and HYST_REJECT HYST_ACCEPT and HYST_REJECT
* If HYST_ACCEPT or HYST_REJECT changes, then the appropriate * If HYST_ACCEPT or HYST_REJECT changes, then the appropriate
actions for link quality change, as specified in Section 14.3 actions for link quality change, as specified in Section 14.3
MUST be taken. MUST be taken.
L_HOLD_TIME L_HOLD_TIME
* If L_HOLD_TIME changes, then L_time for all relevant Link * If L_HOLD_TIME changes, then L_time for all relevant Link
Tuples SHOULD be changed. Tuples MUST be changed.
N_HOLD_TIME N_HOLD_TIME
* If N_HOLD_TIME changes, then NL_time for all relevant Lost * If N_HOLD_TIME changes, then NL_time for all relevant Lost
Neighbor Tuples SHOULD be changed. Neighbor Tuples MUST be changed.
HP_MAXJITTER HP_MAXJITTER
* If HP_MAXJITTER changes, then the periodic HELLO message * If HP_MAXJITTER changes, then the periodic HELLO message
schedule on this MANET interface MAY be changed. schedule on this MANET interface MAY be changed.
HT_MAXJITTER HT_MAXJITTER
* 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 is used as specified in [3]. The constant C is used as specified in [3].
6. Local Information Base 6. Local Information Base
A node maintains a Local Information Base that records information A node maintains a Local Information Base that records information
about its local interfaces (MANET interfaces or otherwise). Each about its interfaces (MANET and non-MANET). Each interface MUST have
such interface MUST have at least one address, and MAY have more than at least one address, and MAY have more than one address.
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 All addresses MUST have an associated prefix length. If an address
protocol MAY respond to changes of this Local Information Base which has no specified prefix length, 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.
The Local Information Base is not modified by signaling. This
protocol responds to changes to this Local Information Base which
MUST reflect corresponding changes in the node's interface MUST reflect corresponding changes in the node's interface
configuration. configuration.
6.1. Local Interface Set 6.1. Local Interface Set
A node's Local Interface Set records its local interfaces. It A node'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 a list of the addresses of this I_local_iface_addr_list is a list of the addresses of this
interface. 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.
6.2. Removed Interface Address Set
A node's Removed Interface Address Set records addresses which were
recently local interface addresses. If a node's interface addresses
are immutable then this set is always empty and MAY be omitted. It
consists of Removed Interface Address Tuples, one per address:
(IR_local_iface_addr, IR_time)
where:
IR_local_iface_addr is a recently used address of an interface of
this node.
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 node maintains an Interface Information Base for each of its MANET
interfaces. This records information about links to that 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 in both the Link Set and as 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 of a symmetric 2-hop neighbor. This allows the node with this MANET
interface address to be immediately considered as a symmetric 2-hop interface address to be immediately considered as a symmetric 2-hop
neighbor if it fails to be a symmetric 1-hop neighbor. neighbor if it fails to be a symmetric 1-hop neighbor.
All addresses MUST have an associated prefix length, which is All addresses MUST have an associated prefix length. Prefix lengths
included in all addresses in the Interface Information Base. Prefix are indicated in HELLO messages as specified in [1]; if an address
lengths are indicated in HELLO messages using the PREFIX_LENGTH TLV has no specified prefix length, then its prefix length is equal to
specified in [1]; if an address has no such TLV, then its prefix the address length. Two addresses are considered equal if and only
length is equal to the address length. Two addresses are considered if their associated prefix lengths are also equal.
equal if and only if their associated prefix lengths are also equal.
7.1. Link Set 7.1. Link Set
A node's Link Set records links from other nodes which are, or A node's Link Set records links from other nodes 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_neighbor_iface_addr_list, L_HEARD_time,
L_SYM_time, L_quality, L_pending, L_lost, L_time) L_SYM_time, L_quality, L_pending, L_lost, L_time)
skipping to change at page 20, line 10 skipping to change at page 23, line 10
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. Node Information Base
Each node maintains a Node Information Base that records information Each node maintains a Node Information Base that records information
about addresses of current and recently symmetric 1-hop neighbors. about addresses of current and recently symmetric 1-hop neighbors.
All addresses MUST have an associated prefix length, which is All addresses MUST have an associated prefix length. Prefix lengths
included in all addresses in the Node Information Base. Prefix are indicated in HELLO messages as specified in [1]; if an address
lengths are indicated in HELLO messages using the PREFIX_LENGTH TLV has no specified prefix length, then its prefix length is equal to
specified in [1]; if an address has no such TLV, then its prefix the address length. Two addresses are considered equal if and only
length is equal to the address length. Two addresses are considered if their associated prefix lengths are also equal.
equal if and only if their associated prefix lengths are also equal.
8.1. Neighbor Set 8.1. Neighbor Set
A node's Neighbor Set records all interface addresses of each 1-hop A node'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:
skipping to change at page 21, line 8 skipping to change at page 24, line 8
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 node which
recently was a symmetric 1-hop neighbor of this node; recently was a symmetric 1-hop neighbor of this node;
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 interfaces. The node MUST update its Interface and Node node's local interface configuration. The node MUST update its
Information Bases in response to such changes. If any changes in the Interface and Node Information Bases in response to such changes. If
Interface and Node Information Bases satisfy any of the conditions any changes in the Interface and Node Information Bases satisfy any
described in Section 13, then those changes must be applied of the conditions described in Section 13, then those changes must be
immediately, unless noted otherwise. applied immediately, unless noted otherwise.
A node MAY transmit HELLO messages in response to these changes. A node 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 node 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 the 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 a MANET interface is removed from the node, then this MUST result If an interface is removed from the node, then this MUST result in
in removal of information from the Local Information Base and the changes to the Local Information Base and the Node Information Base
Neighborhood Information Base as follows: as follows:
1. Remove the Local Interface Tuple that corresponds to the 1. Identify the Local Interface Tuple that corresponds to the
interface to be removed from the Local Interface Set. interface to be removed.
2. If the interface to be removed is a MANET interface (i.e. with 2. For each address (henceforth removed address) in the
I_local_iface_addr_list of that Local Interface Tuple, create a
Removed Interface Address Tuple with:
* IR_local_iface_addr = removed address;
* IR_time = current time + I_HOLD_TIME.
3. Remove that Local Interface Tuple from the Local Interface Set.
4. If the interface to be removed is a MANET interface (i.e. with
I_manet == true) then: 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 found 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 node removes the Local Interface Tuple that contains the
interface address that is used to define the node's originator interface address that is used to define the node's originator
address, as defined in [1], then the node MAY change originator address, as defined in [1], then the node MAY change originator
address. address.
skipping to change at page 22, line 30 skipping to change at page 25, line 39
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 the removed
Neighbor Tuples, if any Neighbor Tuples, if any
are removed; apply Section 13.1, but not Section 13.3. are removed; apply Section 13.1, but not Section 13.3.
3. Any Lost Neighbor Tuples whose NL_neighb_iface_addr is the added 3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr is the
address, are removed. added 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 is the added address,
are removed. are removed.
A HELLO message MAY be sent on all MANET interfaces. A HELLO message 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 is removed from an interface then this is indicated by If an address (henceforth removed address) is removed from an
the removal of an address from the appropriate interface then this is indicated by the removal of that address from
I_local_iface_addr_list. If this list is now empty then the the appropriate I_local_iface_addr_list. If this list is now empty
corresponding Local Interface Tuple MUST be removed. then the corresponding Local Interface Tuple MUST be removed.
Create a Removed Interface Address Tuple with:
o IR_local_iface_addr = removed address;
o IR_time = current time + I_HOLD_TIME.
If a node removes the interface address that is used to define the 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 node's originator address, as defined in [1], then the node MAY
change originator address. change originator address.
A HELLO message MAY be sent on all MANET interfaces. A HELLO message 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
skipping to change at page 23, line 23 skipping to change at page 27, line 23
protocol which uses this neighborhood discovery protocol. 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 [1]. specified in [1].
o Packet header options MAY be used as specified by a protocol which o Packet header options MAY be used as specified by a protocol which
uses this neighborhood discovery protocol. uses this neighborhood discovery protocol.
o Received HELLO messages MUST be parsed in accordance with [1]. A
HELLO message which is not in conformance with [1] MUST be
discarded.
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 [3] and one address block TLV defined two message TLVs defined in [3]. These five TLV types are all
in [1]. These six TLV types are all defined only with Subtype == defined only with Type Extension == 0. TLVs of other types, and
0. TLVs of other types, and of these types but without Subtype == of these types but without Type Extension == 0, are ignored by
0, are ignored by this protocol. All references in this protocol this protocol. All references in this protocol to, for example, a
to, for example, a TLV with Type == LINK_STATUS, are to be TLV with Type == LINK_STATUS, are to be considered as referring to
considered as referring to a TLV with Type == LINK_STATUS and a TLV with Type == LINK_STATUS and Type Extension == 0.
Subtype == 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 [3], representing o A VALIDITY_TIME message TLV as specified in [3], representing
H_HOLD_TIME for the transmitting MANET interface. H_HOLD_TIME for the transmitting MANET interface. The options
included in [3] for representing zero and infinite times MUST NOT
o An address block, with an associated TLV block, known as the Local be used.
Interface Block, as specified in Section 10.1.1.
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 [3], representing o An INTERVAL_TIME message TLV as specified in [3], representing
HELLO_INTERVAL for the transmitting MANET interface. HELLO_INTERVAL for the transmitting MANET interface. The options
included in [3] for representing zero and 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 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. o Other message TLVs.
10.1.1. Local Interface Block 10.1.1. Address Blocks
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.
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 All addresses in a node's Local Interface Set (i.e. in any
for each MANET interface, and hence a HELLO message MAY contain more I_local_iface_addr_list) MUST be included in the address blocks in
than one address without an OTHER_IF TLV. all generated HELLO messages with the following exception. If the
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
omitted. All addresses of the node's interfaces included in an
address block MUST be associated with a TLV with Type == LOCAL_IF, as
defined in Table 1.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| OTHER_IF | 0 bits | Specifies that the address, in the Local | | LOCAL_IF | 8 bits | Specifies that the address is an address |
| | | Interface Block of the message, is an address | | | | associated with the interface on which the |
| | | associated with an interface other than the | | | | message was sent (THIS_IF), another interface |
| | | MANET interface on which the message is | | | | of the sending node (OTHER_IF), or an |
| | | transmitted | | | | unspecified interface of the sending node |
| | | (UNSPEC_IF). |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
Table 1 Table 1
10.1.2. Neighbor Address Blocks Note that the value UNSPEC_IF is not used by this protocol.
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 Address blocks MAY contain current or recently lost 1-hop neighbors'
neighbors' interface addresses, each of which is associated with interface addresses, each of which is associated with address block
address block TLVs as described in Table 2. Other addresses MAY be TLVs as described in Table 2.
included in Neighbor Address Blocks, but MUST NOT be associated with
any of the TLVs specified in Table 2.
+--------------+--------+-------------------------------------------+ +--------------+--------+-------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+--------------+--------+-------------------------------------------+ +--------------+--------+-------------------------------------------+
| LINK_STATUS | 8 bits | Specifies the status of the link from the | | LINK_STATUS | 8 bits | Specifies the status of the link from the |
| | | indicated address (LOST, SYMMETRIC or | | | | indicated address (LOST, SYMMETRIC or |
| | | HEARD) | | | | HEARD). |
| | | | | | | |
| OTHER_NEIGHB | 8 bits | Specifies that the address is (SYMMETRIC) | | OTHER_NEIGHB | 8 bits | Specifies that the address is (SYMMETRIC) |
| | | or was (LOST) of an interface of a | | | | or was (LOST) of an interface of a |
| | | symmetric 1-hop neighbor of the node | | | | symmetric 1-hop neighbor of the node |
| | | transmitting the HELLO message | | | | transmitting the HELLO message. |
+--------------+--------+-------------------------------------------+ +--------------+--------+-------------------------------------------+
Table 2 Table 2
A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value == A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value ==
LOST) also performs the function of a TLV with Type == OTHER_IF and LOST) also performs the function of a TLV with Type == OTHER_NEIGHB
the same value. The latter SHOULD NOT also be included. If a TLV and the same value. The latter SHOULD NOT also be included. If a
with Type == LINK_STATUS and Value == SYMMETRIC is combined with a TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with
TLV with Type == OTHER_IF and Value == LOST then the latter MUST be a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter
ignored, and SHOULD NOT be included. See Appendix A. MUST be ignored, and SHOULD NOT be included. See Appendix A.
Other addresses MAY be included in address blocks, but MUST NOT be
associated with any of the TLVs specified in this section.
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 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.
skipping to change at page 26, line 25 skipping to change at page 30, line 25
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.
A HELLO message MUST include a Local Interface Block, as specified in All addresses in any I_local_iface_addr_list MUST be included, except
Section 10.1.1, as its first address block. that:
Other addresses which MUST be included in Neighbor Address Blocks, as o If the interface on which the HELLO message is to be sent has a
specified in Section 10.1.2, in HELLO messages sent over a given single interface address with maximum prefix length then that
MANET interface are: interface address MAY be omitted.
All such included addresses MUST be associated with a TLV with Type
== LOCAL_IF and value according to the following:
o If the address is of the sending interface, then Value == THIS_IF.
o Otherwise, Value == OTHER_IF.
The following addresses of current or former 1-hop neighbors MAY be
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.
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 node's Node 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.
skipping to change at page 26, line 43 skipping to change at page 31, line 4
of the Interface Information Base for this MANET interface. of the Interface Information Base for this MANET interface.
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 node's Node 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 node's Node Information Base. (These
are advertised for a period equal to N_HOLD_TIME after loss.) are advertised for a period equal to N_HOLD_TIME after loss.)
The addresses, and their associated TLVs, which may be included in Each such address MUST be associated with one or more appropriate
any HELLO message sent on this MANET interface (respecting TLVs, respecting the parameter REFRESH_INTERVAL for each association
REFRESH_INTERVAL for this MANET interface) are: for each MANET interface. Specifically:
1. For each address (henceforth linked address) which appears in a 1. For each address (henceforth linked address) which appears in a
Link Tuple in the Link Set for this MANET interface, for which Link Tuple in the Link Set for this MANET interface, for which
L_status does not equal PENDING, include the linked address with L_status does not equal PENDING, include the linked address with
an associated TLV with: an associated TLV with:
* Type = LINK_STATUS; AND * Type = LINK_STATUS; AND
* Value = L_status. * Value = L_status.
skipping to change at page 27, line 33 skipping to change at page 31, line 40
* 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 TLV with:
* Type = OTHER_NEIGHB; AND * Type = OTHER_NEIGHB; AND
* Value = LOST. * Value = LOST.
If an address is specified with more than one associated TLV, then If a 1-hop neighbor address is specified with more than one
these TLVs MAY be independently included or excluded from each HELLO associated TLV, then these TLVs MAY be independently included or
message. Each such TLV MUST be included associated with that address excluded from each HELLO message. Each such TLV MUST be included
in a HELLO message sent on that MANET interface in every interval of associated with that address in a HELLO message sent on that MANET
length equal to that MANET interface's parameter REFRESH_INTERVAL. interface in every interval of length equal to that MANET interface's
TLVs associated with the same address included in the same HELLO parameter REFRESH_INTERVAL. TLVs associated with the same address
message MAY be applied to the same or different copies of that included in the same HELLO message MAY be applied to the same or
address. 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 [1] using the "LL MANET Routers" multicast address specified by by [1] using the "LL-MANET-Routers" multicast address specified by
[2] as destination IP address, using the MANET UDP port specified in [2] as destination IP address, using either the "manet" UDP port, or
[2]. the "manet" IP protocol number specified in [2].
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 [4]. HELLO messages SHOULD be jittered as described in [4].
Internally triggered message generation (such as due to a change in Internally triggered message generation (such as due to a change in
local interfaces) MAY be treated as if externally generated message local interfaces) MAY be treated as if externally generated message
generation, or MAY be not jittered. generation, or MAY be not jittered.
HELLO messages MUST NOT be forwarded, and thus message forwarding HELLO messages MUST NOT be forwarded, and thus message forwarding
jitter does not apply to HELLO messages. jitter does not apply to HELLO messages.
Each form of jitter described in [4] requires a parameter MAXJITTER. Each form of jitter described in [4] requires a parameter MAXJITTER.
These interface parameters may be dynamic, and are specified by: These interface parameters may be dynamic, and are specified by:
o For periodic message generation: HP_MAXJITTER, which MUST be o For periodic message generation: HP_MAXJITTER.
significantly less than HELLO_INTERVAL.
o For externally triggered message generation: HT_MAXJITTER. If o For externally triggered message generation: HT_MAXJITTER.
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 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. In this
case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL. 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 node MUST first check if any address
in its Local Interface Block is one of its interface addresses (i.e. associated with a TLV with Type == LOCAL_IF is one of the receiving
is in any I_local_iface_addr_list in the Local Interface Set). If so node's current or recently used interface addresses (i.e. is in any
I_local_iface_addr_list in the Local Interface Set or is equal to any
IR_local_iface_addr in the Removed Interface Address Set). If so
then the HELLO message MUST be discarded. then the HELLO message MUST be discarded.
Otherwise the receiving node MUST update its appropriate Interface Otherwise the receiving node MUST update its appropriate Interface
Information Base and its Node Information Base according to this Information Base and its Node Information Base according to this
section. If any changes satisfy any of the conditions described in section. If any changes satisfy any of the conditions described in
Section 13 then the indicated consequences MUST be applied Section 13 then the indicated consequences MUST be applied
immediately, unless noted otherwise. immediately, unless noted otherwise.
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 TLV of the o "validity time" is calculated from the VALIDITY_TIME message TLV
HELLO message as specified in [3]. of the HELLO message as specified in [3]. 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 "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 o "Sending Address List" is the list of the addresses contained in
the Local Interface Block of the HELLO message which do not have the HELLO message with an associated TLV with Type == LOCAL_IF and
an associated TLV with Type == OTHER_IF. Value == THIS_IF. If the Sending Address List is otherwise empty,
then the Sending Address List contains a single address (with
maximum prefix length) equal to the sending address of the IP
datagram in which the HELLO message was included.
o "Neighbor Address List" is the Sending Address List, plus the
addresses contained in the HELLO message with an associated 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 node originating the HELLO message, but which are not included
in the Neighbor Address List. This list is initialized as empty. 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
skipping to change at page 31, line 10 skipping to change at page 35, line 17
+ 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.2. Updating the Lost Neighbor Set
On receiving a HELLO message, a node MUST update its Lost Neighbor On receiving a HELLO message, a node MUST update its Lost Neighbor
Set: Set:
1. For each address (henceforth lost address) in the Lost Neighbor 1. For each address (henceforth lost address) in the Lost Address
List, if no Lost Neighbor Tuple with NL_neighbor_iface_addr == List, if no Lost Neighbor Tuple with NL_neighbor_iface_addr ==
lost address exists, then add a Lost Neighbor Tuple with: 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.3. Updating the Link Set
On receiving a HELLO message, a node MUST update its Link Set for the On receiving a HELLO message, a node MUST update its Link Set for the
skipping to change at page 31, line 45 skipping to change at page 36, line 4
all; apply Section 13.1, but not Section 13.3. all; apply Section 13.1, 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_quality = INITIAL_QUALITY;
* L_pending = INITIAL_PENDING; * L_pending = INITIAL_PENDING;
* L_lost = false; * L_lost = false;
* L_time = current time + validity time. * 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 MANET interface finds any address (henceforth 1. If the node finds any address (henceforth receiving address)
receiving address) in the Receiving Address List in a in the Receiving Address List in an address block in the
Neighbor Address Block in the HELLO message, then the Link HELLO message, then the Link Tuple is modified as follows:
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 a TLV with Type == LINK_STATUS and (Value
== HEARD or Value == SYMMETRIC) then: == 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 a TLV with Type == LINK_STATUS and
Value == LOST then: Value == LOST then:
skipping to change at page 33, line 6 skipping to change at page 37, line 14
12.4. Updating the 2-Hop Set 12.4. 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 node MUST update its 2-Hop Set for the
MANET interface on which the HELLO message was received: 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 with 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 a Neighbor 1. For each address (henceforth 2-hop address) in an address
Address Block of the HELLO message, which is not in the block of the HELLO message, which is not in the Neighbor
Neighbor Address List or in any I_local_iface_addr_list: 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: 1. If the 2-hop address has an associated TLV with:
- Type == LINK_STATUS and Value == SYMMETRIC; OR - Type == LINK_STATUS and Value == SYMMETRIC; OR
- Type == OTHER_NEIGHB and Value == SYMMETRIC, - 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
skipping to change at page 35, line 47 skipping to change at page 40, line 47
o L_status changes to SYMMETRIC; o L_status changes to SYMMETRIC;
(this includes a newly created Link Tuple which is immediately (this includes a newly created Link Tuple which is immediately
updated to have L_status == SYMMETRIC) then: updated to have L_status == SYMMETRIC) then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list includes 1. For the Neighbor Tuple whose N_neighbor_iface_addr_list includes
L_neighbor_iface_addr_list, set: L_neighbor_iface_addr_list, set:
* N_symmetric = true. * N_symmetric = true.
2. Remove all Lost Neighbor Tuples whose LN_neighbor_iface_addr is 2. Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is
included in that N_neighbor_iface_addr_list. 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;
skipping to change at page 40, line 29 skipping to change at page 45, line 29
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 Node Parameters
o N_HOLD_TIME = L_HOLD_TIME o N_HOLD_TIME = L_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 HYST_REJECT = 0
o INITIAL_QUALITY = 1 o INITIAL_QUALITY = 1
skipping to change at page 40, line 50 skipping to change at page 46, line 7
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 = 0.0625 second (1/16 second) o C = 1/1024 second
16. IANA Considerations 16. Security Considerations
16.1. Message Types 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 the
Interface Information Bases and Node Information Base, describing the
node's 1-hop neighborhood and symmetric 2-hop neighborhood.
Under normal circumstances, the information recorded in these
Information Bases 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
Information Bases. 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 Information
Bases, and should be reflected in the specification of protocols
which use information provided by NHDP.
This section, therefore, only outlines the ways in which correctly
formed, but still invalid, HELLO messages may appear.
16.1. Invalid HELLO messages
A correctly formed, but still invalid, HELLO message may take any of
the following forms. Note that a present or absent address in an
address block, does not in and by itself cause a problem. It is the
presence, absence, or incorrectness of associated LOCAL_IF,
LINK_STATUS and OTHER_NEIGHB TLVs that causes problems.
A node may provide false information about its own identity:
* The HELLO message may contain addresses with an associated
LOCAL_IF TLV which do not correspond to addresses of interfaces
of the node transmitting the HELLO message.
* The HELLO message may omit addresses, or their associated
LOCAL_IF TLV, of interfaces of the local node transmitting the
HELLO message (other than the allowed omission of the only
local interface address of the MANET interface over 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
nodes:
* 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.
17. IANA Considerations
17.1. Message Types
This specification defines one message type, which must be allocated This specification defines one message type, which must be allocated
from the "Assigned Message Types" repository of [1] with assignment from the "Assigned Message Types" repository of [1] with assignment
as specified in Table 3. as specified in Table 3.
+-------+------+-----------------+ +-------+------+------------------+
| Name | Type | Description | | Name | Type | Description |
+-------+------+-----------------+ +-------+------+------------------+
| HELLO | TBD | Local signaling | | HELLO | TBD1 | Local signaling. |
+-------+------+-----------------+ +-------+------+------------------+
Table 3 Table 3
16.2. TLV Types 17.2. TLV Types
This specification defines three address block TLV types, which must This specification defines three address block TLV types, which must
be allocated from the "Assigned Address Block TLV Types" repository be allocated from the "Assigned Address Block TLV Types" repository
of [1] with assignments as specified in Table 4. of [1] with assignments as specified in Table 4.
+--------------+------+---------+-----------------------------------+ +--------------+------+-----------+---------------------------------+
| Name | Type | Subtype | Description | | Name | Type | Type | Description |
+--------------+------+---------+-----------------------------------+ | | | extension | |
| OTHER_IF | TBD | 0 | Specifies that the address is | +--------------+------+-----------+---------------------------------+
| | | | associated with an interface | | LOCAL_IF | TBD2 | 0 | Specifies that the address is |
| | | | other than the MANET interface on | | | | | associated with a local |
| | | | which the message is transmitted | | | | | interface of the sending node. |
| | | | | | | | | |
| | | 1-255 | RESERVED | | | | 1-255 | RESERVED |
| | | | | | | | | |
| LINK_STATUS | TBD | 0 | Specifies the status of the link | | LINK_STATUS | TBD3 | 0 | Specifies the status of the |
| | | | from the indicated address (LOST, | | | | | link from the indicated address |
| | | | SYMMETRIC or HEARD) | | | | | (LOST, SYMMETRIC or HEARD). |
| | | | | | | | | |
| | | 1-255 | RESERVED | | | | 1-255 | RESERVED |
| | | | | | | | | |
| OTHER_NEIGHB | TBD | 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 | | | | | node transmitting the message. |
| | | | | | | | | |
| | | 1-255 | RESERVED | | | | 1-255 | RESERVED |
+--------------+------+---------+-----------------------------------+ +--------------+------+-----------+---------------------------------+
Table 4 Table 4
Subtypes indicated as RESERVED may be allocated by standards action, Type extensions indicated as RESERVED may be allocated by standards
as specified in [6]. action, as specified in [6].
16.3. LINK_STATUS and OTHER_NEIGHB Values 17.3. LINK_STATUS and OTHER_NEIGHB Values
The values which the LOCAL_IF TLV can use are the following:
o UNSPEC_IF = 0
o THIS_IF = 1
o OTHER_IF = 2
The values which the LINK_STATUS TLV can use are the following: The values which the LINK_STATUS TLV can use are the following:
o LOST = 0 o LOST = 0
o SYMMETRIC = 1 o SYMMETRIC = 1
o HEARD = 2 o HEARD = 2
The values which the OTHER_NEIGHB TLV can use are the 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
17. References 18. References
17.1. Normative References 18.1. Normative References
[1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized [1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized
MANET Packet/Message Format", Work In MANET Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-07.txt, June 2007. Progress draft-ietf-manet-packetbb-11.txt, November 2007.
[2] Chakeres, I., "Internet Assigned Numbers Authority (IANA) [2] Chakeres, I., "IANA Allocations for MANET Protocols", Work In
Allocations for the Mobile Ad hoc Networks (MANET) Working Progress draft-ietf-manet-iana-07.txt, November 2007.
Group", Work In Progress draft-ietf-manet-iana-05.txt,
June 2007.
[3] Clausen, T. and C. Dearlove, "Representing multi-value time in [3] Clausen, T. and C. Dearlove, "Representing multi-value time in
MANETs", Work In Progress draft-ietf-manet-timetlv-01.txt, MANETs", Work In Progress draft-ietf-manet-timetlv-04.txt,
June 2007. November 2007.
[4] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [4] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", Work In considerations in MANETs", Work In
Progress draft-ietf-manet-jitter-01.txt, June 2007. Progress draft-ietf-manet-jitter-04.txt, December 2007.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998. Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
17.2. Informative References 18.2. Informative References
[7] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [7] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
[8] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): [8] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET):
Routing Protocol Performance Issues and Evaluation Routing Protocol Performance Issues and Evaluation
Considerations", RFC 2501, January 1999. Considerations", RFC 2501, January 1999.
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 addresses may be included in the address blocks after the Local which 1-hop addresses may be included in the address blocks, and with
Interface Block, and with which associated TLVs. These TLVs may have which associated TLVs. These TLVs may have Type == LINK_STATUS or
Type == LINK_STATUS or Type == OTHER_NEIGHB, or both. TLVs with Type Type == OTHER_NEIGHB, or both. TLVs with Type == LINK_STATUS may
== LINK_STATUS may have three possible values (Value == HEARD, Value have three possible values (Value == HEARD, Value == SYMMETRIC or
== SYMMETRIC or Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two
have two possible values (Value == SYMMETRIC or Value == LOST). When possible values (Value == SYMMETRIC or Value == LOST). When both
both TLVs are associated with the same address only certain TLVs are associated with the same address only certain combinations
combinations of these TLV values are necessary, and are the only of these TLV values are necessary, and are the only combinations
combinations generated by the algorithm in Section 11. These generated by the algorithm in Section 11. These combinations are
combinations are indicated in Table 5. indicated in Table 5.
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.
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | Type == | Type == | Type == | | | Type == | Type == | Type == |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
skipping to change at page 45, line 9 skipping to change at page 53, line 9
| LINK_STATUS, | | | | | LINK_STATUS, | | | |
| Value == LOST | | | | | Value == LOST | | | |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
Table 5 Table 5
Appendix B. HELLO Message Example Appendix B. HELLO Message Example
An example HELLO message, transmitted by an originator node with a An example HELLO message, transmitted by an originator node with a
single MANET interface, is as follows. The message uses IPv4 (four single MANET interface, is as follows. The message uses IPv4 (four
octet) addresses without prefix TLVs. The message is transmitted octet) addresses without specified prefix lengths. The message is
with a full message header (message semantics octet is 0) with a hop transmitted with a full message header other than version number
limit of 1 and a hop count of 0. The overall message length is 50 (message semantics octet is 0) with a hop limit of 1 and a hop count
octets. of 0. The overall message length is 49 octets.
The message contains a message TLV block with content length 8 octets The message contains a message TLV block with content length 8 octets
containing two message TLVs, of types VALIDITY_TIME and containing two message TLVs, of types VALIDITY_TIME and
INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating
that no start and stop indexes are included, and each has a value 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 length of 1 octet. The values included (0x6C and 0x58) are time
codes representing the default values of parameters H_HOLD_TIME and codes representing the default values of parameters H_HOLD_TIME and
HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the
default value of constant C (0.0625 second). default value of constant C (1/1024 second).
The first address block contains 1 local interface address. The The message has a single address block containing 5 addresses. The
semantics octet value 2 indicates no address tail, and the head semantics octet value 2 indicates no address tail, the head length of
length of 4 octets indicates no address mid sections. This address 3 octets indicates address mid sections of one octet each (Mid 0 to
block has no TLVs (TLV block content length 0 octets). Mid 4).
The second, and last, address block contains 4 neighbor interface The following TLV block (content length 14 octets) includes two TLVs.
addresses. The semantics octet value 2 indicates no address tail, The first is a LOCAL_IF TLV which (with semantics value 16) indicates
the head length of 3 octets indicates address mid sections of one that a single address, with index 0 (i.e. Head:Mid 0) is the single
octet each. The following TLV block (content length 7 octets) local interface address of this node. The second is a LINK_STATUS
includes one LINK_STATUS TLV which reports the link status values of TLV which (with semantics octet 32) specifies the link status values
all reported neighbors in a single multivalue TLV: the first two of all reported neighbors in a single multivalue TLV which covers the
addresses are HEARD, the third address is SYMMETRIC and the fourth addresses with indexes 1 to 4. The TLV value length of 4 octets
address is LOST. The TLV semantics value of 40 indicates, in indicates one octet per value per address. The last four addresses
addition to that this is a multivalue TLV, that no start and stop are first and second HEARD, third SYMMETRIC, and fourth LOST.
indexes are included, since values for all addresses are included.
The TLV value length of 4 octets indicates one octet per value per
address.
0 1 2 3 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 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| | HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | 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 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 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 1|0 1 1 0 1 1 0 0| INTERVAL_TIME |0 0 0 0 1 0 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 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Head | |0 0 0 0 0 0 1 1| 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| | Mid 0 | Mid 1 | Mid 2 | Mid 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head | | Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid | Mid | |0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS | | LINK_STATUS |0 0 1 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 1 0 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD | |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYMMETRIC | LOST | | 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 1 1 1 1 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 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 1 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 1 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST |
+-+-+-+-+-+-+-+-+
Appendix C. Constraints Appendix C. Constraints
Any process which updates the Local Information Base or the Any process which updates the Local Information Base or the Node
Neighborhood Information Base MUST ensure that all constraints Information Base MUST ensure that all constraints specified in this
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 address which is in 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. the I_local_iface_addr_list of any other Local Interface Tuple.
In each Removed Interface Address Tuple:
o IR_local_iface_addr MUST NOT contain any address which is in the
I_local_iface_addr_list of any Local Interface Tuple.
o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
other Removed Interface Address Tuple.
In each Link Tuple: In each Link Tuple:
o L_neighbor_iface_addr_list MUST NOT be empty. o L_neighbor_iface_addr_list MUST NOT be empty.
o L_neighbor_iface_addr_list MUST NOT contain any address which is 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. in the I_local_iface_addr_list of any Local Interface Tuple or the
IR_local_iface_addr of any Removed Interface Address Tuple.
o L_neighbor_iface_addr_list MUST NOT contain any duplicated
addresses.
o L_neighbor_iface_addr_list MUST NOT contain any address which is 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 in the L_neighbor_iface_addr_list of any other Link Tuple in the
same Link Set. same Link Set.
o If L_HEARD_time has not expired then there MUST be a Neighbor o If L_HEARD_time has not expired then there MUST be a Neighbor
Tuple whose N_neighbor_iface_addr_list contains Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list. L_neighbor_iface_addr_list.
o L_HEARD_time MUST NOT be greater than L_time. o L_HEARD_time MUST NOT be greater than L_time.
skipping to change at page 47, line 49 skipping to change at page 57, line 16
o If L_quality >= HYST_ACCEPT then L_pending MUST be false. 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 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. o L_pending MUST NOT be set to true if it is currently false.
In each Neighbor Tuple: In each Neighbor Tuple:
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. in the I_local_iface_addr_list of any Local Interface Tuple or the
IR_local_iface_addr of any Removed Interface Address Tuple.
o N_neighbor_iface_addr_list MUST NOT contain any duplicated
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 == true, then there MUST be one or more Link Tuples
with: 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
skipping to change at page 48, line 25 skipping to change at page 57, line 45
* 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 one such Link Tuple MUST have L_HEARD_time not expired. least 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. of any Local Interface Tuple or the IR_local_iface_addr of any
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. any Local Interface Tuple or the IR_local_iface_addr of any
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. Security Considerations Appendix D. Flow and Congestion Control
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
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.
Appendix E. Flow and Congestion Control
This protocol specifies one message type, the HELLO message. The This protocol specifies one message type, the HELLO message. The
maximum size of a HELLO message is proportional to the size of 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 originating node's 1-hop neighborhood. HELLO messages MUST NOT be
forwarded. forwarded.
A node MUST report its 1-hop neighborhood in HELLO messages on each 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 of its MANET interfaces at least each REFRESH_INTERVAL. This puts a
lower bound on the control traffic generated by each node in the lower bound on the control traffic generated by each node in the
network employing this protocol. network employing this protocol.
A node MUST ensure that two successive HELLO messages sent on the A node MUST ensure that two successive HELLO messages sent on the
same MANET interface are separated by at least HELLO_MIN_INTERVAL. 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 (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 HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound
on the control traffic generated by each node in the network on the control traffic generated by each node in the network
employing this protocol. employing this protocol.
Appendix F. Contributors Appendix E. Contributors
This specification is the result of the joint efforts of the This specification is the result of the joint efforts of the
following contributors -- listed alphabetically. following contributors -- listed alphabetically.
o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil> o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, Hitachi Labs Europe, France, o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
<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 Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, o Christopher Dearlove, BAE Systems, UK,
<Chris.Dearlove@baesystems.com> <Chris.Dearlove@baesystems.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
Appendix G. Acknowledgements Appendix F. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, The authors would like to acknowledge the team behind OLSRv1,
specified in RFC3626 for their contributions. specified in RFC3626 for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components: Joe Macker (NRL), Alan Cullen (BAE specification and its components: Joe Macker (NRL), Alan Cullen (BAE
Systems), and the entire IETF MANET working group. Systems), and the entire IETF MANET working group.
Authors' Addresses Authors' Addresses
 End of changes. 142 change blocks. 
514 lines changed or deleted 693 lines changed or added

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