Internet DRAFT - draft-clausen-manet-olsrv2nd
draft-clausen-manet-olsrv2nd
Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Informational C. Dearlove
Expires: October 12, 2006 BAE Systems Advanced Technology
Centre
J. Dean
Naval Research Laboratory
The OLSRv2 Design Team
MANET Working Group
April 10, 2006
Neighborhood Discovery for OLSRv2
draft-clausen-manet-olsrv2nd-00rc2
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Clausen, et al. Expires October 12, 2006 [Page 1]
Internet-Draft OLSRv2-ND April 2006
Abstract
This document describes the neighborhood discovery protocol for the
Optimized Link State Routing Protocol version 2. The protocol
provides each node with local topology up to two hops distance,
describing a node's 1-hop neighbors and symmetric 2-hop neighbors.
This is achieved through periodic message exchange. The neighborhood
discovery protocol may be used by other MANET protocols which need
neighborhood information.
The protocol imposes minimum requirements to the network by not
requiring sequenced or reliable transmission of control traffic.
Clausen, et al. Expires October 12, 2006 [Page 2]
Internet-Draft OLSRv2-ND April 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5
2. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
3. Neighborhood Information Base . . . . . . . . . . . . . . . . 7
3.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Symmetric Neighbor Set . . . . . . . . . . . . . . . . . . 8
3.3. Neighborhood Address Association Set . . . . . . . . . . . 9
3.4. 2-Hop Neighbor Set . . . . . . . . . . . . . . . . . . . . 9
4. OLSRv2 Control Message Structures . . . . . . . . . . . . . . 11
4.1. General Message TLVs . . . . . . . . . . . . . . . . . . . 11
4.1.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . 11
4.1.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . 12
4.2. Local Interface Blocks . . . . . . . . . . . . . . . . . . 12
4.3. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. HELLO Message: Address Blocks TLVs . . . . . . . . . . 13
5. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 14
5.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 15
6. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 16
6.1. Populating the Link Set . . . . . . . . . . . . . . . . . 16
6.2. Populating the Symmetric Neighbor Set . . . . . . . . . . 17
6.3. Populating the Neighborhood Address Association Set . . . 18
6.4. Populating the 2-Hop Neighbor Set . . . . . . . . . . . . 19
6.5. Neighborhood Changes . . . . . . . . . . . . . . . . . . . 20
7. Proposed Values for Constants . . . . . . . . . . . . . . . . 21
7.1. Message Intervals . . . . . . . . . . . . . . . . . . . . 21
7.2. Holding Times . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 22
8.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 22
8.3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 22
8.4. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Heuristics for Generating HELLO Messages . . . . . . 25
Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 28
Appendix C. Representing Time . . . . . . . . . . . . . . . . . . 30
Appendix D. Security Considerations . . . . . . . . . . . . . . . 31
Appendix E. Flow and Congestion Control . . . . . . . . . . . . . 33
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 34
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
Clausen, et al. Expires October 12, 2006 [Page 3]
Internet-Draft OLSRv2-ND April 2006
1. Introduction
The Optimized Link State Routing Protocol version 2 (OLSRv2) [3] uses
an exchange of HELLO messages in order that each node can determine
its neighborhood up to two hops distant. This document is a
specification of that discovery protocol. This discovery protocol is
used by OLSRv2 to determine a node's 1-hop neighbors for routing, and
to allow the selection of MultiPoint Relays (MPRs) for optimized
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. This protocol may
also be used by protocols other than OLSRv2 and makes no assumptions
about the underlying link layer, other than support of local
multicast. Link layer information and notifications may be used if
available and applicable to qualify the neighborhood information.
1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2].
Additionally, this document uses the following terminology:
node - A MANET router which implements the neighborhood discovery
protocol as specified in this document.
MANET interface - A network device participating in a MANET and
using this Neighborhood Discovery protocol. A node may have
several MANET interfaces, each interface assigned one or more IP
addresses.
1-hop neighbor - A node X is an 1-hop neighbor of node Y if node Y
can hear node X (i.e., a link exists from a MANET interface on
node X to an MANET interface on node Y).
2-hop neighbor - A node X is a 2-hop neighbor of node Y if node X is
a 1-hop neighbor of a 1-hop neighbor of node Y, but is not node Y
itself.
link - A link is a pair of MANET interfaces from two different
nodes, where at least one interface is able to hear (i.e. receive
traffic from) the other.
symmetric link - A link where both MANET interfaces are able to hear
(i.e. receive traffic from) the other.
Clausen, et al. Expires October 12, 2006 [Page 4]
Internet-Draft OLSRv2-ND April 2006
asymmetric link - A link which is not symmetric.
1-hop neighborhood - The 1-hop neighborhood of any node X is the set
of 1-hop neighbors of node X.
symmetric 1-hop neighborhood - A subset of the 1-hop neighborhood,
the symmetric 1-hop neighborhood of any node X is the set of nodes
which have at least one symmetric link to node X.
symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of
node X is the set of nodes, excluding node X itself, which have a
symmetric link to the symmetric 1-hop neighborhood of X. (This may
include nodes in the 1-hop neighborhood of X.)
1.2. Applicability Statement
This neighborhood discovery protocol supports nodes which have one or
more interfaces which participate in the MANET. It provides each
node with local topology information up to two hops away. This
information is made available to other protocols through a collection
of sets, describing the node's 1-hop neighborhood and symmetric 2-hop
neighborhood.
The protocol uses the message exchange format specified in [1]. This
implies that the HELLO messages specified by this neighborhood
discovery protocol may be extended by the TLV mechanisms described in
[1], e.g. to signal MPR selection as required by OLSRv2 [3]. This
also implies that neighborhood discovery protocol messages can be
transmitted in packets with messages from other protocols so long as
these protocols also use [1].
This specification assumes that all addresses have an associated
prefix length. The prefix length of an address is, in control
messages, indicated using the PREFIX_LENGTH TLV from [1]. If no
PREFIX_LENGTH TLV is present for a given address, it is assumed that
the prefix length for that address is identical 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 various sets of this specification
(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 control messages.
Clausen, et al. Expires October 12, 2006 [Page 5]
Internet-Draft OLSRv2-ND April 2006
2. Protocol Overview and Functioning
This protocol consists of a specification of local signaling, which
serves to:
o discover links to adjacent MANET nodes;
o perform bidirectionality check on the discovered links;
o advertise neighbors and hence discover symmetric 2-hop neighbors.
This signaling consists of a single type of message known as a HELLO
message. HELLO messages are transmitted periodically by each node.
This allows nodes to continuously track changes in their 1-hop and
symmetric 2-hop neighborhoods.
HELLO messages MAY, in addition to periodic transmissions, also be
generated as a response to some event (e.g. if a layer 2 notification
is available and indicates a change in the link to a neighbor).
However a node MUST respect a minimum interval, MIN_INTERVAL between
successive HELLO message transmissions.
This neighborhood discovery protocol is designed to work in a
completely distributed manner and does not depend on any central
entity. The protocol does not require reliable transmission of HELLO
messages: because each node sends HELLO messages periodically, it can
sustain a reasonable loss of some HELLO messages. Such losses can
occur frequently in radio networks due to collisions or other
transmission problems.
This protocol does not require any changes to the format of IP
packets. Thus any existing IP stack can be used as is.
Clausen, et al. Expires October 12, 2006 [Page 6]
Internet-Draft OLSRv2-ND April 2006
3. Neighborhood Information Base
The neighborhood information base stores information about the 1-hop
neighborhood and the symmetric 2-hop neighborhood of a node.
Note that it is possible for a node, X, to be present in both the
1-hop and symmetric 2-hop neighborhood of another node, Y,
concurrently. If the link between node X and node Y breaks, this
allows that node X is taken into consideration as a symmetric 2-hop
neighbor by node Y immediately, rather than by awaiting a HELLO
message exchange cycle.
3.1. Link Set
A node records a set of "Link Tuples", recording information about
its 1-hop neighborhood:
(L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time,
L_ASYM_time, L_time)
each describing a link between a MANET interface of this node and a
MANET interface of one of its 1-hop neighbors, where:
L_local_iface_addr is the address of the MANET interface of the
local node on which the 1-hop neighbor node is or was heard;
L_neighbor_iface_addr is the address of the MANET interface of the
1-hop neighbor node;
L_SYM_time is the time until which the link to the 1-hop neighbor
node is considered symmetric;
L_ASYM_time is the time until which the MANET interface of the 1-hop
neighbor is considered heard;
L_time specifies when this Link Tuple expires and MUST be removed.
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.
Clausen, et al. Expires October 12, 2006 [Page 7]
Internet-Draft OLSRv2-ND April 2006
+-------------+-------------+-----------+
| L_SYM_time | L_ASYM_time | L_STATUS |
+-------------+-------------+-----------+
| Expired | Expired | LOST |
| | | |
| Not Expired | Expired | SYMMETRIC |
| | | |
| Not Expired | Not Expired | SYMMETRIC |
| | | |
| Expired | Not Expired | HEARD |
+-------------+-------------+-----------+
Table 1
In a node, the set of Link Tuples is denoted the "Link Set".
3.2. Symmetric Neighbor Set
A node records a set of "Symmetric Neighbor Tuples", recording
information about its symmetric 1-hop neighborhood:
(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:
N_local_iface_addr is the address of the MANET interface of the
local node to which the 1-hop neighbor node has or had a symmetric
link;
N_neighbor_iface_addr is an address of the MANET interface of a
1-hop neighbor node which is or was in this node's symmetric 1-hop
neighborhood;
N_SYM_time is the time until which the 1-hop neighbor is considered
to be in this node's symmetric 1-hop neighborhood;
N_time specifies when this Symmetric Neighborhood Tuple expires and
MUST be removed.
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.
Clausen, et al. Expires October 12, 2006 [Page 8]
Internet-Draft OLSRv2-ND April 2006
+-------------+-----------+
| N_SYM_time | N_STATUS |
+-------------+-----------+
| Expired | LOST |
| | |
| Not Expired | SYMMETRIC |
+-------------+-----------+
Table 2
In a node, the set of Symmetric Neighbor Tuples is denoted the
"Symmetric Neighbor Set".
3.3. Neighborhood Address Association Set
A node records a set of "Neighborhood Address Association Tuples",
recording information about the MANET interface configuration of its
1-hop neighbors:
(NA_neighbor_iface_addr_list, NA_time)
NA_neighbor_iface_addr_list is a list of interface addresses of a
single 1-hop neighbor;
NA_time specifies when this Neighborhood Address Association Tuple
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
A node records a set of "2-Hop Neighbor Tuples", recording
information about a its 2-hop neighborhood:
(N2_local_iface_addr, N2_neighbor_iface_addr, N2_2hop_iface_addr,
N2_time)
each describing a symmetric link between an address of a MANET
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;
Clausen, et al. Expires October 12, 2006 [Page 9]
Internet-Draft OLSRv2-ND April 2006
N2_neighbor_iface_addr is the address of the MANET interface address
of a symmetric 1-hop neighbor;
N2_2hop_iface_addr is the address of a MANET interface of a 2-hop
neighbor which has a symmetric link (not necessarily using 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 and MUST be removed.
In a node, the set of 2-Hop Neighbor Tuples is denoted the "2-Hop
Neighbor Set".
Clausen, et al. Expires October 12, 2006 [Page 10]
Internet-Draft OLSRv2-ND April 2006
4. OLSRv2 Control Message Structures
The packet and message format used by this neighborhood discovery
protocol is defined in [1], which is used with the following
considerations:
o this protocol specifies one message type: HELLO message;
o HELLO messages are transmitted only one hop, i.e. MUST NOT be
forwarded;
o multi-message packets may be created using other messages as
specified by the protocol which uses this neighborhood discovery
protocol;
o packet headers may be included as specified by the protocol which
uses the neighborhood discovery protocol;
o message header options may be used as specified by the protocol
which uses this neighborhood discovery protocol;
o this protocol specifies two message TLVs and three address block
TLVs; other TLVs MAY be included as specified by the protocol
which uses this neighborhood discovery protocol.
The remainder of this section defines, within the framework of [1],
TLVs specific to this neighborhood discovery protocol.
4.1. General Message TLVs
This section specifies two message TLVs, VALIDITY_TIME and
INTERVAL_TIME.
4.1.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.
Clausen, et al. Expires October 12, 2006 [Page 11]
Internet-Draft OLSRv2-ND April 2006
VALIDITY_TIME Message TLV Specification Overview
+----------------+------+-------------------+----------------------+
| 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 as
specified in Appendix C.
4.1.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.
The INTERVAL_TIME message TLV specification is given in Table 4.
INTERVAL_TIME Message TLV Specification Overview
+----------------+------+-------------------+----------------------+
| Name | Type | Length | Value |
+----------------+------+-------------------+----------------------+
| INTERVAL_TIME | TBD | 8 bits | <time> |
+----------------+------+-------------------+----------------------+
Table 4
where <time> is the maximum time until the next transmission of a
HELLO message by the originator node on the same interface,
represented as specified in Appendix C.
4.2. Local Interface Blocks
The first address block, plus following TLV block, in a HELLO message
is known as the Local Interface Block. The Local Interface Block is
not distinguished in any way other than by being the first address
block in the message.
The first address of the Local Interface Block MUST contain the
address of the interface over which the HELLO message is transmitted.
If that interface has an associated prefix different from the length
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".
Clausen, et al. Expires October 12, 2006 [Page 12]
Internet-Draft OLSRv2-ND April 2006
The Local Interface Block MUST contain all of the addresses of all of
the MANET interfaces of the originating node, using the standard
<address-block> syntax from [1]. Those addresses, if any, which
correspond to MANET interfaces other than that on which the HELLO
message is transmitted MUST have a corresponding OTHER_IF TLV as
specified in Section 4.3.1.
Note that a Local Interface Block MAY include more than one address
for each MANET interface, and hence a HELLO message MAY contain more
than one address without an OTHER_IF TLV.
4.3. HELLO Messages
A HELLO message MUST contain:
o a message TLV VALIDITY_TIME as specified in Section 4.1.1;
o a Local Interface Block.
A HELLO message MAY contain:
o a message TLV INTERVAL_TIME as specified in Section 4.1.2;
o one or more address blocks with associated address block TLVs as
specified in Section 4.3.1; these address blocks contain 1-hop
neighbors' MANET interface addresses.
4.3.1. HELLO Message: Address Blocks TLVs
HELLO Message Address Block TLV Specification Overview
+----------------+------+-------------------+-----------------------+
| Name | Type | Length | Value |
+----------------+------+-------------------+-----------------------+
| OTHER_IF | TBD | 0 bits | Not Applicable |
| | | | |
| LINK_STATUS | TBD | 8 bits | One of LOST, |
| | | | SYMMETRIC or HEARD. |
| | | | |
| OTHER_NEIGHB | TBD | 8 bits | One of LOST or |
| | | | SYMMETRIC |
+----------------+------+-------------------+-----------------------+
Table 5
Clausen, et al. Expires October 12, 2006 [Page 13]
Internet-Draft OLSRv2-ND April 2006
5. HELLO Message Generation
HELLO messages MUST be generated and transmitted independently on
each MANET interface. The maximum interval between HELLO
transmissions on the same MANET interface MUST NOT exceed
HELLO_INTERVAL. Two successive HELLO message transmissions on the
same MANET interface MUST be separated by at least MIN_INTERVAL.
Each HELLO message MUST include a Local Interface Block as specified
in Section 4.2 as its first address block.
On its MANET interface with address Sending Address, a node MUST
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.
The addresses, with their associated TLVs, which MUST be included in
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,
include:
* L_neighbor_iface_addr with an associated TLV with:
+ Type = LINK_STATUS; AND
+ Value = L_STATUS.
2. For each address which appears as an N_neighbor_iface_addr in one
or more Symmetric Neighbor Tuples:
1. If this address has already been included with an associated
TLV with Type == LINK_STATUS and Value == SYMMETRIC, do not
add an associated TLV with Type == OTHER_NEIGHB;
2. otherwise if, for one or more of these Symmetric Neighbor
Tuples, N_STATUS == SYMMETRIC, then include this address with
associated TLV with:
+ Type = OTHER_NEIGHB; AND
+ Value = SYMMETRIC;
Clausen, et al. Expires October 12, 2006 [Page 14]
Internet-Draft OLSRv2-ND April 2006
3. otherwise if, for all of these Symmetric Neighbor Tuples,
N_STATUS == LOST, and this address has not already been
included with an associated TLV with Type == LINK_STATUS and
Value == LOST, then include this address with associated TLV
with:
+ Type = OTHER_NEIGHB; AND
+ Value = LOST.
If an address is specified as included with more than one associated
TLV, then:
o for each HELLO message, including that address, all TLVs
associated with that address MUST be included;
o the address MUST only be included once, with the TLVs all
associated with that single address.
5.1. HELLO Message: Transmission
Messages are retransmitted in the packet/message format specified by
[1] with the ALL-MANET-NEIGHBORS multicast address as destination IP
address and with the HELLO message Hop Limit = 1.
Clausen, et al. Expires October 12, 2006 [Page 15]
Internet-Draft OLSRv2-ND April 2006
6. HELLO Message Processing
On receiving a HELLO message, a node will update its neighborhood
information base according to the specification given in this
section.
For the purpose of this section, note the following definitions:
o the "validity time" of a message is calculated from the VALIDITY-
TIME TLV of the message as specified in Section 4.1.1;
o the "Source Address" is the first address and associated prefix
length of the Local Interface Block of the HELLO message;
o the "Receiving Address" is the address, including prefix length,
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
preceding the current time (e.g. current time - 1).
6.1. Populating the Link Set
On receiving a HELLO message, a node SHOULD update its Link Set:
1. If there is no Link Tuple with:
* L_local_iface_addr == Receiving Address; AND
* L_neighbor_iface_addr == Source Address,
then create a new Link Tuple with
* L_local_iface_addr = Receiving Address;
* L_neighbor_iface_addr = Source Address;
* L_SYM_time = EXPIRED;
* L_time = current time + validity time.
2. This Link Tuple (existing or new) is then modified as follows:
1. If the node finds the Receiving Address in one of the address
blocks included in the HELLO message, other than the Local
Interface Block, then the Link Tuple is modified as follows:
1. If the Receiving Address in that address block is
associated with a TLV with Type == LINK_STATUS and Value
Clausen, et al. Expires October 12, 2006 [Page 16]
Internet-Draft OLSRv2-ND April 2006
== LOST then:
1. if L_STATUS == SYMMETRIC:
o L_time = current time + max(validity time,
L_HOLD_TIME),
o L_SYM_time = EXPIRED.
2. Otherwise if the Receiving Address in that address block
is associated with a TLV with Type == LINK_STATUS and
(Value == HEARD or Value == SYMMETRIC) then:
- L_SYM_time = current time + validity time;
- L_time = L_SYM_time + L_HOLD_TIME.
2. L_ASYM_time = current time + validity time;
3. L_time = max(L_time, L_ASYM_time).
6.2. Populating the Symmetric Neighbor Set
On receiving a HELLO message, a node SHOULD update its Symmetric
Neighbor Set:
1. If the Receiving Address is in an address block of the HELLO
message, other than the Local Interface Block, with an associated
TLV with Type == LINK_STATUS and (Value == HEARD or Value ==
SYMMETRIC) then:
1. For each address (henceforth neighbor address) in the HELLO
message Local Interface Block:
1. If there is a Symmetric Neighbor Tuple with:
- N_local_iface_addr == Receiving Address; AND
- N_neighbor_iface_addr == neighbor address,
then update this Symmetric Neighbor Tuple to have:
- N_SYM_time = current time + validity time;
- N_time = N_SYM_time + N_HOLD_TIME.
Clausen, et al. Expires October 12, 2006 [Page 17]
Internet-Draft OLSRv2-ND April 2006
2. Otherwise create a new Symmetric Neighbor Tuple with:
- N_local_iface_addr = Receiving Address;
- N_neighbor_iface_addr = neighbor address;
- N_SYM_time = current time + validity time;
- N_time = N_SYM_time + N_HOLD_TIME.
2. Otherwise if the Receiving Address is in an address block of the
HELLO message, other than the Local Interface Block, with an
associated TLV with Type == LINK_STATUS and Value == LOST, then:
1. For each address (henceforth neighbor address) in the HELLO
message Local Interface Block, if there exists a Symmetric
Neighbor Tuple with:
+ N_local_iface_addr == Receiving Address; AND
+ N_neighbor_iface_addr == neighbor address,
update this Symmetric Neighbor Tuple to have:
+ N_SYM_time = EXPIRED;
+ N_time = min(N_time, current time + N_HOLD_TIME).
6.3. Populating the Neighborhood Address Association Set
On receiving a HELLO message, the node SHOULD update its Neighborhood
Address Association Set:
1. Remove all Neighborhood Address Association Tuples where:
* NA_neighbor_iface_addr_list contains at least one address
which is contained in the Local Interface Block of the
received HELLO message,
and create a new Neighborhood Address Association Tuple with:
* NA_neighbor_iface_addr_list = list of all addresses contained
in the Local Interface Block of the received HELLO message;
* NA_time = current time + validity time.
Clausen, et al. Expires October 12, 2006 [Page 18]
Internet-Draft OLSRv2-ND April 2006
6.4. Populating the 2-Hop Neighbor Set
On receiving a HELLO message the node SHOULD update its 2-Hop
Neighbor Set:
1. If there exists a Link Tuple with L_local_iface_addr == Source
Address and L_STATUS == SYMMETRIC then:
1. For each address (henceforth 2-hop neighbor address) in an
address block of the HELLO message, other than the Local
Interface Block, which is not an interface address of the
receiving node (i.e. a node is not its own 2-hop neighbor):
1. If the 2-hop neighbor address has an associated TLV with:
- Type == LINK_STATUS and Value == SYMMETRIC; OR
- Type == OTHER_NEIGHB and Value == SYMMETRIC,
then, if there is no 2-Hop Neighbor Tuple with:
- N2_local_iface_addr == Receiving Address;
- N2_neighbor_iface_addr == Source Address;
- N2_2hop_iface_addr == 2-hop neighbor address;
create a 2-Hop Neighbor Tuple with:
- N2_local_iface_addr = Receiving Address; AND
- N2_neighbor_iface_addr = Source Address; AND
- N2_2hop_iface_addr = 2-hop neighbor address.
This 2-Hop Neighbor Tuple (existing or new) is then
modified as follows:
- N2_time = current time + validity time.
2. Otherwise if the 2-hop neighbor address has a TLV with:
- Type == LINK_STATUS and (Value == LOST or Value ==
HEARD); OR
- Type == OTHER_NEIGHB and Value == LOST;
then remove all 2-Hop Neighbor Tuples with:
Clausen, et al. Expires October 12, 2006 [Page 19]
Internet-Draft OLSRv2-ND April 2006
- N2_local_iface_addr == Receiving Address; AND
- N2_neighbor_iface_addr == Source Address; AND
- N2_2hop_iface_addr == 2-hop neighbor address.
6.5. Neighborhood Changes
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
Value == LOST) then all 2-Hop Neighbor Tuples with:
o N2_local_iface_addr == L_local_iface_addr from the Link Tuple,
AND;
o N2_neighbor_iface_addr == L_neighbor_iface_addr from the Link
Tuple,
MUST be deleted.
In this, or any other case of neighborhood change, a node MAY send a
HELLO message reporting updated information. If a node does send
such a HELLO message the node MUST ensure that any two successive
HELLO messages are separated by at least MIN_INTERVAL.
Clausen, et al. Expires October 12, 2006 [Page 20]
Internet-Draft OLSRv2-ND April 2006
7. Proposed Values for Constants
This section list the values for the constants used in the
description of the protocol.
7.1. Message Intervals
o HELLO_INTERVAL = 2 seconds
o REFRESH_INTERVAL = 2 seconds
o MIN_INTERVAL = 0.5 seconds
7.2. Holding Times
o L_HOLD_TIME = 3 x REFRESH_INTERVAL
o N_HOLD_TIME = 3 x REFRESH_INTERVAL
7.3. Time
o C = 0.0625 seconds (1/16 second)
In order to achieve interoperability, C MUST be the same on all
nodes.
Clausen, et al. Expires October 12, 2006 [Page 21]
Internet-Draft OLSRv2-ND April 2006
8. IANA Considerations
8.1. Multicast Addresses
A well-known multicast address, ALL-MANET-NEIGHBORS, must be
registered and defined for both IPv6 and IPv4. The addressing scope
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
This specification defines one message type, which must be allocated
from the "Assigned Message Types" repository of [1]
+--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+
| HELLO | TBD | Local Signaling |
+--------------------+-------+--------------------------------------+
Table 6
8.3. TLV Types
This specification defines two Message TLV types, which must be
allocated from the "Assigned message TLV Types" repository of [1]
+--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+
| VALIDITY_TIME | TBD | The time (in seconds) from receipt |
| | | of the message during which the |
| | | information contained in the message |
| | | is to be considered valid |
| | | |
| INTERVAL_TIME | TBD | The maximum time (in seconds) |
| | | between two successive transmissions |
| | | of messages of the appropriate type |
+--------------------+-------+--------------------------------------+
Table 7
This specification defines two Address Block TLV types, which must be
allocated from the "Assigned address block TLV Types" repository of
[1]
Clausen, et al. Expires October 12, 2006 [Page 22]
Internet-Draft OLSRv2-ND April 2006
+--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+
| OTHER_IF | TBD | Specifies that the address, in the |
| | | Local Interface Block of the |
| | | message, is an address associated |
| | | with a MANET interface other than |
| | | the one on which the message is |
| | | transmitted |
| | | |
| LINK_STATUS | TBD | Specifies a given link's status |
| | | (LOST, SYMMETRIC or HEARD) |
| | | |
| OTHER_NEIGHB | TBD | Specifies that the address is, or |
| | | was, of a MANET interface of a |
| | | symmetric 1-hop neighbor of the node |
| | | transmitting the HELLO message, but |
| | | does not have a matching or better |
| | | LINK_STATUS TLV |
+--------------------+-------+--------------------------------------+
Table 8
8.4. LINK_STATUS and OTHER_NEIGHB Values
The values which the LINK_STATUS TLV can use are the following:
o LOST = 0
o SYMMETRIC = 1
o HEARD = 2
The values which the OTHER_NEIGHB TLV can use are the following:
o LOST = 0
o SYMMETRIC = 1
Clausen, et al. Expires October 12, 2006 [Page 23]
Internet-Draft OLSRv2-ND April 2006
9. References
9.1. Normative References
[1] Clausen, T., Dean, J., and C. Dearlove, "Generalized MANET
Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-00.txt, February 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
9.2. Informative References
[3] Clausen, T. and C. Dearlove, "The Optimized Link State Routing
Protocol", Work In Progress draft-ietf-manet-olsrv2-01.txt,
March 2006.
[4] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996.
Clausen, et al. Expires October 12, 2006 [Page 24]
Internet-Draft OLSRv2-ND April 2006
Appendix A. Heuristics for Generating HELLO Messages
The algorithm for generating HELLO messages in Section 5 specifies
which addresses MUST be included in the address blocks after the
Local Interface Block, and with which associated TLVs. These
addresses may have Type == LINK_STATUS or Type == OTHER_NEIGHB, or
both. TLVs of Type == LINK_STATUS may have three possible values
(Value == HEARD, Value == SYMMETRIC or Value == LOST), and TLVs of
TYPE == OTHER_NEIGHB may have two possible values (Value == SYMMETRIC
or Value == LOST). When both TLVs are associated with the same
address only certain combinations of these TLV values are necessary,
and are the only combinations generated by the algorithm in
Section 5. These combinations are indicated in Table 9.
Cells labeled with "Yes" indicate the possible combinations which are
generated by the algorithm in Section 5. Cells labeled with "No"
indicate combinations not generated by the algorithm in Section 5,
but which are correctly parsed and interpreted by the algorithm in
Section 6.
+----------------+----------------+----------------+----------------+
| | Type == | Type == | Type == |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value == | Value == LOST |
| | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+
| Type == | No | Yes | Yes |
| LINK_STATUS | | | |
| (absent) | | | |
| | | | |
| Type == | Yes | Yes | Yes |
| LINK_STATUS, | | | |
| Value == HEARD | | | |
| | | | |
| Type == | Yes | No | No |
| LINK_STATUS, | | | |
| Value == | | | |
| SYMMETRIC | | | |
| | | | |
| Type == | Yes | Yes | No |
| LINK_STATUS, | | | |
| Value == LOST | | | |
+----------------+----------------+----------------+----------------+
Table 9
In creating the HELLO message there are three stages:
Clausen, et al. Expires October 12, 2006 [Page 25]
Internet-Draft OLSRv2-ND April 2006
1. collect the addresses into groups, each of which will form an
address block;
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.
Clausen, et al. Expires October 12, 2006 [Page 26]
Internet-Draft OLSRv2-ND April 2006
* 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 lower cost approach.
Alternatively a single decision based on the expected number of
1-hop neighbor addresses may be made.
Clausen, et al. Expires October 12, 2006 [Page 27]
Internet-Draft OLSRv2-ND April 2006
Appendix B. HELLO Message Example
A simple example HELLO message, sent by an originator node with a
single MANET interface, is as follows. The message uses IPv4 (four
octet) addresses without prefix TLVs, i.e. with all addresses having
maximum length prefixes. The message is sent with a full message
header (message semantics octet is 0) with a hop limit of 1 and a hop
count of 0. The overall message length is 48 octets (it does not
need padding).
The message has a message TLV block with content length 8 octets
containing two message TLVs, of types VALIDITY_TIME and
INTERVAL_TIME. Each uses a TLV with semantics value 4, indicating no
start and stop indexes are included, and each has a value length of 1
octet. The values included (0x68 and 0x50) represent the default
values of 6 seconds and 2 seconds, respectively.
The first address block contains 1 local interface address, with head
length 4, and no tail octets. This address block has no TLVs (TLV
block content length 0 octets).
The second, and last, address block contains 4 neighbor interface
addresses, with head length 3 octets, each tail being a single octet.
The following TLV block (content length 7 octets) includes one TLV
which reports the link status of all neighbors in a single multivalue
TLV: the first two addresses are HEARD, the third address is
SYMMETRIC and the fourth address is LOST. The TLV semantics value of
12 indicates, in addition to that this is a multivalue TLV, that no
start index and stop index are included, since values for all
addresses are included. The TLV value length of 4 octets indicates
one octet per value per address.
Clausen, et al. Expires October 12, 2006 [Page 28]
Internet-Draft OLSRv2-ND April 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 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 | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail | Tail | Tail |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HEARD | HEARD | SYMMETRIC | LOST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clausen, et al. Expires October 12, 2006 [Page 29]
Internet-Draft OLSRv2-ND April 2006
Appendix C. Representing Time
OLSRv2 specifies several TLVs, where time, in seconds, is represented
as a single octet.
The lowest four bits of the octet represent the mantissa (a) and the
four highest bits of the octet represent the exponent (b), 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.
Clausen, et al. Expires October 12, 2006 [Page 30]
Internet-Draft OLSRv2-ND April 2006
Appendix D. Security Considerations
The objective of this protocol is to allow each node in the network
to acquire information describing its 1-hop and 2-hop neighborhood.
This is acquired through periodic message exchange between
neighboring nodes, and the information is made available through a
collection of sets, describing the nodes 1-hop neighborhood and 2-hop
neighborhood.
Under normal circumstances, the information recorded in these sets is
correct -- i.e. corresponds to the actual network topology modulo any
changes which have not (yet) been tracked by the periodic message
exchanges. If some node for some reason, malice or malfunction,
inject invalid HELLO messages, incorrect information may be recorded
in the sets maintained.
A correctly formed, but still invalid, HELLO message may take any of
the following forms:
1. The Local Interface Block of the HELLO message may contain
addresses which do not correspond to addresses of MANET
interfaces of the local node which transmits the HELLO message;
2. The Local Interface Block of the HELLO message may omit
addresses of MANET interfaces of the local node which transmits
the HELLO message;
3. The Local Interface Block may contain OTHER_IF TLVs, indicating
incorrectly that an address is associated with a MANET interface
other than the one over which the HELLO message is being
transmitted;
4. The Local Interface Block may omit OTHER_IF TLVs, thereby
indicating incorrect addresses associated with the MANET
interface over which the HELLO message is being transmitted;
5. A present or absent address in an address block, other than in
the Local Interface Block, does not in and by itself cause a
problem. It is the presence, absence or incorrectness of
associated LINK_STATUS and OTHER_NEIGHB TLVs that cause
problems;
6. A present LINK_STATUS TLV may, incorrectly, identify an address
as being of a node which is or was in the sending nodes 1-hop
neighborhood;
7. A consistently absent LINK_STATUS TLV may, incorrectly, fail to
identify an address as being of a node which is or was in the
Clausen, et al. Expires October 12, 2006 [Page 31]
Internet-Draft OLSRv2-ND April 2006
sending nodes 1-hop neighborhood;
8. A present OTHER_NEIGHB TLV may, incorrectly, identify an address
as being of a node which is or was in the sending node's
symmetric 1-hop neighborhood;
9. A consistently absent OTHER_NEIGHB TLV may, incorrectly, fail to
identify an address as being of a node which is or was in the
sending node's symmetric 1-hop neighborhood;
10. The value of a LINK_STATUS or OTHER_NEIGHB TLV may incorrectly
indicate the status (LOST, SYMMETRIC, HEARD) of an 1-hop
neighbor.
Clausen, et al. Expires October 12, 2006 [Page 32]
Internet-Draft OLSRv2-ND April 2006
Appendix E. Flow and Congestion Control
This document specifies one message type, HELLO messages. The size
of each complete HELLO message is proportional to the size of the
transmitting node's 1-hop neighborhood (this information may be sent
distributed across multiple interfaces). HELLO messages MUST NOT be
forwarded.
A node MUST report its 1-hop neighborhood in HELLO messages on each
of its MANET interfaces at least each REFRESH_INTERVAL. Thus, this
puts a lower bound on the control traffic, which each node employing
this neighborhood discovery protocol in the network generates.
A node MUST ensure that two successive HELLO messages sent on the
same MANET interface are separated by at least MIN_INTERVAL. Thus,
this puts an upper bound on the control traffic, which each node
employing this neighborhood discovery protocol in the network
generates.
In order for the protocol to function, each node in the network MUST
employ the HELLO signaling as described in this specification.
Clausen, et al. Expires October 12, 2006 [Page 33]
Internet-Draft OLSRv2-ND April 2006
Appendix F. Contributors
This specification is the result of the joint efforts of the
following contributors -- listed alphabetically.
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, Hitachi Labs Europe, France,
<Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, PCRI, France, <T.Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK,
<Chris.Dearlove@baesystems.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
Clausen, et al. Expires October 12, 2006 [Page 34]
Internet-Draft OLSRv2-ND April 2006
Appendix G. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1,
specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent
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
for intense technical discussions, early reviews and comments on the
specification and its components: Joe Macker (NRL), Alan Cullen (BAE
Systems), Richard Ogier (SRI), Song-Yean Cho (Samsung Software
Center) and the entire IETF MANET working group.
Clausen, et al. Expires October 12, 2006 [Page 35]
Internet-Draft OLSRv2-ND April 2006
Authors' Addresses
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
Christopher M. Dearlove
BAE Systems Advanced Technology Centre
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ocs/sharedservices/atc/
Justin W. Dean
Naval Research Laboratory
Phone: +1 202 767 3397
Email: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/
The OLSRv2 Design Team
MANET Working Group
Clausen, et al. Expires October 12, 2006 [Page 36]
Internet-Draft OLSRv2-ND April 2006
Full 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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Clausen, et al. Expires October 12, 2006 [Page 37]
