draft-ietf-manet-nhdp-00.txt   draft-ietf-manet-nhdp-01.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
Expires: December 21, 2006 C. Dearlove Intended status: Standards Track C. Dearlove
BAE Systems Advanced Technology Expires: August 13, 2007 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 19, 2006 February 9, 2007
MANET Neighborhood Discovery Protocol (NHDP) MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-00 draft-ietf-manet-nhdp-01
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 21, 2006. This Internet-Draft will expire on August 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a neighborhood discovery protocol (NHDP) for This document describes a 1-hop and symmetric 2-hop neighborhood
a mobile ad hoc network (MANET). The protocol provides each MANET discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
node with local topology up to two hops distant, describing a node's
1-hop neighbors and symmetric 2-hop neighbors. This is achieved
through periodic message exchange. This neighborhood discovery
protocol may be used by any MANET protocols which need neighborhood
information.
The protocol imposes minimum requirements to the network by not
requiring sequenced or reliable transmission of control traffic.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
3. Neighborhood Information Base . . . . . . . . . . . . . . . . 9 4.1. HELLO Message Generation . . . . . . . . . . . . . . . . . 7
3.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. HELLO message content . . . . . . . . . . . . . . . . . . 8
3.2. Symmetric Neighbor Set . . . . . . . . . . . . . . . . . . 10 4.3. Node Behavior . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Neighborhood Address Association Set . . . . . . . . . . . 11 5. Neighborhood Information Base . . . . . . . . . . . . . . . . 10
3.4. 2-Hop Neighbor Set . . . . . . . . . . . . . . . . . . . . 11 5.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 13 5.2. Symmetric Neighbor Set . . . . . . . . . . . . . . . . . . 11
4.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Neighborhood Address Association Set . . . . . . . . . . . 12
4.1.1. Local Interface Block . . . . . . . . . . . . . . . . 14 5.4. 2-Hop Neighbor Set . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Message TLVs . . . . . . . . . . . . . . . . . . . . . 14 6. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 13
4.1.3. Address Block TLVs . . . . . . . . . . . . . . . . . . 16 6.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 13
5. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 17 6.1.1. Local Interface Block . . . . . . . . . . . . . . . . 14
5.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 18 6.1.2. Address Block TLVs . . . . . . . . . . . . . . . . . . 14
6. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 19 7. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 15
6.1. Populating the Link Set . . . . . . . . . . . . . . . . . 19 7.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 16
6.2. Populating the Symmetric Neighbor Set . . . . . . . . . . 20 7.1.1. HELLO Message: Jitter . . . . . . . . . . . . . . . . 17
6.3. Populating the Neighborhood Address Association Set . . . 21 8. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 18
6.4. Populating the 2-Hop Neighbor Set . . . . . . . . . . . . 22 8.1. Populating the Link Set . . . . . . . . . . . . . . . . . 18
6.5. Neighborhood Changes . . . . . . . . . . . . . . . . . . . 23 8.2. Populating the Symmetric Neighbor Set . . . . . . . . . . 19
7. Proposed Values for Constants . . . . . . . . . . . . . . . . 24 8.3. Populating the Neighborhood Address Association Set . . . 20
7.1. Message Intervals . . . . . . . . . . . . . . . . . . . . 24 8.4. Populating the 2-Hop Neighbor Set . . . . . . . . . . . . 20
7.2. Holding Times . . . . . . . . . . . . . . . . . . . . . . 24 8.5. Neighborhood Changes . . . . . . . . . . . . . . . . . . . 22
7.3. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Proposed Values for Constants . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9.1. Message Intervals . . . . . . . . . . . . . . . . . . . . 23
8.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 25 9.2. Holding Times . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 25 9.3. Jitter Times . . . . . . . . . . . . . . . . . . . . . . . 23
8.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 25 9.4. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.4. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Heuristics for Generating HELLO Messages . . . . . . 28 10.4. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 25
Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Security Considerations . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 27
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 37 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Appendix C. Time TLVs . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 39 C.1. Representing Time . . . . . . . . . . . . . . . . . . . . 30
C.2. General Time TLV Structure . . . . . . . . . . . . . . . . 30
C.3. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . 32
C.3.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . 32
C.3.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . 32
Appendix D. Message Jitter . . . . . . . . . . . . . . . . . . . 33
D.1. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 33
D.1.1. Periodic message generation . . . . . . . . . . . . . 33
D.1.2. Externally triggered message generation . . . . . . . 34
D.1.3. Message forwarding . . . . . . . . . . . . . . . . . . 34
Appendix E. Utilizing Link Layer Information . . . . . . . . . . 36
Appendix F. Security Considerations . . . . . . . . . . . . . . 38
Appendix F.1. Invalid HELLO messages . . . . . . . . . . . . . . . 38
Appendix G. Flow and Congestion Control . . . . . . . . . . . . 40
Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 41
Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44
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). It was originally developed for the a mobile ad hoc network (MANET). The protocol uses an exchange of
Optimized Link State Routing Protocol version 2 (OLSRv2) [3], based HELLO messages in order that each node can determine its 1-hop and
on that used in the Optimized Link State Routing Protocol version 1 symmetric 2-hop neighborhoods.
[4]. It uses an exchange of HELLO messages in order that each node
can determine its neighborhood up to two hops distant. This protocol This specification describes both this HELLO message exchange, the
is used by OLSRv2 to determine a node's 1-hop neighbors for routing, messages being defined as instances of the specification [1], and the
and to allow the selection of MultiPoint Relays (MPRs) for optimized information storage required for neighborhood discovery.
flooding and topology reporting. This specification however only
describes the message exchange and information storage required for
1-hop and symmetric 2-hop neighborhood discovery. It may be used by
any MANET protocols which need neighborhood information, and which
may add an MPR mechanism, or an alternative to it, using appropriate
TLVs (type-length-value objects) as specified in [1], using which
this protocol's HELLO message format is defined.
This protocol makes no assumptions about the underlying link layer, This protocol makes no assumptions about the underlying link layer,
other than support of local multicast. Link layer information and other than support of link local multicast. Link layer information
notifications may be used if available and applicable to qualify the and notifications may be used if available and applicable.
neighborhood information.
1.1. Terminology This protocol is based on the neighborhood discovery process
contained in the Optimized Link State Routing Protocol (OLSR) [3].
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 [2]. document are to be interpreted as described in RFC2119 [2].
The terms "packet", "message", "address block", "TLV", and "TLV
block" in this document are to be interpreted as described in [1].
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
node - A MANET router which implements this neighborhood discovery Node - A MANET router which implements this neighborhood discovery
protocol. protocol.
MANET interface - A network device participating in a MANET and using MANET interface - A network device participating in a MANET and
this neighborhood discovery protocol. A node may have several using this neighborhood discovery protocol. A node may have
MANET interfaces, each interface being assigned one or more IP several MANET interfaces, each being assigned one or more IP
addresses. addresses.
link - A link is a pair of MANET interfaces from two different nodes, Link - A pair of MANET interfaces from two different nodes, where at
where at least one interface is able to hear (i.e. receive traffic least one interface is able to receive traffic from the other.
from) the other.
symmetric link - A link where both MANET interfaces are able to hear
(i.e. receive traffic from) the other.
asymmetric link - A link which is not symmetric. Symmetric link - A link where both MANET interfaces are able to
receive traffic from the other.
1-hop neighbor - A node X is a 1-hop neighbor of a node Y if node Y 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if node Y
can hear node X (i.e. a link exists from a MANET interface on node can hear node X (i.e. a link exists from a MANET interface on node
X to a MANET interface on node Y). X to a MANET interface on node Y).
symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of
a node Y if a symmetric link exists from a MANET interface on node a node Y if a symmetric link exists from a MANET interface on node
X to a MANET interface on node Y. X to a MANET interface on node Y.
symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of
a node Y if node X is a symmetric 1-hop neighbor of a symmetric a node Y if node X is a symmetric 1-hop neighbor of a symmetric
1-hop neighbor of node Y, but is not node Y itself. 1-hop neighbor of node Y, but is not node Y itself.
1-hop neighborhood - The 1-hop neighborhood of a node X is the set of 1-hop neighborhood - The 1-hop neighborhood of a node X is the set
the 1-hop neighbors of node X. of the 1-hop neighbors of node X.
symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a
node X is the set of the symmetric 1-hop neighbors of node X. node X is the set of the symmetric 1-hop neighbors of node X.
symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a
node X is the set of the symmetric 2-hop neighbors of node X. node X is the set of the symmetric 2-hop neighbors of node X.
(This may include nodes in the 1-hop neighborhood, or even in the (This may include nodes in the 1-hop neighborhood, or even in the
symmetric 1-hop neighborhood, of node X.) symmetric 1-hop neighborhood, of node X.)
1.2. Applicability Statement 3. Applicability Statement
This neighborhood discovery protocol supports nodes which have one or This neighborhood discovery protocol supports nodes which have one or
more interfaces which participate in the MANET. It provides each more interfaces participating in the MANET. It provides each node
node with local topology information up to two hops away. This with local topology information up to two hops away. This
information is made available to other protocols through a collection information is made available to other protocols through a
of sets describing the node's 1-hop neighborhood and symmetric 2-hop Neighborhood Information Base, described in Section 5.
neighborhood, collectively known as the neighborhood information
base.
The specification is designed specifically with IP (IPv4/IPv6) in The protocol is designed to work in networks where messages may be
mind. All addresses within a control message are assumed to be of lost, such as due to collisions in wireless networks. If relevant
the same size, deduced from IP. In the case of mixed IPv6 and IPv4 link layer information is available then it may be used by this
addresses, IPv4 addresses are carried in IPv6 as specified in [5]. protocol.
The packets defined by this specification may use any transport This protocol to works in a completely distributed manner and does
protocol appropriate to the protocol using this specification. When not depend on any central entity. It does not require any changes to
the diffusion mechanism enabled by this specification is employed, the format of IP packets, thus any existing IP stack can be used as
UDP may be most appropriate. is.
This protocol uses the message exchange format specified in [1]. This protocol uses the packet and message formats specified in [1].
This implies that the HELLO messages specified by this protocol may HELLO messages specified by this protocol may be extended using the
be extended using the TLV mechanisms described in [1], e.g. to signal TLV mechanisms described in [1]. For example, if multipoint relays
MPR selection as required by OLSRv2 [3]. This also implies that (MPRs) are to be calculated similarly to as in OLSR [3] and signaled
neighborhood discovery protocol messages can be transmitted in to neighbors, then this information may be added to HELLO messages
packets with messages from other protocols, so long as these using an address block TLV. HELLO messages can also be transmitted
protocols also use [1]. in packets with messages from other protocols that also use [1].
2. Protocol Overview and Functioning 4. Protocol Overview and Functioning
This protocol consists of a specification of local signaling, which This protocol specifies local (one hop) signaling that:
serves to:
o advertise the presence of a node and its MANET interfaces to o advertises the presence of a node and its MANET interfaces;
adjacent nodes (1-hop neighbors);
o discover links to adjacent nodes; o discovers links to adjacent nodes;
o perform bidirectionality (symmetry) checks on the discovered o performs bidirectionality checks on the discovered links;
links;
o advertise 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 discover symmetric 2-hop neighbors; 1-hop neighbors and hence discover symmetric 2-hop neighbors;
o maintain an information base consisting of discovered links and o maintains an information base describing discovered links and
their status, 1-hop neighbors and their MANET interfaces, their status, 1-hop neighbors and their MANET interfaces,
symmetric 1-hop neighbors and symmetric 2-hop neighbors. symmetric 1-hop neighbors and symmetric 2-hop neighbors.
Signaling consists of a single type of periodically transmitted Signaling consists of a single type of message, known as a HELLO
message known as a HELLO message. A HELLO message identifies its message. A HELLO message identifies its originator node and that
originator node and that node's MANET interfaces and addresses. As a node's MANET interfaces and addresses. As a node receives HELLO
node receives HELLO messages and populates its information base, a messages and populates its information base, a list of 1-hop
list of 1-hop neighbors' MANET interface addresses and their link neighbors' MANET interface addresses and their link status (lost,
status is included in subsequent HELLO message content. Thus, the symmetric or heard) is included in subsequent HELLO messages. Thus,
periodic transmission allows nodes to continuously track changes in the periodic transmission allows nodes to continuously track changes
their 1-hop and symmetric 2-hop neighborhoods. in their 1-hop and symmetric 2-hop neighborhoods. If information
about link quality is available from the link layer, then this may
also be used, see Appendix E.
Because each node sends HELLO messages periodically, the protocol can 4.1. HELLO Message Generation
tolerate reasonable message loss without requiring reliable
transmission. Such losses can occur frequently in radio networks due
to collisions or other transmission problems.
The nominal time interval of a node's periodic HELLO transmission is HELLO messages may be sent:
known as HELLO_INTERVAL and MAY be included in the HELLO message.
The HELLO message MUST include a validity time value that indicates
the length of time for which the message content is to be considered
valid and included in the receiving node's information base. In some
uses the validity time may be a multiple of HELLO_INTERVAL to allow
for lossy exchange of HELLO messages.
HELLO messages MAY, in addition to periodic transmissions, also be o Proactively, at a regular interval, known as HELLO_INTERVAL.
generated as a response to some event (e.g. a change in the HELLO_INTERVAL may be fixed, as suggested in Section 9, or may be
advertised neighborhood indicated by a received HELLO message or by a dynamic. For example HELLO_INTERVAL may be backed off due to
layer 2 notification, if available, indicating a change in a link to congestion or network stability. Note that if HELLO_INTERVAL is
a neighbor). However a node MUST respect a minimum interval, dynamic, it is interpreted as the interval within which the next
HELLO_MIN_INTERVAL, between successive HELLO message transmissions in HELLO message will be sent on the same MANET interface.
order to maintain an upper bound on signaling traffic.
This protocol is designed to work in a completely distributed manner o As a response to a change in the node itself, or its neighborhood,
and does not depend on any central entity. This protocol does not for example on first becoming active or in response to a new,
require any changes to the format of IP packets, thus any existing IP broken or changed status link.
stack can be used as is.
Each MANET node will form estimates of its 1-hop and symmetric 2-hop o In a combination of these proactive and responsive mechanisms.
neighborhoods as this protocol operates. These estimates can be
maintained in an information base comprised of the data sets listed
below. These are defined formally in Section 3 and can be summarized
as follows:
Link Set - This set records the status of all links from and, if Jittering of HELLO message generation and transmission, as described
symmetric, to 1-hop neighbors. It also records as lost links in Section 7.1, may be appropriate.
which used to be symmetric but have since failed. A node MUST
record the Link Set in order to correctly send HELLO messages.
Symmetric Neighbor Set - This set records the addresses of the MANET HELLO messages are sent independently on each MANET interface.
interfaces of symmetric 1-hop neighbors, or, as lost, those which
used to be. Note that if any of these nodes have more than one
MANET interface then this set may record addresses that are not in
the Link Set. A node MUST record the Symmetric Neighbor Set in
order to correctly send HELLO messages.
Neighborhood Address Association Set - This set allows the addresses 4.2. HELLO message content
of the MANET interfaces of each 1-hop neighbor to be associated
with each other. It is required for processes such as MPR
selection as in [3].
2-Hop Neighbor Set - This set records the addresses of the MANET Each HELLO message sent over a MANET interface need not contain all
interfaces of symmetric 2-hop neighbors. It is required for of the information appropriate to that MANET interface, however:
processes such as MPR selection as in [3].
3. Neighborhood Information Base o A HELLO message MUST contain all of its own local interface
information.
The neighborhood information base stores information about the 1-hop o Within every time interval of length REFRESH_INTERVAL, HELLO
neighborhood and the symmetric 2-hop neighborhood of a node. messages sent over a MANET interface MUST include all of the
information appropriate to that interface in at least one HELLO
message sent on that interface. This applies to otherwise purely
responsive nodes as well as proactive nodes.
Note that it is possible for a node, X, to be present in both the o A HELLO message MUST include a VALIDITY_TIME message TLV that
1-hop and symmetric 2-hop neighborhoods of another node, Y, indicates the length of time for which the message content is to
concurrently. If the link between node X and node Y breaks, this be considered valid and included in the receiving node's
allows node X to be taken into consideration as a symmetric 2-hop Neighborhood Information Base.
neighbor by node Y immediately, rather than waiting for a HELLO
message exchange cycle.
This specification assumes that all addresses have an associated o A HELLO message SHOULD include an INTERVAL_TIME message TLV that
prefix length. The prefix length of an address is, in HELLO indicates the current value of HELLO_INTERVAL.
messages, indicated using the PREFIX_LENGTH TLV specified in [1]. If
no PREFIX_LENGTH TLV is present for a given address, it is assumed
that the prefix length for that address is equal to the length of the
address. Two addresses are identical if and only if both the
addresses and their associated prefix lengths are identical.
Addresses recorded in the neighborhood information base 4.3. Node Behavior
(L_local_iface_addr, L_neighbor_iface_addr, N_local_iface_addr,
N_neighbor_iface_addr, N2_local_iface_addr, N2_neighbor_iface_addr,
N2_2hop_iface_addr and those listed in NA_neighbor_iface_addr_list)
MUST all be recorded with prefix lengths, in order to allow
comparison with addresses received in HELLO messages.
3.1. Link Set A node MUST:
A node records a set of "Link Tuples", recording information about o Respect a minimum interval, HELLO_MIN_INTERVAL, between successive
its 1-hop neighborhood: HELLO message transmissions over a given interface. If jitter is
used then this interval may be reduced, but only by a random value
not exceeding HP_MAXJITTER.
o Ensure that if HELLO_INTERVAL and other parameters are maintained
dynamically, changes do not invalidate the guarantees of
Section 7.1.
o Maintain, based on received HELLO messages, estimates of its 1-hop
and symmetric 2-hop neighborhoods as this protocol operates.
Formally defined in Section 5, this can be summarized as
consisting of the following sets:
Link Set - Records the status of all links from and to current
and former 1-hop neighbors.
Symmetric Neighbor Set - Records the status of current and former
symmetric 1-hop neighbors. If any of these nodes have more
than one MANET interface then this set may record addresses
that are not in the Link Set.
Neighborhood Address Association Set - Allows the addresses of
the MANET interfaces of each 1-hop neighbor to be associated
with each other.
2-Hop Neighbor Set - Records the addresses of the MANET
interfaces of symmetric 2-hop neighbors.
The information in the Link Set and Symmetric Neighbor Set MUST be
maintained in order for a node to correctly generate HELLO
messages.
5. Neighborhood Information Base
A node maintains a Neighborhood Information Base that records
information about its 1-hop and symmetric 2-hop neighborhoods. The
Neighborhood Information Base includes the Link Set, the Symmetric
Neighbor Set, the Neighborhood Address Association Set and the 2-Hop
Neighbor Set.
A node, X, can be present in both the 1-hop and symmetric 2-hop
neighborhoods of another node, Y, concurrently. This allows node X
to be immediately considered as a symmetric 2-hop neighbor by node Y
if the link between them fails.
All addresses MUST have an associated prefix length, which is
included in all addresses in the Neighborhood Information Base.
Prefix lengths are indicated in HELLO messages using the
PREFIX_LENGTH TLV specified in [1]; if an address has no such TLV,
then its prefix length is equal to the address length. Two addresses
are considered equal if and only if their associated prefix lengths
are also equal.
5.1. Link Set
A node's Link Set records its 1-hop neighborhood. It consists of
Link Tuples:
(L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time,
L_ASYM_time, L_time) L_ASYM_time, L_time)
each describing a link between a MANET interface of this node and a where:
MANET interface of one of its 1-hop neighbors, where:
L_local_iface_addr is the address of the MANET interface of the local L_local_iface_addr is the address of the local MANET interface on
node on which the 1-hop neighbor is or was heard; which the 1-hop neighbor is or was heard;
L_neighbor_iface_addr is the address of the MANET interface of the L_neighbor_iface_addr is the address of the MANET interface of the
1-hop neighbor; 1-hop neighbor;
L_SYM_time is the time until which the link to the 1-hop neighbor is L_SYM_time is the time until which the link to the 1-hop neighbor is
considered symmetric; considered symmetric;
L_ASYM_time is the time until which the MANET interface of the 1-hop L_ASYM_time is the time until which the MANET interface of the 1-hop
neighbor is considered heard; neighbor is considered heard;
L_time specifies when this Link Tuple expires and MUST be removed. L_time specifies when this Tuple expires and MUST be removed.
The status of the link, denoted L_STATUS, can be derived based on the The status of the link, denoted L_STATUS, can be derived based on the
fields L_SYM_time and L_ASYM_time as defined in Table 1. fields L_SYM_time and L_ASYM_time as defined in Table 1.
+-------------+-------------+-----------+ +-------------+-------------+-----------+
| L_SYM_time | L_ASYM_time | L_STATUS | | L_SYM_time | L_ASYM_time | L_STATUS |
+-------------+-------------+-----------+ +-------------+-------------+-----------+
| Expired | Expired | LOST | | Expired | Expired | LOST |
| | | | | | | |
| Not Expired | Expired | SYMMETRIC | | Not Expired | Expired | SYMMETRIC |
| | | | | | | |
| Not Expired | Not Expired | SYMMETRIC | | Not Expired | Not Expired | SYMMETRIC |
| | | | | | | |
| Expired | Not Expired | HEARD | | Expired | Not Expired | HEARD |
+-------------+-------------+-----------+ +-------------+-------------+-----------+
Table 1 Table 1
In a node, the set of Link Tuples is denoted the "Link Set". 5.2. Symmetric Neighbor Set
3.2. Symmetric Neighbor Set
A node records a set of "Symmetric Neighbor Tuples", recording A node's Symmetric Neighbor Set records its symmetric 1-hop
information about its symmetric 1-hop neighborhood: neighborhood. It consists of Symmetric Neighbor Tuples:
(N_local_iface_addr, N_neighbor_iface_addr, N_SYM_time, N_time) (N_local_iface_addr, N_neighbor_iface_addr, N_SYM_time, N_time)
each describing an address of a MANET interface of this node and an
address of a MANET interface of one of its symmetric 1-hop neighbors,
where: where:
N_local_iface_addr is the address of the MANET interface of the local N_local_iface_addr is the address of the local MANET interface to
node to which the 1-hop neighbor has or had a symmetric link; which the 1-hop neighbor has or had a symmetric link;
N_neighbor_iface_addr is an address of a MANET interface of a 1-hop N_neighbor_iface_addr is an address of a MANET interface of a 1-hop
neighbor which is or was in this node's symmetric 1-hop neighbor which is or was a symmetric 1-hop neighbor of this node;
neighborhood;
N_SYM_time is the time until which the 1-hop neighbor is considered N_SYM_time is the time until which the 1-hop neighbor is considered
to be in this node's symmetric 1-hop neighborhood; to be a symmetric 1-hop neighbor;
N_time specifies when this Symmetric Neighborhood Tuple expires and
MUST be removed. N_time specifies when this Tuple expires and MUST be removed.
The status of the 1-hop neighbor, denoted N_STATUS, can be derived The status of the 1-hop neighbor, denoted N_STATUS, can be derived
based on the field L_SYM_time as defined in Table 2. based on the field L_SYM_time as defined in Table 2.
+-------------+-----------+ +-------------+-----------+
| N_SYM_time | N_STATUS | | N_SYM_time | N_STATUS |
+-------------+-----------+ +-------------+-----------+
| Expired | LOST | | Expired | LOST |
| | | | | |
| Not Expired | SYMMETRIC | | Not Expired | SYMMETRIC |
+-------------+-----------+ +-------------+-----------+
Table 2 Table 2
In a node, the set of Symmetric Neighbor Tuples is denoted the 5.3. Neighborhood Address Association Set
"Symmetric Neighbor Set".
3.3. Neighborhood Address Association Set
A node records a set of "Neighborhood Address Association Tuples", A node's Neighborhood Address Association Set records the MANET
recording information about the MANET interface configuration of its interface configuration of its 1-hop neighbors. It consists of
1-hop neighbors: Neighborhood Address Association Tuples:
(NA_neighbor_iface_addr_list, NA_time) (NA_neighbor_iface_addr_list, NA_time)
where:
NA_neighbor_iface_addr_list is a list of interface addresses of a NA_neighbor_iface_addr_list is a list of interface addresses of a
single 1-hop neighbor; single 1-hop neighbor;
NA_time specifies when this Neighborhood Address Association Tuple NA_time specifies when this Tuple expires and MUST be removed.
expires and MUST be removed.
In a node, the set of Neighborhood Address Association Tuples is
denoted the "Neighborhood Address Association Set".
3.4. 2-Hop Neighbor Set 5.4. 2-Hop Neighbor Set
A node records a set of "2-Hop Neighbor Tuples", recording A node's 2-Hop Neighbor Set records its symmetric 2-hop neighborhood.
information about a its symmetric 2-hop neighborhood: It consists of 2-Hop Neighbor Tuples:
(N2_local_iface_addr, N2_neighbor_iface_addr, N2_2hop_iface_addr, (N2_local_iface_addr, N2_neighbor_iface_addr, N2_2hop_iface_addr,
N2_time) N2_time)
each describing a symmetric link between an address of a MANET where:
interface of one of this node's symmetric 1-hop neighbors and an
address of a MANET interface of a node in this node's symmetric 2-hop
neighborhood.
N2_local_iface_addr is the address of the local MANET interface over
which the information defining this 2-Hop Neighbor Tuple was
received;
N2_neighbor_iface_addr is the address of the MANET interface address N2_local_iface_addr is the address of the local MANET interface on
of a symmetric 1-hop neighbor; which this information was received;
N2_2hop_iface_addr is the address of a MANET interface of a symmetric N2_neighbor_iface_addr is the address of the MANET interface of a
2-hop neighbor which has a symmetric link (not necessarily using symmetric 1-hop neighbor;
this address) to the node with MANET interface address
N2_neighbor_iface_addr;
N2_time specifies the time at which this 2-Hop Neighbor Tuple expires N2_2hop_iface_addr is the address of a MANET interface of a
and MUST be removed. symmetric 2-hop neighbor which has a symmetric link (using any
MANET interface) to the indicated symmetric 1-hop neighbor;
In a node, the set of 2-Hop Neighbor Tuples is denoted the "2-Hop N2_time specifies the time at which this Tuple expires and MUST be
Neighbor Set". removed.
4. Packets and Messages 6. Packets and Messages
The packet and message format used by this neighborhood discovery The packet and message format used by this neighborhood discovery
protocol is defined in [1], which is used with the following protocol is defined in [1], which is used with the following
considerations: considerations:
o this protocol specifies one message type, the HELLO message, in o this protocol specifies one message type, the HELLO message;
Section 4.1;
o HELLO message header options may be used as specified by the o HELLO message header options may be used as specified by the
protocol which uses this neighborhood discovery protocol; protocol which uses this neighborhood discovery protocol;
o HELLO messages are transmitted only one hop, i.e. MUST NOT be o HELLO messages MUST NOT be forwarded;
forwarded;
o multi-message packets may be created using other messages as o HELLO messages may be included in multi-message packets as
specified by the protocol which uses this neighborhood discovery specified in [1];
protocol;
o packet header options may be used as specified by the protocol o packet header options may be used as specified by the protocol
which uses this neighborhood discovery protocol. which uses this neighborhood discovery protocol.
4.1. HELLO Messages 6.1. HELLO Messages
A HELLO message MUST contain: A HELLO message MUST contain:
o a message TLV with Type == VALIDITY_TIME and Value == H_HOLD_TIME, o A VALIDITY_TIME message TLV as specified in Appendix C,
as specified in Section 4.1.2.1 representing time value (at distance one hop) H_HOLD_TIME, which
MUST NOT be less than REFRESH_INTERVAL. If HELLO messages may be
lost then H_HOLD_TIME SHOULD be a multiple of REFRESH_INTERVAL.
o an address block known as the Local Interface Block, as specified o An address block, and associated TLV block, known as the Local
in Section 4.1.1; other addresses MUST NOT be added to this Interface Block, as specified in Section 6.1.1.
address block.
A HELLO message MAY contain: A HELLO message which is transmitted at a regular interval SHOULD
contain, and otherwise MAY contain:
o a message TLV with Type == INTERVAL_TIME and Value == o An INTERVAL_TIME message TLV as specified in Appendix C,
HELLO_INTERVAL, as specified in Section 4.1.2.2; representing time value (at distance one hop) HELLO_INTERVAL.
o one or more address blocks with associated address block TLVs as A HELLO message MAY contain:
specified in Section 4.1.3; these address blocks contain current
or former 1-hop neighbors' MANET interface addresses with
associated TLVs. Other addresses (i.e. addresses of non-neighbor
nodes) MAY be added to these address blocks, however if they are
then these addresses MUST NOT have associated TLVs from the
address block TLVs specified in Section 4.1.3.
This protocol specifies two message TLVs and three address block TLVs o One or more address blocks, with associated address block TLVs,
used in HELLO messages in Section 4.1.2 and Section 4.1.3; other TLVs containing current or former 1-hop neighbors' MANET interface
MAY be included as specified by the protocol which uses this addresses. Other addresses (i.e. addresses of non-neighbor nodes)
neighborhood discovery protocol. MAY be included in these address blocks, but MUST NOT be
associated with any of the TLVs specified in Section 6.1.2.
4.1.1. Local Interface Block o Other message TLVs.
6.1.1. Local Interface Block
The first address block, plus following TLV block, in a HELLO message The first address block, plus following TLV block, in a HELLO message
is known as the Local Interface Block. The Local Interface Block is is known as the Local Interface Block. The Local Interface Block is
not distinguished in any way other than by being the first address not distinguished in any way other than by being the first address
block in the message. block in the message.
The first address of the Local Interface Block MUST contain the used The first address of the Local Interface Block MUST be the used
address of the interface over which the HELLO message is transmitted. address of the MANET interface over which the HELLO message is
If that interface has an associated prefix different from the length transmitted.
of the address, a PREFIX_LENGTH TLV MUST be associated with this
address. This first address, with associated prefix length, of the
Local Interface Block is henceforth denoted the "Source Address".
The Local Interface Block MUST contain all of the addresses of all of The Local Interface Block MUST contain all of the addresses of all of
the MANET interfaces of the originating node, using the standard the MANET interfaces of the originating node, and no other addresses.
<address-block> syntax specified in [1]. Those addresses, if any, Those addresses, if any, which correspond to MANET interfaces other
which correspond to MANET interfaces other than that on which the than that on which the HELLO message is transmitted MUST have a
HELLO message is transmitted MUST have a corresponding OTHER_IF TLV corresponding OTHER_IF TLV as specified in Section 6.1.2, other
as specified in Section 4.1.3, other addresses MUST NOT use this TLV. addresses (i.e. those of the MANET interface on which the HELLO
message is transmitted) MUST NOT use this TLV.
Note that a Local Interface Block MAY include more than one address Note that a Local Interface Block MAY include more than one address
for each MANET interface, and hence a HELLO message MAY contain more for each MANET interface, and hence a HELLO message MAY contain more
than one address without an OTHER_IF TLV. A Local Interface Block than one address without an OTHER_IF TLV.
MUST NOT contain any addresses which are not of MANET interfaces of
the originating node.
4.1.2. Message TLVs
This section specifies two message TLVs: VALIDITY_TIME and
INTERVAL_TIME.
4.1.2.1. VALIDITY_TIME TLV
All HELLO messages MUST include a VALIDITY_TIME TLV, specifying for
how long a node may, upon receiving a message, consider the message
content to be valid. The VALIDITY_TIME TLV, described in this
document, contains a single value since HELLO messages are
transmitted only one hop. Note that [1] specifies an extended
version of this VALIDITY_TIME TLV, which is compatible with the
format of the VALIDITY_TIME TLV in this specification.
The VALIDITY_TIME message TLV specification is given in Table 3.
+----------------+------+-------------------+----------------------+
| Name | Type | Length | Value |
+----------------+------+-------------------+----------------------+
| VALIDITY_TIME | TBD | 8 bits | <t_default> |
+----------------+------+-------------------+----------------------+
Table 3
where <t_default> is the period for which the information is valid,
represented as specified in Section 4.1.2.3.
4.1.2.2. INTERVAL_TIME TLV
HELLO messages MAY include an INTERVAL_TIME message TLV, specifying
the interval at which HELLO messages are being generated by the
originator node. Note that HELLO messages which are not part of a
regular schedule SHALL be ignored in defining the interval. If, for
whatever reason, HELLO messages are sent in an irregular pattern,
then this SHALL be the longest interval in that pattern.
The INTERVAL_TIME message TLV specification is given in Table 4.
+----------------+------+-------------------+----------------------+
| Name | Type | Length | Value |
+----------------+------+-------------------+----------------------+
| INTERVAL_TIME | TBD | 8 bits | <time> |
+----------------+------+-------------------+----------------------+
Table 4
where <time> is the scheduled maximum time until the next
transmission of a HELLO message by the originator node on the same
interface, represented as specified in Section 4.1.2.3.
4.1.2.3. Representing Time
Section 4.1.2.1 and Section 4.1.2.2 specify TLVs where time is
represented as a single octet. This is defined by the lowest four
bits of the octet representing the mantissa (a) and the highest four
bits of the octet representing the exponent (b) of the time as a
multiple of a fixed constant C, yielding that:
o time = C * (1 + a/16) * 2^b
where a is the integer represented by the four lowest bits of the
time field and b the integer represented by the four highest bits of
the time field. All nodes in the network MUST use the same value of
C, which will be specified in seconds, hence so will be all times
(see Section 7). Note that ascending values of the octet represent
ascending values of time, times may thus be compared by comparison of
octets.
An algorithm for computing the representation of time t is the
following:
1. find the largest integer b such that t/C >= 2^b;
2. set a = 16 * (t / (C * 2^b) - 1), rounded up to the nearest
integer;
3. if a == 16 then set b = b + 1 and set a = 0;
4. if a and b are in the range 0 and 15 then t can be represented by
an octet holding the value 16*b + a, otherwise it can not.
As examples, the values of 2 seconds and 6 seconds are represented by
(a=0, b=5) and (a=8, b=6), respectively, i.e., by the octets 80 and
104 (hexadecimal 50 and 68).
4.1.3. Address Block TLVs 6.1.2. Address Block TLVs
The three address block TLVs used in HELLO messages are specified in The three address block TLVs used in HELLO messages are specified in
Table 5. Table 3.
+----------------+------+-------------------+-----------------------+ +----------------+------+-------------------+-----------------------+
| Name | Type | Length | Value | | Name | Type | Length | Value |
+----------------+------+-------------------+-----------------------+ +----------------+------+-------------------+-----------------------+
| OTHER_IF | TBD | 0 bits | Not Applicable | | OTHER_IF | TBD | 0 bits | Not Applicable |
| | | | | | | | | |
| LINK_STATUS | TBD | 8 bits | One of LOST, | | LINK_STATUS | TBD | 8 bits | One of LOST, |
| | | | SYMMETRIC or HEARD. | | | | | SYMMETRIC or HEARD |
| | | | | | | | | |
| OTHER_NEIGHB | TBD | 8 bits | One of LOST or | | OTHER_NEIGHB | TBD | 8 bits | One of LOST or |
| | | | SYMMETRIC | | | | | SYMMETRIC |
+----------------+------+-------------------+-----------------------+ +----------------+------+-------------------+-----------------------+
Table 5 Table 3
5. HELLO Message Generation 7. HELLO Message Generation
HELLO messages MUST be generated and transmitted independently on HELLO messages MUST be generated and transmitted independently on
each MANET interface. The maximum interval between HELLO each MANET interface. If using the HELLO message interval
transmissions on the same MANET interface MUST NOT exceed HELLO_INTERVAL then, following a HELLO message transmission on a
HELLO_MIN_INTERVAL. Two successive HELLO message transmissions on MANET interface, another HELLO message MUST be sent on the same
the same MANET interface MUST be separated by at least interface after an interval not greater than HELLO_INTERVAL. Two
HELLO_MIN_INTERVAL. successive HELLO message transmissions on the same MANET interface
MUST be separated by at least HELLO_MIN_INTERVAL, except as noted in
Section 7.1.1.
Each HELLO message MUST include a Local Interface Block as specified A HELLO message MUST include a Local Interface Block as specified in
in Section 4.1.1 as its first address block. Section 6.1.1 as its first address block.
On its MANET interface with address Sending Address, a node MUST Other addresses which MUST be included in HELLO messages are:
report appropriate addresses with associated TLVs from the Link Set
and Symmetric Neighbor Set. These addresses, with their associated
TLVs, MAY be reported in any HELLO messages transmitted on that MANET
interface. All such addresses, with their associated TLVs, MUST be
reported in at least one HELLO message transmitted on that MANET
interface within every interval of length REFRESH_INTERVAL. These
addresses MUST NOT be included in the Local Interface Block, they MAY
be included in any other address block.
The addresses, with their associated TLVs, which MUST be included in o addresses of 1-hop neighbors from the Link Set;
HELLO messages over the local MANET interface with address Sending
Address, are computed thus:
1. For each Link Tuple with L_local_iface_addr == Sending Address, o addresses of 1-hop neighbors from the Symmetric Neighbor Set.
include:
* L_neighbor_iface_addr with an associated TLV with: These addresses MUST NOT be included in the Local Interface Block.
These addresses MAY be included in any HELLO messages sent on the
appropriate MANET interface. These addresses, and their associated
TLVs, are:
+ Type = LINK_STATUS; AND 1. For each address which appears as an L_neighbor_iface_addr in one
or more Link Tuples whose L_local_iface_addr is an address of the
MANET interface over which the HELLO message is to be sent,
include that L_neighbor_iface_addr with an associated TLV with:
+ Value = L_STATUS. * Type = LINK_STATUS; AND
* Value = L_STATUS.
2. For each address which appears as an N_neighbor_iface_addr in one 2. For each address which appears as an N_neighbor_iface_addr in one
or more Symmetric Neighbor Tuples: or more Symmetric Neighbor Tuples:
1. if this address has already been included with an associated 1. if this address has already been included with an associated
TLV with Type == LINK_STATUS and Value == SYMMETRIC, do not TLV with Type == LINK_STATUS and Value == SYMMETRIC, do not
add an associated TLV with Type == OTHER_NEIGHB; add an associated TLV with Type == OTHER_NEIGHB;
2. otherwise if, for one or more of these Symmetric Neighbor 2. otherwise if, for one or more of these Symmetric Neighbor
Tuples, N_STATUS == SYMMETRIC, then include this address with Tuples, N_STATUS == SYMMETRIC, then include this
associated TLV with: N_neighbor_iface_addr with an associated TLV with:
+ Type = OTHER_NEIGHB; AND + Type = OTHER_NEIGHB; AND
+ Value = SYMMETRIC; + Value = SYMMETRIC.
3. otherwise if, for all of these Symmetric Neighbor Tuples, 3. otherwise if, for all of these Symmetric Neighbor Tuples,
N_STATUS == LOST, and this address has not already been N_STATUS == LOST, and this address has not already been
included with an associated TLV with Type == LINK_STATUS and included with an associated TLV with Type == LINK_STATUS and
Value == LOST, then include this address with associated TLV Value == LOST, then include this N_neighbor_iface_addr with
with: an associated TLV with:
+ Type = OTHER_NEIGHB; AND + Type = OTHER_NEIGHB; AND
+ Value = LOST. + Value = LOST.
If an address is specified as included with more than one associated On each of its MANET interfaces, for each specified 1-hop neighbor
TLV, then these TLVs MAY be independently included or excluded from address and associated TLV, the address and associated TLV MUST be
HELLO messages as long as all are included with any interval of included in at least one HELLO message in every interval of length
length REFRESH_INTERVAL. TLVs applying to the same address MAY be REFRESH_INTERVAL.
applied to the same or different copies of the address in a given
HELLO message.
5.1. HELLO Message: Transmission If an address is specified with more than one associated TLV, then
these TLVs MAY be independently included or excluded from each HELLO
messages as long as each such TLV is included associated with that
address in a HELLO message sent on that MANET interface in every
interval of length REFRESH_INTERVAL.
TLVs associated with the same address included in the same HELLO
message MAY be applied to the same or different copies of that
address.
7.1. HELLO Message: Transmission
Messages are transmitted in the packet/message format specified by Messages are transmitted in the packet/message format specified by
[1] using the ALL-MANET-NEIGHBORS multicast address as destination IP [1] using the ALL-MANET-NEIGHBORS multicast address as destination IP
address and with the HELLO message Hop Limit = 1. address, and with the HELLO message hop limit = 1.
6. HELLO Message Processing If the parameters of the protocol are changed, then guarantees given
for the old values of the parameters MUST still be respected. In
particular:
On receiving a HELLO message, a node will update its neighborhood o If HELLO_INTERVAL is increased, then a HELLO message MUST be sent
information base according to the specification given in this within the old HELLO_INTERVAL of the previous HELLO message sent
section. on each MANET interface.
o If REFRESH_INTERVAL is increased, then all information (addresses
and associated TLVs) must be sent again on each MANET interface
within the old REFRESH_INTERVAL of the previous HELLO message that
included that information.
7.1.1. HELLO Message: Jitter
HELLO messages MAY be sent using periodic message generation or
externally triggered message generation. If using data link and
physical layers which are subject to packet loss due to collisions,
HELLO messages SHOULD be jittered as described in Appendix D.
Internally triggered message generation MAY be treated as if
externally generated message generation, or MAY be not jittered.
HELLO messages MUST NOT be forwarded, and thus message forwarding
jitter does not apply to HELLO messages.
Each form of jitter described in Appendix D requires a parameter
MAXJITTER. These parameters may be dynamic, and are specified by:
o For periodic message generation: HP_MAXJITTER, which MUST be
significantly less than HELLO_INTERVAL.
o For externally triggered message generation: HT_MAXJITTER. If
HELLO messages are also periodically generated then HT_MAXJITTER
also MUST be significantly less than HELLO_INTERVAL.
When HELLO message generation is delayed in order that a HELLO
message is not sent within HELLO_MIN_INTERVAL of the previous HELLO
message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
be reduced by jitter, with maximum reduction HP_MAXJITTER. In this
case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL.
8. HELLO Message Processing
On receiving a HELLO message, a node MUST update its neighborhood
information base.
For the purpose of this section, note the following definitions: For the purpose of this section, note the following definitions:
o the "validity time" of a message is calculated from the o the "validity time" of a message is calculated from the
VALIDITY_TIME TLV of the message as specified in Section 4.1.2.1; VALIDITY_TIME TLV of the message as specified in Appendix C;
o the "Source Address" is the first address, including prefix o the "Source Address" is the first address, including prefix
length, of the Local Interface Block in the HELLO message; length, of the Local Interface Block in the HELLO message;
o the "Receiving Address" is the address, including prefix length, o the "Receiving Address" is the address, including prefix length,
of the MANET interface on which the HELLO message was received; of the MANET interface on which the HELLO message was received;
o the word EXPIRED indicates that a timer is set to a value clearly o the word EXPIRED indicates that a timer is set to a value clearly
preceding the current time (e.g. current time - 1). preceding the current time (e.g. current time - 1).
6.1. Populating the Link Set 8.1. Populating the Link Set
On receiving a HELLO message, a node SHOULD update its Link Set: On receiving a HELLO message, a node SHOULD update its Link Set:
1. If there is no Link Tuple with: 1. If there is no Link Tuple with:
* L_local_iface_addr == Receiving Address; AND * L_local_iface_addr == Receiving Address; AND
* L_neighbor_iface_addr == Source Address, * L_neighbor_iface_addr == Source Address,
then create a new Link Tuple with then create a new Link Tuple with
skipping to change at page 20, line 25 skipping to change at page 19, line 24
(Value == HEARD or Value == SYMMETRIC) then: (Value == HEARD or Value == SYMMETRIC) then:
- L_SYM_time = current time + validity time; - L_SYM_time = current time + validity time;
- L_time = L_SYM_time + L_HOLD_TIME. - L_time = L_SYM_time + L_HOLD_TIME.
2. L_ASYM_time = current time + validity time; 2. L_ASYM_time = current time + validity time;
3. L_time = max(L_time, L_ASYM_time). 3. L_time = max(L_time, L_ASYM_time).
6.2. Populating the Symmetric Neighbor Set 8.2. Populating the Symmetric Neighbor Set
On receiving a HELLO message, a node SHOULD update its Symmetric On receiving a HELLO message, a node SHOULD update its Symmetric
Neighbor Set: Neighbor Set:
1. If the Receiving Address is in an address block of the HELLO 1. If the Receiving Address is in an address block of the HELLO
message, other than the Local Interface Block, with an associated message, other than the Local Interface Block, with an associated
TLV with Type == LINK_STATUS and (Value == HEARD or Value == TLV with Type == LINK_STATUS and (Value == HEARD or Value ==
SYMMETRIC) then: SYMMETRIC) then:
1. For each address (henceforth neighbor address) in the HELLO 1. For each address (henceforth neighbor address) in the HELLO
skipping to change at page 21, line 33 skipping to change at page 20, line 28
+ N_local_iface_addr == Receiving Address; AND + N_local_iface_addr == Receiving Address; AND
+ N_neighbor_iface_addr == neighbor address, + N_neighbor_iface_addr == neighbor address,
update this Symmetric Neighbor Tuple to have: update this Symmetric Neighbor Tuple to have:
+ N_SYM_time = EXPIRED; + N_SYM_time = EXPIRED;
+ N_time = min(N_time, current time + N_HOLD_TIME). + N_time = min(N_time, current time + N_HOLD_TIME).
6.3. Populating the Neighborhood Address Association Set 8.3. Populating the Neighborhood Address Association Set
On receiving a HELLO message, the node SHOULD update its Neighborhood On receiving a HELLO message, the node SHOULD update its Neighborhood
Address Association Set: Address Association Set:
1. Remove all Neighborhood Address Association Tuples where: 1. Remove all Neighborhood Address Association Tuples where:
* NA_neighbor_iface_addr_list contains at least one address * NA_neighbor_iface_addr_list contains at least one address
which is contained in the Local Interface Block of the which is contained in the Local Interface Block of the
received HELLO message, received HELLO message,
and create a new Neighborhood Address Association Tuple with: and create a new Neighborhood Address Association Tuple with:
* NA_neighbor_iface_addr_list = list of all addresses contained * NA_neighbor_iface_addr_list = list of all addresses contained
in the Local Interface Block of the received HELLO message; in the Local Interface Block of the received HELLO message;
* NA_time = current time + validity time. * NA_time = current time + validity time.
6.4. Populating the 2-Hop Neighbor Set 8.4. Populating the 2-Hop Neighbor Set
On receiving a HELLO message the node SHOULD update its 2-Hop On receiving a HELLO message the node SHOULD update its 2-Hop
Neighbor Set: Neighbor Set:
1. If there exists a Link Tuple with L_local_iface_addr == Source 1. If there exists a Link Tuple with L_local_iface_addr == Source
Address and L_STATUS == SYMMETRIC then: Address and L_STATUS == SYMMETRIC then:
1. For each address (henceforth 2-hop neighbor address) in an 1. For each address (henceforth 2-hop neighbor address) in an
address block of the HELLO message, other than the Local address block of the HELLO message, other than the Local
Interface Block, which is not an interface address of the Interface Block, which is not an interface address of the
skipping to change at page 23, line 8 skipping to change at page 22, line 4
- Type == LINK_STATUS and (Value == LOST or Value == - Type == LINK_STATUS and (Value == LOST or Value ==
HEARD); OR HEARD); OR
- Type == OTHER_NEIGHB and Value == LOST; - Type == OTHER_NEIGHB and Value == LOST;
then remove all 2-Hop Neighbor Tuples with: then remove all 2-Hop Neighbor Tuples with:
- N2_local_iface_addr == Receiving Address; AND - N2_local_iface_addr == Receiving Address; AND
- N2_neighbor_iface_addr == Source Address; AND - N2_neighbor_iface_addr == Source Address; AND
- N2_2hop_iface_addr == 2-hop neighbor address. - N2_2hop_iface_addr == 2-hop neighbor address.
6.5. Neighborhood Changes 8.5. Neighborhood Changes
If the L_SYM_time field of a Link Tuple expires (either due to timing If the L_SYM_time field of a Link Tuple expires (either due to timing
out, or as a result of processing a TLV with Type == LINK_STATUS and out, or as a result of processing a TLV with Type == LINK_STATUS and
Value == LOST) then all 2-Hop Neighbor Tuples with: Value == LOST) then all 2-Hop Neighbor Tuples with:
o N2_local_iface_addr == L_local_iface_addr from the Link Tuple, o N2_local_iface_addr == L_local_iface_addr from the Link Tuple,
AND; AND;
o N2_neighbor_iface_addr == L_neighbor_iface_addr from the Link o N2_neighbor_iface_addr == L_neighbor_iface_addr from the Link
Tuple, Tuple,
MUST be deleted. MUST be deleted.
In this, or any other case of neighborhood change, a node MAY send a In this, or any other case of neighborhood change, a node MAY send a
HELLO message reporting updated information. If a node does send HELLO message reporting updated information, subject to the
such a HELLO message the node MUST ensure that any two successive constraints in Section 7.
HELLO messages are separated by at least HELLO_MIN_INTERVAL.
7. Proposed Values for Constants 9. Proposed Values for Constants
This section list the values for the constants used in the This section lists proposed values for the constants used in the
description of the protocol. specification of the protocol.
7.1. Message Intervals 9.1. Message Intervals
o HELLO_INTERVAL = 2 seconds o HELLO_INTERVAL = 2 seconds
o REFRESH_INTERVAL = HELLO_INTERVAL o REFRESH_INTERVAL = HELLO_INTERVAL
o HELLO_MIN_INTERVAL = HELLO_INTERVAL/4 o HELLO_MIN_INTERVAL = HELLO_INTERVAL/4
7.2. Holding Times 9.2. Holding Times
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
o N_HOLD_TIME = H_HOLD_TIME o N_HOLD_TIME = H_HOLD_TIME
7.3. Time 9.3. Jitter Times
o C = 0.0625 seconds (1/16 second) o HP_MAXJITTER = HELLO_INTERVAL/4
o HT_MAXJITTER = HELLO_INTERVAL/4
9.4. Time
o C = 0.0625 second (1/16 second)
In order to achieve interoperability, C MUST be the same on all In order to achieve interoperability, C MUST be the same on all
nodes. nodes.
8. IANA Considerations 10. IANA Considerations
8.1. Multicast Addresses 10.1. Multicast Addresses
A well-known multicast address, ALL-MANET-NEIGHBORS, must be A well-known link-local multicast address, ALL-MANET-NEIGHBORS, must
registered and defined for both IPv6 and IPv4. The addressing scope be registered and defined for both IPv6 and IPv4.
is link-local, i.e. this address is similar to the all nodes/routers
multicast address of IPv6 in that it targets all MANET nodes adjacent
to the originator of an IP datagram.
8.2. Message Types 10.2. 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] from the "Assigned Message Types" repository of [1].
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description | | Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| HELLO | TBD | Local Signaling | | HELLO | TBD | Local signaling |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
Table 6 Table 4
8.3. TLV Types 10.3. TLV Types
This specification defines two Message TLV types, which must be This specification defines two Message TLV types, which must be
allocated from the "Assigned Message TLV Types" repository of [1] allocated from the "Assigned Message TLV Types" repository of [1].
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description | | Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| VALIDITY_TIME | TBD | The time (in seconds) from receipt | | VALIDITY_TIME | TBD | The time (in seconds) from receipt |
| | | of the message during which the | | | | of the message during which the |
| | | information contained in the message | | | | information contained in the message |
| | | is to be considered valid | | | | is to be considered valid |
| | | | | | | |
| INTERVAL_TIME | TBD | The maximum time (in seconds) | | INTERVAL_TIME | TBD | The maximum time (in seconds) |
| | | between two successive transmissions | | | | between two successive transmissions |
| | | of messages of the appropriate type | | | | of messages of the appropriate type |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
Table 7 Table 5
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] of [1].
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description | | Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| OTHER_IF | TBD | Specifies that the address, in the | | OTHER_IF | TBD | Specifies that the address, in the |
| | | Local Interface Block of the | | | | Local Interface Block of the |
| | | message, is an address associated | | | | message, is an address associated |
| | | with a MANET interface other than | | | | with a MANET interface other than |
| | | the one on which the message is | | | | the one on which the message is |
| | | transmitted | | | | transmitted |
| | | | | | | |
| LINK_STATUS | TBD | Specifies a given link's status | | LINK_STATUS | TBD | Specifies the status of the link to |
| | | (LOST, SYMMETRIC or HEARD) | | | | the indicated address (LOST, |
| | | SYMMETRIC or HEARD) |
| | | | | | | |
| OTHER_NEIGHB | TBD | Specifies that the address is, or | | OTHER_NEIGHB | TBD | Specifies that the address is |
| | | was, of a MANET interface of a | | | | (SYMMETRIC) or was (LOST) of a MANET |
| | | symmetric 1-hop neighbor of the node | | | | interface of a symmetric 1-hop |
| | | transmitting the HELLO message, but | | | | neighbor of the node transmitting |
| | | does not have a matching or better | | | | the HELLO message, but does not have |
| | | LINK_STATUS TLV | | | | a matching or better LINK_STATUS TLV |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
Table 8 Table 6
8.4. LINK_STATUS and OTHER_NEIGHB Values 10.4. LINK_STATUS and OTHER_NEIGHB Values
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
9. References 11. References
9.1. Normative References 11.1. Normative References
[1] Clausen, T., Dean, J., Dearlove, C., 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-01.txt, June 2006. Progress draft-ietf-manet-packetbb-03.txt, January 2007.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] 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.
9.2. Informative References 11.2. Informative References
[3] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized Link
State Routing Protocol version 2", Work In
Progress draft-ietf-manet-olsrv2-02.txt, June 2006.
[4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [3] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
[5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Appendix A. Address Block TLV Combinations
Addressing Architecture", RFC 3513, April 2003.
Appendix A. Heuristics for Generating HELLO Messages
The algorithm for generating HELLO messages in Section 5 specifies The algorithm for generating HELLO messages in Section 7 specifies
which addresses MAY be included in the address blocks after the Local which addresses MAY be included in the address blocks after the Local
Interface Block, and with which associated TLVs. These TLVs may have Interface Block, and with which associated TLVs. These TLVs may have
Type == LINK_STATUS or Type == OTHER_NEIGHB, or both. TLVs with Type Type == LINK_STATUS or Type == OTHER_NEIGHB, or both. TLVs with Type
== LINK_STATUS may have three possible values (Value == HEARD, Value == LINK_STATUS may have three possible values (Value == HEARD, Value
== SYMMETRIC or Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may == SYMMETRIC or Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may
have two possible values (Value == SYMMETRIC or Value == LOST). When have two possible values (Value == SYMMETRIC or Value == LOST). When
both TLVs are associated with the same address only certain both TLVs are associated with the same address only certain
combinations of these TLV values are necessary, and are the only combinations of these TLV values are necessary, and are the only
combinations generated by the algorithm in Section 5. These combinations generated by the algorithm in Section 7. These
combinations are indicated in Table 9. combinations are indicated in Table 7.
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 5. Cells labeled with "No" generated by the algorithm in Section 7. Cells labeled with "No"
indicate combinations not generated by the algorithm in Section 5, indicate combinations not generated by the algorithm in Section 7,
but which are correctly parsed and interpreted by the algorithm in but which are correctly parsed and interpreted by the algorithm in
Section 6. Section 8.
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | Type == | Type == | Type == | | | Type == | Type == | Type == |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value == | Value == LOST | | | (absent) | Value == | Value == LOST |
| | | SYMMETRIC | | | | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| Type == | No | Yes | Yes | | Type == | No | Yes | Yes |
| LINK_STATUS | | | | | LINK_STATUS | | | |
| (absent) | | | | | (absent) | | | |
skipping to change at page 28, line 49 skipping to change at page 27, line 49
| Type == | Yes | No | No | | Type == | Yes | No | No |
| LINK_STATUS, | | | | | LINK_STATUS, | | | |
| Value == | | | | | Value == | | | |
| SYMMETRIC | | | | | SYMMETRIC | | | |
| | | | | | | | | |
| Type == | Yes | Yes | No | | Type == | Yes | Yes | No |
| LINK_STATUS, | | | | | LINK_STATUS, | | | |
| Value == LOST | | | | | Value == LOST | | | |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
Table 9 Table 7
In creating the HELLO message there are three stages:
1. collect the addresses into groups, each of which will form an
address block (this heuristic assumes that each address will be
included only once in a HELLO message, and that all TLVs
associated with it are included);
2. order the addresses in each group for most efficient TLV
association;
3. add the TLVs in the most efficient manner, whether single or
multiple value.
There is no straightforward way to perform these steps to create the
most optimal (smallest) HELLO message. Instead the following
heuristics may be considered:
1. The easiest approach to grouping addresses is to put them all in
a single address block. Separate address blocks are appropriate
when addresses have significantly different initial (head) bit
sequences, and the address compression in the address block
construction can be more efficient when addresses with different
initial sequences can be compressed separately, gaining more than
the overhead of multiple address blocks. Separate address blocks
have a lower overhead when either they use different TLVs, or
when they use multivalue TLVs. The simplest heuristic is to use
a single address block, unless addresses may be divided into one
or more subnets, especially if these are associated with
different MANET interfaces and hence each uses either LINK_STATUS
or OTHER_NEIGHB TLVs, but not both.
2. Grouping addresses that use a single TLV is straightforward, so
that each TLV type and value may be applied to a continuous
sequence of addresses. This can be extended to cover the case
where addresses have more than one TLV. An example of how to
order all TLV combinations so that each TLV type and value is
applied to a continuous sequence of addresses is given. (This
order is not unique.)
* Type == LINK_STATUS, Value == LOST.
* Type == LINK_STATUS, Value == LOST and Type == OTHER_NEIGHB,
Value == SYMMETRIC.
* Type == OTHER_NEIGHB, Value == SYMMETRIC.
* Type == LINK_STATUS, Value == HEARD and Type == OTHER_NEIGHB,
Value == SYMMETRIC.
* Type == LINK_STATUS, Value == HEARD.
* Type == LINK_STATUS, Value == HEARD and Type == OTHER_NEIGHB,
Value == LOST.
* Type == OTHER_NEIGHB, Value == LOST.
* Type == LINK_STATUS, Value == SYMMETRIC.
This order is not appropriate when multiple value TLVs are to be
used, then it is more important to group all TLVs of the same
type together, even when having different values. A possible
ordering is
* Type == LINK_STATUS, Value == HEARD.
* Type == LINK_STATUS, Value == SYMMETRIC.
* Type == LINK_STATUS, Value == LOST.
* Type == LINK_STATUS, Value == HEARD and Type == OTHER_NEIGHB,
Value == SYMMETRIC.
* Type == LINK_STATUS, Value == HEARD and Type == OTHER_NEIGHB,
Value == LOST.
* Type == LINK_STATUS, Value == LOST and Type == OTHER_NEIGHB,
Value == SYMMETRIC.
* Type == OTHER_NEIGHB, Value == SYMMETRIC.
* Type == OTHER_NEIGHB, Value == LOST.
Where one TLV type uses single values and the other multiple
values, appropriate orderings can be devised.
3. When there are many addresses in an address block, the most
efficient way to add TLVs is as up to five single value TLVs,
each with a single octet value field. When there are few
addresses in an address block, the most efficient way to add TLVs
is as up to two multiple value TLVs, with one octet of value per
address each. It may be appropriate to use one approach for each
TLV type. It is relatively straightforward to estimate the cost
of each approach (adding TLV type, semantics, length and index
overheads per TLV, and either one octet per value or per address
as appropriate) and to select the probably lower cost approach.
Alternatively a single decision based on the expected number of
1-hop neighbor addresses may be made.
Appendix B. HELLO Message Example Appendix B. HELLO Message Example
A simple example HELLO message, sent by an originator node with a An example HELLO message, sent by an originator node with a single
single MANET interface, is as follows. The message uses IPv4 (four MANET interface, is as follows. The message uses IPv4 (four octet)
octet) addresses without prefix TLVs, i.e. with all addresses having addresses without prefix TLVs. The message is sent with a full
maximum length prefixes. The message is sent with a full message message header (message semantics octet is 0) with a hop limit of 1
header (message semantics octet is 0) with a hop limit of 1 and a hop and a hop count of 0. The overall message length is 50 octets.
count of 0. The overall message length is 48 octets (it does not
need padding).
The message has 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 4, indicating no INTERVAL_TIME. Each uses a TLV with semantics value 4, indicating
start and stop indexes are included, and each has a value length of 1 that no start and stop indexes are included, and each has a value
octet. The values included (0x68 and 0x50) represent the default length of 1 octet. The values included (0x68 and 0x50) are time
values of 6 seconds and 2 seconds, respectively. codes representing the default values of parameters H_HOLD_TIME and
HELLO_INTERVAL, respectively (6 seconds and 2 seconds).
The first address block contains 1 local interface address, with head The first address block contains 1 local interface address. The
length 4 and no address tail or mid parts. This address block has no semantics octet value 2 indicates no address tail, and the head
TLVs (TLV block content length 0 octets). length of 4 octets indicates no address mid sections. This address
block has no TLVs (TLV block content length 0 octets).
The second, and last, address block contains 4 neighbor interface The second, and last, address block contains 4 neighbor interface
addresses, with head length 3 octets, no address tail part and each addresses. The semantics octet value 2 indicates no address tail,
address mid part having length one octet. The following TLV block the head length of 3 octets indicates address mid sections of one
(content length 7 octets) includes one TLV which reports the link octet each. The following TLV block (content length 7 octets)
status of all neighbors in a single multivalue TLV: the first two includes one LINK_STATUS TLV which reports the link status values of
all reported neighbors in a single multivalue TLV: the first two
addresses are HEARD, the third address is SYMMETRIC and the fourth addresses are HEARD, the third address is SYMMETRIC and the fourth
address is LOST. The TLV semantics value of 12 indicates, in address is LOST. The TLV semantics value of 20 indicates, in
addition to that this is a multivalue TLV, that no start and stop addition to that this is a multivalue TLV, that no start and stop
indexes are included, since values for all addresses are included. indexes are included, since values for all addresses are included.
The TLV value length of 4 octets indicates one octet per value per The TLV value length of 4 octets indicates one octet per value per
address. 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 0 0| | HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | 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 0 1 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 0 1 0 0| |0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| |0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head | |0 0 0 0 0 1 0 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 1| | 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head | Mid | |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid | Mid |0 0 0 0 0 0 0 0| | Head (cont) | Mid | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 0 1 1 0 0|0 0 0 0 0 1 0 0| | Mid |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HEARD | HEARD | SYMMETRIC | LOST | |0 0 0 1 0 1 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYMMETRIC | LOST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix C. Security Considerations Appendix C. Time TLVs
This appendix specifies a general time TLV structure for expressing
either single time values or a set of time values with each value
associated with a range of distances. Furthermore, using this
general time TLV structure, this document specifies the INTERVAL_TIME
and VALIDITY_TIME TLVs, which are used by NHDP.
C.1. Representing Time
This document specifies a TLV structure in which time values are each
represented in an 8 bit time code, one or more of which may be used
in a TLV's value field. Of these 8 bits, the least significant four
bits represent the mantissa (a), and the most significant four bits
represent the exponent (b), so that:
o time value = (1 + a/16) * 2^b * C
o time code = 16 * b + a
All nodes in the network MUST use the same value of C, which will be
specified in seconds, hence so will be all time values. Note that
ascending values of the time code represent ascending time values,
time values may thus be compared by comparison of time codes.
An algorithm for computing the time code representing the smallest
representable time value not less than the time value t is:
1. find the largest integer b such that t/C >= 2^b;
2. set a = 16 * (t / (C * 2^b) - 1), rounded up to the nearest
integer;
3. if a == 16 then set b = b + 1 and set a = 0;
4. if a and b are in the range 0 and 15 then the required time value
can be represented by the time code 16 * b + a, otherwise it can
not.
The minimum time value that can be represented in this manner is C.
The maximum time value that can be represented in this manner is
63488 * C.
C.2. General Time TLV Structure
A Time TLV may be a packet, message or address block TLV. If it is a
packet or message TLV then it must be a single value TLV as defined
in [1]; if it is an address block TLV then it may be single value or
multivalue TLV. The specific Time TLVs specified in this document,
in Appendix C.3 are message, and hence single value, TLVs. Note that
even a single value Time TLV may contain a multiple octet <value>
field.
The purpose of a single value Time TLV is to allow a single time
value to be determined by a node receiving an entity containing the
Time TLV, based on its distance from the entity's originator. The
Time TLV may contain information that allows that time value to be a
function of distance, and thus different receiving nodes may
determine different time values. If a receiving node will not be
able to determine its distance from the originating node, then the
form of this Time TLV with a single time code in a <value> field (or
single value subfield) SHOULD be used.
The <value> field of a single value Time TLV is specified, using the
regular expression syntax of [1], by:
<value> = {<time><distance>}*<time>
where:
<time> is an 8 bit field containing a time code as defined in
Appendix C.1.
<distance> is an 8 bit field specifying a distance from the message
originator, in hops.
A single value <value> field thus consists of an odd number of
octets; with a repetition factor of n in the regular expression
syntax it contains 2n+1 octets, thus the <length> field of a single
value Time TLV, which MUST always be present, is given by:
o <length> = 2n+1
A single value <value> field may be thus represented by:
<t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default>
<d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence.
Then, at the receiving node's distance from the originator node, the
time value indicated is that represented by the time code:
o <t_1>, if n > 0 and distance <= <d_1>;
o <t_i+1>, if n > 1 and <d_i> < distance <= <d_i+1> for some i such
that 1 <= i < n;
o <t_default> otherwise, i.e. if n == 0 or distance > <d_n>.
In a multivalue Time TLV, each single value subfield of the
multivalue Time TLV is defined as above. Note that [1] requires that
each single value subfield has the same length (i.e. the same value
of n) but they need not use the same values of <d_1> to <d_n>.
C.3. Message TLVs
Two message TLVs are defined, for signaling message validity time
(VALIDITY_TIME) and message interval (INTERVAL_TIME).
C.3.1. VALIDITY_TIME TLV
A VALIDITY TIME TLV is a message TLV that defines the validity time
of the information carried in the message in which the TLV is
contained. After this time the receiving node MUST consider the
message content to no longer be valid (unless repeated in a later
message). The validity time of a message MAY be specified to depend
on the distance from its originator. (This is appropriate if
messages are sent with different hop limits, so that receiving nodes
at greater distances receive information less frequently and must
treat is as valid for longer.)
A VALIDITY_TIME TLV is an example of a Time TLV specified as in
Appendix C.1.
C.3.2. INTERVAL_TIME TLV
An INTERVAL_TIME TLV is a message TLV that defines the maximum time
before another message of the same type as this message from the same
originator should be received. This interval time MAY be specified
to depend on the distance from the originator. (This is appropriate
if messages are sent with different hop limits, so that receiving
nodes at greater distances have an increased interval time.)
An INTERVAL_TIME TLV is an example of a Time TLV specified as in
Appendix C.1.
Appendix D. Message Jitter
Since NHDP employs periodic message transmission in order to detect
neighborhoods, and since NHDP is a building block for MANET routing
protocols employing other triggered or periodic message exchanges,
this appendix presents global concerns pertaining to jittering of
MANET control traffic.
D.1. Jitter
In order to prevent nodes in a MANET from simultaneous transmission,
whilst retaining the MANET characteristic of maximum node autonomy, a
randomization of the transmission time of packets by nodes, known as
jitter, may be employed. Note that while jitter may resolve the
problem of simultaneous transmissions, the delays it introduces will
otherwise only have a negative impact on a well-designed protocol.
Thus jitter parameters should always be minimized, subject to their
acceptably achieving their intent. Three jitter mechanisms, which
target different aspects of this problem, may be employed, with the
aim of reducing the likelihood of simultaneous transmission, and, if
it occurs, preventing it from continuing.
Three cases exist:
o Periodic message generation;
o Externally triggered message generation;
o Message forwarding.
D.1.1. Periodic message generation
When a node generates a message periodically, two successive messages
will be separated by a well-defined interval, denoted here
MESSAGE_INTERVAL. A node may maintain more than one such interval,
e.g. for different message types or in different circumstances (such
as backing off transmissions to avoid congestion). Jitter may be
applied by reducing this delay by a random amount, so that the delay
between consecutive transmissions of a messages of the same type is
equal to (MESSAGE_INTERVAL - jitter), where jitter is the random
value.
Subtraction of the random value from the message interval ensures
that the message interval never exceeds the nominal message interval,
and does not adversely affect timeouts or other mechanisms which may
be based on message late arrival or failure to arrive. Note that by
basing the message transmission time on the previous transmission
time, rather than by jittering a fixed clock, nodes can become
completely desynchronized, which minimizes their probability of
collisions.
It is appropriate and convenient for the jitter value to be taken
from a uniform distribution between zero and a maximum value, denoted
here MAXJITTER. MAXJITTER must be significantly less than the
current value of MESSAGE_INTERVAL. MAXJITTER may be a single fixed
parameter (in which case it must be significantly less than all
values of MESSAGE_INTERVAL) or be based on MESSAGE_INTERVAL (for
example it may be a fixed proportion of MESSAGE_INTERVAL).
Note that a node will know its own MESSAGE_INTERVAL value and can
readily ensure that any MAXJITTER value used is appropriate.
D.1.2. Externally triggered message generation
When a node responds to an externally triggered change in
circumstances which is likely to also affect other nodes by
generating a message, that message may be jittered by delaying it by
a random duration. If this message is of a type which is
periodically transmitted then it may be appropriate to restart its
schedule of these messages, this should be based on this delayed
time. In some cases there may be a minimum interval between such
messages, in this case it may be appropriate to jitter that minimum
interval time.
The normal delay on a triggered message may be generated uniformly in
an interval between zero and a maximum delay, denoted here MAXJITTER.
Selection of MAXJITTER will be protocol specific. In some cases the
delay may be fixed, or fixed according to the message type. In the
case of a regularly scheduled message, at an interval denoted here
MESSAGE_INTERVAL, MAXJITTER must be significantly less than
MESSAGE_INTERVAL. This may require prior agreement as to the value
(or minimum value) of MESSAGE_INTERVAL, be by inclusion of
MESSAGE_INTERVAL (the time until the next relevant message, rather
than the time since the last) in the message, or use any other
protocol specific mechanism.
D.1.3. Message forwarding
When a node forwards a message it may be jittered by delaying it by a
random time. The normal delay on a triggered message may be
generated uniformly in an interval between zero and a maximum delay,
denoted here MAXJITTER. The value of MAXJITTER will be protocol
specific and may in some cases be fixed, possibly by message type.
However in the case of a regularly scheduled message, at an interval
denoted here MESSAGE_INTERVAL, MAXJITTER must be significantly less
than MESSAGE_INTERVAL. This may require prior agreement as to the
value (or minimum value) of MESSAGE_INTERVAL, may be by inclusion in
the message of MESSAGE_INTERVAL (the time until the next relevant
message, rather than the time since the last message) or be by any
other protocol specific mechanism. The choice of MAXJITTER may also
take into account the expected number of times that the message may
be forwarded.
For several possible reasons (differing parameters, message
rescheduling, extreme random values) a node may receive a message
while still waiting to forward an earlier message of the same type
originating from the same node. This is possible without jitter, but
may occur more often with it. The appropriate action to take is
protocol specific (typically to discard the earlier message or to
forward both, possible modifying timing to maintain message order).
In many cases, including [3] and protocols using the full
functionality of [1], messages are transmitted hop by hop in
potentially multi-message packets, and some or all of those messages
may need to be forwarded. For efficiency this should be in a single
packet, and hence the forwarding jitter of all messages received in a
single packet should be the same. For this to have the intended
distribution it is necessary to choose a single random jitter for all
messages. It is not appropriate to give each message a random jitter
and then using the smallest of these jitter values, as that produces
a jitter with a reduced mean value.
In addition, the protocol may permit messages received in different
packets to be combined, possibly also with locally generated messages
(scheduled or triggered). However in this case the purpose of the
jitter will be accomplished by choosing any of the independently
scheduled times for these events as the single forwarding time; this
may have to be the earliest time to achieve all constraints. This is
because without combining messages, a transmission was due at this
time anyway.
Appendix E. Utilizing Link Layer Information
The interface between NHDP and any protocol(s) using NHDP is through
the Neighborhood Information Base as defined in Section 5. The
message exchange and associated processing specified in Section 7 and
Section 8 allow fully maintaining this Neighborhood Information Base.
Different link layers, and even different implementations of the same
link layer, may make varying amount of information available
describing local connectivity. If present, such link layer
information MAY be used to supplement, or replace, elements of NHDP
as follows:
No link layer information - Absent any link layer information on a
MANET interface, NHDP MUST be employed for populating all sets of
the Neighborhood Information Base as defined in this
specification.
Failed data delivery - If link layer information is available on a
MANET interface, identifying when data delivery to a presumed
directly connected node has failed, NHDP MUST be employed for
populating all sets of the Neighborhood Information Base as
defined in this specification. The link layer information MAY be
used to degrade a presumed directly connected node from being
considered as SYMMETRIC to being considered HEARD or LOST. A
HELLO message reflecting these changes MAY be generated,
respecting the considerations in Section 7.
Link quality information - The link layer may make available "soft"
information (possibly derived from the physical layer) relating to
the link quality. NHDP MAY be able to use this information, in a
normalized form, to adjust the link status between LOST, HEARD and
SYMMETRIC.
Local (1-hop) connectivity - If link layer information is available
on a MANET interface, identifying the local (1-hop) connectivity
via that interface, then this information MAY be used as follows
when generating HELLO messages over that interface:
* Step 1 in Hello Message Generation (Section 7) MAY be ignored.
This implies that local connectivity verification over that
MANET interface is not performed by NHDP, but is using the link
layer information.
* All other steps in Hello Message Generation (Section 7) MUST be
carried out, such that Neighborhood Address Association Sets
and 2-Hop Neighbor Sets can be populated correctly.
* All MANET interfaces which do not have local (1-hop)
connectivity information available MUST employ the message
exchange as detailed in this specification.
Appendix F. Security Considerations
The objective of this protocol is to allow each node in the network The objective of this protocol is to allow each node in the network
to acquire information describing its 1-hop and symmetric 2-hop to acquire information describing its 1-hop and symmetric 2-hop
neighborhoods. This is acquired through periodic message exchange neighborhoods. This is acquired through message exchange between
between neighboring nodes, and the information is made available neighboring nodes. The information is made available through a
through a collection of sets, describing the node's 1-hop collection of sets, describing the node's 1-hop neighborhood and
neighborhood and symmetric 2-hop neighborhood. symmetric 2-hop neighborhood.
Under normal circumstances, the information recorded in these sets is Under normal circumstances, the information recorded in these sets is
correct - i.e. corresponds to the actual network topology, apart from correct - i.e. corresponds to the actual network topology, apart from
any changes which have not (yet) been tracked by the HELLO message any changes which have not (yet) been tracked by the HELLO message
exchanges. If some node for some reason, malice or malfunction, exchanges.
inject invalid HELLO messages, incorrect information may be recorded
in the sets maintained. If some node for some reason, malice or malfunction, injects invalid
HELLO messages, incorrect information may be recorded in the sets
maintained. The exact consequence of this inexactness depends on the
use of these sets, and MUST be explicitly 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 F.1. Invalid HELLO messages
A correctly formed, but still invalid, HELLO message may take any of A correctly formed, but still invalid, HELLO message may take any of
the following forms: the following forms:
1. The Local Interface Block of the HELLO message may contain A node may lie about its own identity:
* The Local Interface Block of the HELLO message may contain
addresses which do not correspond to addresses of MANET addresses which do not correspond to addresses of MANET
interfaces of the local node which transmits the HELLO message; interfaces of the local node which transmits the HELLO message;
2. The Local Interface Block of the HELLO message may omit * The Local Interface Block of the HELLO message may omit
addresses of MANET interfaces of the local node which transmits addresses of MANET interfaces of the local node which transmits
the HELLO message; the HELLO message;
3. The Local Interface Block may contain OTHER_IF TLVs, indicating * The Local Interface Block may contain OTHER_IF TLVs, indicating
incorrectly that an address is associated with a MANET interface incorrectly that an address is associated with a MANET
other than the one over which the HELLO message is being interface other than the one over which the HELLO message is
transmitted; being transmitted;
4. The Local Interface Block may omit OTHER_IF TLVs, thereby * The Local Interface Block may omit OTHER_IF TLVs, thereby
indicating incorrect addresses associated with the MANET indicating incorrect addresses associated with the MANET
interface over which the HELLO message is being transmitted; interface over which the HELLO message is being transmitted;
A node may lie about the identity of other nodes:
5. A present or absent address in an address block, other than in * A present or absent address in an address block, other than in
the Local Interface Block, does not in and by itself cause a the Local Interface Block, does not in and by itself cause a
problem. It is the presence, absence or incorrectness of problem. It is the presence, absence or incorrectness of
associated LINK_STATUS and OTHER_NEIGHB TLVs that cause associated LINK_STATUS and OTHER_NEIGHB TLVs that cause
problems; problems;
6. A present LINK_STATUS TLV may, incorrectly, identify an address * A present LINK_STATUS TLV may, incorrectly, identify an address
as being of a node which is or was in the sending node's 1-hop as being of a node which is or was in the sending node's 1-hop
neighborhood; neighborhood;
7. A consistently absent LINK_STATUS TLV may, incorrectly, fail to * A consistently absent LINK_STATUS TLV may, incorrectly, fail to
identify an address as being of a node which is or was in the identify an address as being of a node which is or was in the
sending node's 1-hop neighborhood; sending node's 1-hop neighborhood;
8. A present OTHER_NEIGHB TLV may, incorrectly, identify an address * A present OTHER_NEIGHB TLV may, incorrectly, identify an
as being of a node which is or was in the sending node's address as being of a node which is or was in the sending
symmetric 1-hop neighborhood; node's symmetric 1-hop neighborhood;
9. A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail to * A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail
identify an address as being of a node which is or was in the to identify an address as being of a node which is or was in
sending node's symmetric 1-hop neighborhood; the sending node's symmetric 1-hop neighborhood;
10. The value of a LINK_STATUS or OTHER_NEIGHB TLV may incorrectly * The value of a LINK_STATUS or OTHER_NEIGHB TLV may incorrectly
indicate the status (LOST, SYMMETRIC, HEARD) of a 1-hop indicate the status (LOST, SYMMETRIC, HEARD) of a 1-hop
neighbor. neighbor.
Appendix D. Flow and Congestion Control Appendix G. Flow and Congestion Control
This document specifies one message type, HELLO messages. The size This document specifies one message type, the HELLO message. The
of each complete HELLO message is proportional to the size of the size of each complete HELLO message is proportional to the size of
transmitting node's 1-hop neighborhood (this information may be sent the originating node's 1-hop neighborhood; some or all of this
distributed across multiple interfaces). HELLO messages MUST NOT be information on each of the node's MANET interfaces. HELLO messages
forwarded. MUST NOT be 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. Thus, this of its MANET interfaces at least each REFRESH_INTERVAL. Thus, this
puts a lower bound on the control traffic, which each node employing puts a lower bound on the control traffic generated by each node in
this neighborhood discovery protocol in the network generates. the network employing this neighborhood discovery 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.
Thus, this puts an upper bound on the control traffic, which each (If using jitter then this may be reduced to a mean minimum value of
node employing this neighborhood discovery protocol in the network HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound
generates. on the control traffic generated by each node in the network
employing this neighborhood discovery protocol.
In order for the protocol to function, each node in the network MUST
employ the HELLO signaling as described in this specification.
Appendix E. Contributors Appendix H. 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 Emmanuel Baccelli, Hitachi Labs Europe, France,
<Emmanuel.Baccelli@inria.fr> <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, PCRI, France, <T.Clausen@computer.org> 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 F. Acknowledgements Appendix I. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, The authors would like to acknowledge the team behind OLSRv1,
specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent specified in RFC3626, for their contributions.
Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced
Research in Engineering, Pakistan) 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), Song-Yean Cho (Samsung Software Center) and the entire IETF Systems), and the entire IETF MANET working group.
MANET working group.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
skipping to change at page 39, line 5 skipping to change at page 44, line 5
Justin W. Dean Justin W. Dean
Naval Research Laboratory Naval Research Laboratory
Phone: +1 202 767 3397 Phone: +1 202 767 3397
Email: jdean@itd.nrl.navy.mil Email: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/ URI: http://pf.itd.nrl.navy.mil/
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 39, line 29 skipping to change at page 44, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 187 change blocks. 
680 lines changed or deleted 864 lines changed or added

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