draft-ietf-manet-nhdp-06.txt   draft-ietf-manet-nhdp-07.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: September 11, 2008 BAE Systems Advanced Technology Expires: January 11, 2009 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
March 10, 2008 July 10, 2008
MANET Neighborhood Discovery Protocol (NHDP) MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-06 draft-ietf-manet-nhdp-07
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 September 11, 2008. This Internet-Draft will expire on January 11, 2009.
Abstract Abstract
This document describes a 1-hop and symmetric 2-hop neighborhood This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs). discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 9 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 9
4.2. Information Base Overview . . . . . . . . . . . . . . . . 9 4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 10
4.2.1. Local Information Base . . . . . . . . . . . . . . . . 9 4.2. Information Base Overview . . . . . . . . . . . . . . . . 10
4.2.2. Interface Information Bases . . . . . . . . . . . . . 10 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 10
4.2.3. Node Information Base . . . . . . . . . . . . . . . . 10 4.2.2. Interface Information Bases . . . . . . . . . . . . . 11
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 11 4.2.3. Node Information Base . . . . . . . . . . . . . . . . 11
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 11 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 12
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 11 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 12
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 12 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 12
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 13
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 14 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 14 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 15
5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 14 5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 15
5.1.2. Information Validity Times . . . . . . . . . . . . . . 15 5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 15
5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Information Validity Times . . . . . . . . . . . . . . 16
5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 17
5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Information Validity Time . . . . . . . . . . . . . . 17 5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 18
5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 17 5.2.1. Information Validity Time . . . . . . . . . . . . . . 18
5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 18
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 20 5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 20 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 21
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 20 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 21
7. Interface Information Base . . . . . . . . . . . . . . . . . . 21 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 21
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Interface Information Base . . . . . . . . . . . . . . . . . . 22
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Node Information Base . . . . . . . . . . . . . . . . . . . . 23 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 23 8. Node Information Base . . . . . . . . . . . . . . . . . . . . 24
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 23 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 24
9. Local Information Base Changes . . . . . . . . . . . . . . . . 24 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 24
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 24 9. Local Information Base Changes . . . . . . . . . . . . . . . . 25
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 24 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 25
9.3. Adding an Address to an Interface . . . . . . . . . . . . 25 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 25
9.4. Removing an Address from an Interface . . . . . . . . . . 26 9.3. Adding an Address to an Interface . . . . . . . . . . . . 26
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 27 9.4. Removing an Address from an Interface . . . . . . . . . . 27
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 27 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 28
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 28 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 28
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 30 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 29
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 30 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 31
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 32 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 31
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 32 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 33
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 33 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 33
12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 34 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 34
12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 35 12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 35
12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 35 12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 36
12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 37 12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 36
13. Other Information Base Changes . . . . . . . . . . . . . . . . 39 12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 38
13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 39 13. Other Information Base Changes . . . . . . . . . . . . . . . . 40
13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 40 13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 40
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 41 13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 41
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 42 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 42
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 42 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 42 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 43
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 43 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 43
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 44 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 44
15. Proposed Values for Parameters and Constants . . . . . . . . . 45 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 45
15.1. Message Interval Interface Parameters . . . . . . . . . . 45 15. Proposed Values for Parameters and Constants . . . . . . . . . 46
15.2. Information Validity Time Interface Parameters . . . . . . 45 15.1. Message Interval Interface Parameters . . . . . . . . . . 46
15.3. Information Validity Time Node Parameters . . . . . . . . 45 15.2. Information Validity Time Interface Parameters . . . . . . 46
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 45 15.3. Information Validity Time Node Parameters . . . . . . . . 46
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 45 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 46
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 46 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 46
16. Security Considerations . . . . . . . . . . . . . . . . . . . 47 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 47
16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 47 16. Security Considerations . . . . . . . . . . . . . . . . . . . 48
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48
17.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 49 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
17.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 49 17.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 50
17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 50 17.2. Address Block TLV Types . . . . . . . . . . . . . . . . . 50
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 51
18.1. Normative References . . . . . . . . . . . . . . . . . . . 51 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
18.2. Informative References . . . . . . . . . . . . . . . . . . 51 18.1. Normative References . . . . . . . . . . . . . . . . . . . 53
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 52 18.2. Informative References . . . . . . . . . . . . . . . . . . 53
Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 53 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 54
Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 56 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 55
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 59 Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 58
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 60 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 61
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 61 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 62
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
This document describes a neighborhood discovery protocol (NHDP) for This document describes a neighborhood discovery protocol (NHDP) for
a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an
exchange of HELLO messages in order that each node can determine the exchange of HELLO messages in order that each node can determine the
presence and status of its 1-hop and symmetric 2-hop neighbors. presence and status of its 1-hop and symmetric 2-hop neighbors.
Messages are defined as instances of the specification [packetbb]. Messages are defined as instances of the specification [packetbb].
This neighborhood information is recorded in the form of Information This neighborhood information is recorded in the form of Information
skipping to change at page 5, line 5 skipping to change at page 4, line 27
presence of a dynamic network topology. presence of a dynamic network topology.
This protocol makes no assumptions about the underlying link layer, This protocol makes no assumptions about the underlying link layer,
other than support of link local broadcast or multicast. Link layer other than support of link local broadcast or multicast. Link layer
information may be used if available and applicable. information may be used if available and applicable.
This protocol is based on the neighborhood discovery process This protocol is based on the neighborhood discovery process
contained in the Optimized Link State Routing Protocol (OLSR) contained in the Optimized Link State Routing Protocol (OLSR)
[RFC3626]. [RFC3626].
1.1. Motivation
MANETs differ from more traditional wired and infrastructure based
wireless networks, due to their envisioned applicability also over
more challenging network interfaces (e.g. wireless, lossy, broadcast
interfaces with moderate and shared bandwidth, hidden and exposed
terminals and interference from other network interfaces and the
environment) and in more challenging topological conditions (e.g.
rapid and unpredictable mobility, dynamic and non-predetermined
network membership). An approach, often taken by MANET routing
protocols, is to collect local topological information up to 2 hops,
in order to, for example, optimize their flooding performance within
the MANET.
Due to the properties of wireless transmissions, communication
between two network interfaces on neighboring nodes may not be bi-
directional; even if node A is able to receive a packets from node B,
the converse is not guaranteed to be true. Furthermore, because of
the localized nature of wireless broadcasts communication, differing
neighbor sets often exist for differing neighboring nodes within the
same communications channel. If node A is able to exchange packets
with node B and node B is able to exchange packets with node C on the
same interface, this does not guarantee that node A and node C can
exchange packets directly.
Nodes in a MANET may have multiple heterogeneous interfaces
participating in the same MANET routing protocol, each of which with
the characteristics as described above. Between the same pair of
nodes more than one distinct communications channel (links) may
therefore exist, with different properties.
For MANET routing protocols to correctly identify candidate links for
inclusion in a routing path, the existence and bi-directionality of
such distinct links between a node and its neighbors must be
established and monitored.
The set of neighbor nodes of a given MANET node may be continuously
changing, often due to node mobility or due to a changing physical
environment in which the MANET is located. There are typically no
signals from lower layers which would enable an IP routing protocol
to detect and, as appropriate, react to such changes. Yet as such
changes are can often take place on the order of seconds, requiring
MANET IP routing protocols to also act rapidly to ensure sufficient
convergence properties.
MANET routing protocols often employ relay set reductions in order to
conserve network capacity when maintaining network-wide topological
information, with calculation of these reduced relay sets employing
up to 2-hop information. Such is the case e.g. for [RFC3626].
The neighborhood discovery protocol specified in this document
provides continued tracking of neighborhood changes, continued bi-
directionality tracking of links between neighbors and local
topological information up to two hops. Combined, this allows a
MANET routing protocol access to information describing link
establishment/disappearance, and provides the necessary topological
information for reduced relay set selection and other purposes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
The terms "packet", "message", "address", "address block", "TLV", and The terms "packet", "message", "address", "address block", "TLV", and
"TLV block" in this document are to be interpreted as described in "TLV block" in this document are to be interpreted as described in
[packetbb]. [packetbb].
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.
Interface - A network device, configured and assigned one or more IP Interface - A network device, configured and assigned one or more IP
addresses. addresses.
Address - An address, as recorded in the Information Bases specified Address - An address, as recorded in the Information Bases specified
by this protocol, and included in HELLO messages generated by this by this protocol, and included in HELLO messages generated by this
protocol, may be either an address or an address prefix. These protocol, may be either an address or an address prefix. The
can be represented as a single address object in a HELLO message, exception to this is addresses described as originator addresses;
as defined by [packetbb]. An address so represented is considered these must be simple addresses without a prefix length. Non-
to have a prefix length equal to its length (in bits) when originator addresses can be represented as a single address object
considered as an address object, and a similar convention is used in a HELLO message, as defined by [packetbb]. An address so
in the Information Bases specified by this protocol. Two represented is considered to have a prefix length equal to its
addresses (address objects) are considered equal only if their length (in bits) when considered as an address object, and a
prefix lengths are also equal. similar convention is used in the Information Bases specified by
this protocol. Two addresses (address objects) are considered
equal only if their prefix lengths are also equal.
MANET interface - An interface participating in a MANET and using MANET interface - An interface participating in a MANET and using
this neighborhood discovery protocol. A node may have several this neighborhood discovery protocol. A node may have several
MANET interfaces. MANET interfaces.
Heard - A MANET interface of node X is considered heard on a MANET Heard - A MANET interface of node X is considered heard on a MANET
interface of a node Y if the latter can receive traffic from the interface of a node Y if the latter can receive traffic from the
former. former.
Link - A pair of MANET interfaces from two different nodes, where at Link - A pair of MANET interfaces from two different nodes, where at
skipping to change at page 7, line 23 skipping to change at page 8, line 23
o Is designed to work in networks with a dynamic topology, and in o Is designed to work in networks with a dynamic topology, and in
which messages may be lost, such as due to collisions in wireless which messages may be lost, such as due to collisions in wireless
networks. networks.
o Supports nodes that each have one or more participating MANET o Supports nodes that each have one or more participating MANET
interfaces. The set of a node's interfaces may change over time. interfaces. The set of a node's interfaces may change over time.
Each interface may have one or more interface addresses, and these Each interface may have one or more interface addresses, and these
may also be dynamically changing. may also be dynamically changing.
o Can use the link local multicast address and either the "manet" o Can use the link local multicast address "LL-MANET-Routers", and
UDP port or the "manet" IP protocol number specified in either the "manet" UDP port or the "manet" IP protocol number, all
[manet-iana]. as specified in [manet-iana].
o Uses the packet and message formats specified in [packetbb]. Such o Uses the packet and message formats specified in [packetbb]. Such
packets may contain messages specified by this protocol as well as packets may contain messages specified by this protocol as well as
other protocols. other protocols.
o Specifies signaling using HELLO messages. The necessary contents o Specifies signaling using HELLO messages. The necessary contents
of these messages are defined in this specification, and may be of these messages are defined in this specification, and may be
extended using the TLV mechanisms described in [packetbb]. extended using the TLV mechanisms described in [packetbb].
o Can use relevant link layer information if it is available. o Can use relevant link layer information if it is available.
skipping to change at page 28, line 20 skipping to change at page 29, line 20
All addresses in a node's Local Interface Set (i.e. in any All addresses in a node's Local Interface Set (i.e. in any
I_local_iface_addr_list) MUST be included in the address blocks in I_local_iface_addr_list) MUST be included in the address blocks in
all generated HELLO messages with the following exception. If the all generated HELLO messages with the following exception. If the
MANET interface on which the HELLO message is to be sent has a single MANET interface on which the HELLO message is to be sent has a single
interface address with maximum prefix length then that address MAY be interface address with maximum prefix length then that address MAY be
omitted. All addresses of the node's interfaces included in an omitted. All addresses of the node's interfaces included in an
address block MUST be associated with a TLV with Type == LOCAL_IF, as address block MUST be associated with a TLV with Type == LOCAL_IF, as
defined in Table 1. defined in Table 1.
+----------+--------+-----------------------------------------------+ +----------+---------+----------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+----------+--------+-----------------------------------------------+ +----------+---------+----------------------------------------------+
| LOCAL_IF | 1 | Specifies that the address is an address | | LOCAL_IF | 1 octet | Specifies that the address is an address |
| | octet | associated with the interface on which the | | | | associated with the interface on which the |
| | | message was sent (THIS_IF), another interface | | | | message was sent (THIS_IF), another |
| | | of the sending node (OTHER_IF), or an | | | | interface of the sending node (OTHER_IF), or |
| | | unspecified interface of the sending node | | | | an unspecified interface of the sending node |
| | | (UNSPEC_IF). | | | | (UNSPEC_IF). |
+----------+--------+-----------------------------------------------+ +----------+---------+----------------------------------------------+
Table 1 Table 1
Note that the value UNSPEC_IF is not used by this protocol. It is Note that the value UNSPEC_IF is not used by this protocol. It is
provided for an expected alternative use of this TLV. provided for an expected alternative use of this TLV.
Address blocks MAY contain current or recently lost 1-hop neighbors' Address blocks MAY contain current or recently lost 1-hop neighbors'
interface addresses, each of which is associated with address block interface addresses, each of which is associated with address block
TLVs as described in Table 2. TLVs as described in Table 2.
+--------------+--------+-------------------------------------------+ +--------------+---------+------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+--------------+--------+-------------------------------------------+ +--------------+---------+------------------------------------------+
| LINK_STATUS | 1 | Specifies the status of the link from the | | LINK_STATUS | 1 octet | Specifies the status of the link from |
| | octet | indicated address (LOST, SYMMETRIC or | | | | the indicated address (LOST, SYMMETRIC |
| | | HEARD). | | | | or HEARD). |
| | | | | | | |
| OTHER_NEIGHB | 1 | Specifies that the address is (SYMMETRIC) | | OTHER_NEIGHB | 1 octet | Specifies that the address is |
| | octet | or was (LOST) of an interface of a | | | | (SYMMETRIC) or was (LOST) of an |
| | | symmetric 1-hop neighbor of the node | | | | interface of a symmetric 1-hop neighbor |
| | | transmitting the HELLO message. | | | | of the node transmitting the HELLO |
+--------------+--------+-------------------------------------------+ | | | message. |
+--------------+---------+------------------------------------------+
Table 2 Table 2
A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value == A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value ==
LOST) also performs the function of a TLV with Type == OTHER_NEIGHB LOST) also performs the function of a TLV with Type == OTHER_NEIGHB
and the same value. The latter SHOULD NOT also be included. If a and the same value. The latter SHOULD NOT also be included. If a
TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with
a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter
MUST be ignored, and SHOULD NOT be included. See Appendix A. MUST be ignored, and SHOULD NOT be included. See Appendix A.
skipping to change at page 49, line 9 skipping to change at page 50, line 9
status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop
neighbor. neighbor.
* The value of an OTHER_NEIGHB TLV may incorrectly indicate the * The value of an OTHER_NEIGHB TLV may incorrectly indicate the
status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor. status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.
17. IANA Considerations 17. IANA Considerations
17.1. Message Types 17.1. Message Types
This specification defines one message type, which must be allocated This specification defines one message type, to be allocated from the
from the "Assigned Message Types" repository of [packetbb] with 0-223 range of the "Message Types" namespace defined in [packetbb],
assignment as specified in Table 3. as specified in Table 3.
+-------+------+------------------+ +-------+------+------------------+
| Name | Type | Description | | Name | Type | Description |
+-------+------+------------------+ +-------+------+------------------+
| HELLO | TBD1 | Local signaling. | | HELLO | TBD1 | Local signaling. |
+-------+------+------------------+ +-------+------+------------------+
Table 3 Table 3
17.2. TLV Types 17.2. Address Block TLV Types
This specification defines three address block TLV types, which must This specification defines three address block TLV types, which must
be allocated from the "Assigned Address Block TLV Types" repository be allocated from the "Address Block TLV Types" namespace defined in
of [packetbb] with assignments as specified in Table 4. [packetbb]. IANA are requested to make allocations in the 8-127
range for these types. This will create three new type extension
registries with assignments as specified in Table 4, Table 5 and
Table 6. Specifications of these TLVs are in Section 10.1.1, with
value constants defined in Section 17.3.
+--------------+------+-----------+---------------------------------+ +----------+------+-----------+-------------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+--------------+------+-----------+---------------------------------+ +----------+------+-----------+-------------------------------------+
| LOCAL_IF | TBD2 | 0 | Specifies that the address is | | LOCAL_IF | TBD2 | 0 | Specifies that the address is |
| | | | associated with a local | | | | | associated with a local interface |
| | | | interface of the sending node. | | | | | of the sending node. |
| | | | |
| | | 1-255 | RESERVED |
| | | | | | | | | |
| LINK_STATUS | TBD3 | 0 | Specifies the status of the | | | | 1-255 | Expert Review |
| | | | link from the indicated address | +----------+------+-----------+-------------------------------------+
Table 4
+-------------+------+-----------+----------------------------------+
| Name | Type | Type | Description |
| | | extension | |
+-------------+------+-----------+----------------------------------+
| LINK_STATUS | TBD3 | 0 | Specifies the status of the link |
| | | | from the indicated address |
| | | | (LOST, SYMMETRIC or HEARD). | | | | | (LOST, SYMMETRIC or HEARD). |
| | | | | | | | | |
| | | 1-255 | RESERVED | | | | 1-255 | Expert Review |
| | | | | +-------------+------+-----------+----------------------------------+
Table 5
+--------------+------+-----------+---------------------------------+
| Name | Type | Type | Description |
| | | extension | |
+--------------+------+-----------+---------------------------------+
| OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is | | OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is |
| | | | (SYMMETRIC) or recently was | | | | | (SYMMETRIC) or recently was |
| | | | (LOST) of an interface of a | | | | | (LOST) of an interface of a |
| | | | symmetric 1-hop neighbor of the | | | | | symmetric 1-hop neighbor of the |
| | | | node transmitting the message. | | | | | node transmitting the message. |
| | | | | | | | | |
| | | 1-255 | RESERVED | | | | 1-255 | Expert Review |
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
Table 4 Table 6
Type extensions indicated as RESERVED may be allocated by standards
action, as specified in [RFC2434]. Type extensions indicated as Expert Review SHOULD be allocated as
described in [packetbb], based on Expert Review as defined in
[RFC5226].
17.3. LINK_STATUS and OTHER_NEIGHB Values 17.3. LINK_STATUS and OTHER_NEIGHB Values
The values which the LOCAL_IF TLV can use are the following: The values which the LOCAL_IF TLV can use are the following:
o UNSPEC_IF = 0 o UNSPEC_IF = 0
o THIS_IF = 1 o THIS_IF = 1
o OTHER_IF = 2 o OTHER_IF = 2
skipping to change at page 51, line 9 skipping to change at page 53, line 9
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
18. References 18. References
18.1. Normative References 18.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", RFC 5148, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226,
BCP 26, May 2008.
[packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", Work In "Generalized MANET Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-12.txt, March 2008. Progress draft-ietf-manet-packetbb-13.txt, June 2008.
[manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
Work In Progress draft-ietf-manet-iana-07.txt,
November 2007.
[timetlv] Clausen, T. and C. Dearlove, "Representing multi-value [timetlv] Clausen, T. and C. Dearlove, "Representing multi-value
time in MANETs", Work In time in MANETs", Work In
Progress draft-ietf-manet-timetlv-04.txt, Progress draft-ietf-manet-timetlv-04.txt,
November 2007. November 2007.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
considerations in MANETs", RFC 5148, February 2008. Work In Progress draft-ietf-manet-iana-07.txt,
November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 2434,
BCP 26, October 1998.
18.2. Informative References 18.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003.
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003.
Appendix A. Address Block TLV Combinations Appendix A. Address Block TLV Combinations
The algorithm for generating HELLO messages in Section 11 specifies The algorithm for generating HELLO messages in Section 11 specifies
which 1-hop addresses may be included in the address blocks, and with which 1-hop addresses may be included in the address blocks, and with
which associated TLVs. These TLVs may have Type == LINK_STATUS or which associated TLVs. These TLVs may have Type == LINK_STATUS or
Type == OTHER_NEIGHB, or both. TLVs with Type == LINK_STATUS may Type == OTHER_NEIGHB, or both. TLVs with Type == LINK_STATUS may
have three possible values (Value == HEARD, Value == SYMMETRIC or have three possible values (Value == HEARD, Value == SYMMETRIC or
Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two
possible values (Value == SYMMETRIC or Value == LOST). When both possible values (Value == SYMMETRIC or Value == LOST). When both
TLVs are associated with the same address only certain combinations 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 11. These combinations are generated by the algorithm in Section 11. These combinations are
indicated in Table 5. 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 11. Cells labeled with "No" generated by the algorithm in Section 11. Cells labeled with "No"
indicate combinations not generated by the algorithm in Section 11, indicate combinations not generated by the algorithm in Section 11,
but which are correctly parsed and interpreted by the algorithm in but which are correctly parsed and interpreted by the algorithm in
Section 12. Section 12.
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | Type == | Type == | Type == | | | Type == | Type == | Type == |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
skipping to change at page 52, line 49 skipping to change at page 54, 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 5 Table 7
Appendix B. HELLO Message Example Appendix B. HELLO Message Example
An example HELLO message, transmitted by an originator node with a An example HELLO message, transmitted by an originator node with a
single MANET interface, is as follows. The message uses IPv4 (four single MANET interface, is as follows. The message uses IPv4 (four
octet) addresses without specified prefix lengths. The message is octet) addresses without specified prefix lengths. The message is
transmitted with a full message header other than version number transmitted with a full message header (flags octet value is 240)
(message semantics octet is 30) with a hop limit of 1 and a hop count with a hop limit of 1 and a hop count of 0. The overall message
of 0. The overall message length is 49 octets. length is 49 octets.
The message contains a message TLV block with content length 8 octets The message contains a message TLV block with content length 8 octets
containing two message TLVs, of types VALIDITY_TIME and containing two message TLVs, of types VALIDITY_TIME and
INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating INTERVAL_TIME. Each uses a TLV with flags octet value 16, indicating
that each has a value. Each has a value length of 1 octet; the that each has a value. Each has a value length of 1 octet; the
values included (0x64 and 0x58) are time codes representing the values included (0x64 and 0x58) are time codes representing the
default values of parameters H_HOLD_TIME and HELLO_INTERVAL, default values of parameters H_HOLD_TIME and HELLO_INTERVAL,
respectively (6 seconds and 2 seconds) assuming the default value of respectively (6 seconds and 2 seconds) assuming the default value of
constant C (1/1024 second). constant C (1/1024 second).
The message has a single address block containing 5 addresses. The The message has a single address block containing 5 addresses. The
semantics octet value 1 indicates an address head but no address flags octet value 128 indicates an address head but no address tail.
tail. The head length of 3 octets indicates address mid sections of The head length of 3 octets indicates address mid sections of one
one octet each (Mid 0 to Mid 4). octet each (Mid 0 to Mid 4).
The following TLV block (content length 14 octets) includes two TLVs. The following TLV block (content length 14 octets) includes two TLVs.
The first is a LOCAL_IF TLV which (with semantics value 10) indicates The first is a LOCAL_IF TLV which (with flags octet value 80)
that a single address, with index 0 (i.e. Head:Mid 0) is the single indicates that a single address, with index 0 (i.e. Head:Mid 0) is
local interface address of this node (the 1 octet value LOCAL_IF the single local interface address of this node (the 1 octet value
indicates that this address is of this interface). The second is a THIS_IF indicates that this address is of this interface). The
LINK_STATUS TLV which (with semantics octet 44) specifies the link second is a LINK_STATUS TLV which (with flags octet value 48)
status values of all reported neighbors in a single multivalue TLV specifies the link status values of all reported neighbors in a
which covers the addresses with indexes 1 to 4. The TLV value length single multivalue TLV which covers the addresses with indexes 1 to 4.
of 4 octets indicates one octet per value per address. The last four The TLV value length of 4 octets indicates one octet per value per
addresses are first and second HEARD, third SYMMETRIC, and fourth address. The last four addresses are first and second HEARD, third
LOST. SYMMETRIC, and fourth LOST.
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 1 1 1 1 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1| | HELLO |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 1| |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head | |0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 0 | Mid 1 | Mid 2 | Mid 3 | | Mid 0 | Mid 1 | Mid 2 | Mid 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF | | Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF | |0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS |0 0 1 0 1 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| | LINK_STATUS |0 0 1 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST | | LOST |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Note that this example is for illustrative purposes. The essential Note that this example is for illustrative purposes. The essential
information can be conveyed, more efficiently (assuming that the information can be conveyed, more efficiently (assuming that the
local interface address will be supplied by IP, and that the local interface address will be supplied by IP, and that the
INTERVAL_TIME is not needed) by the 29 octets: INTERVAL_TIME is not needed) by the 29 octets:
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 0 1 1 1 0 1| | HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0| |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head | |0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 1 | Mid 2 | Mid 3 | Mid 4 | | Mid 1 | Mid 2 | Mid 3 | Mid 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 1 0 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST | | LOST |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Appendix C. Constraints Appendix C. Constraints
Any process which updates the Local Information Base or the Node Any process which updates the Local Information Base or the Node
Information Base MUST ensure that all constraints specified in this Information Base MUST ensure that all constraints specified in this
skipping to change at page 61, line 12 skipping to change at page 63, line 12
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
Appendix F. Acknowledgements Appendix F. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, The authors would like to acknowledge the team behind OLSRv1,
specified in RFC3626 for their contributions. specified in RFC3626 for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components: Joe Macker (NRL), Alan Cullen (BAE specification and its components (listed alphabetically): Alan Cullen
Systems), and the entire IETF MANET working group. (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe
Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA),
and the entire IETF MANET working group.
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.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
 End of changes. 46 change blocks. 
182 lines changed or deleted 266 lines changed or added

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