draft-ietf-manet-nhdp-05.txt   draft-ietf-manet-nhdp-06.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: June 8, 2008 BAE Systems Advanced Technology Expires: September 11, 2008 BAE Systems Advanced Technology
Centre Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
December 6, 2007 March 10, 2008
MANET Neighborhood Discovery Protocol (NHDP) MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-05 draft-ietf-manet-nhdp-06
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 June 8, 2008. This Internet-Draft will expire on September 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a 1-hop and symmetric 2-hop neighborhood This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs). discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 11 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 11
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 11 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 11
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 11 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 11
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 12 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 12
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 13
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 14 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 14
5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 14 5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 14
5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 14 5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 14
5.1.2. Information Validity Times . . . . . . . . . . . . . . 15 5.1.2. Information Validity Times . . . . . . . . . . . . . . 15
5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 16 5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 16
5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 17 5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Information Validity Time . . . . . . . . . . . . . . 17 5.2.1. Information Validity Time . . . . . . . . . . . . . . 17
5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 17 5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 17
5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 19 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 20
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 19 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 20
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 19 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 20
7. Interface Information Base . . . . . . . . . . . . . . . . . . 21 7. Interface Information Base . . . . . . . . . . . . . . . . . . 21
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Node Information Base . . . . . . . . . . . . . . . . . . . . 23 8. Node Information Base . . . . . . . . . . . . . . . . . . . . 23
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 23 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 23
9. Local Information Base Changes . . . . . . . . . . . . . . . . 24 9. Local Information Base Changes . . . . . . . . . . . . . . . . 24
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 24 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 24
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 24 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 24
9.3. Adding an Address to an Interface . . . . . . . . . . . . 25 9.3. Adding an Address to an Interface . . . . . . . . . . . . 25
9.4. Removing an Address from an Interface . . . . . . . . . . 25 9.4. Removing an Address from an Interface . . . . . . . . . . 26
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 27 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 27
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 27 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 27
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 28 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 28
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 30 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 30
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 30 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 30
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 32 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 32
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 32 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 32
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 33 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 33
12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 34 12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 34
12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 35 12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 35
skipping to change at page 3, line 45 skipping to change at page 4, line 4
17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 50 17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 50
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
18.1. Normative References . . . . . . . . . . . . . . . . . . . 51 18.1. Normative References . . . . . . . . . . . . . . . . . . . 51
18.2. Informative References . . . . . . . . . . . . . . . . . . 51 18.2. Informative References . . . . . . . . . . . . . . . . . . 51
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 52 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 52
Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 53 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 53
Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 56 Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 56
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 59 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 59
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 60 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 60
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 61 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . . . 63
1. Introduction 1. Introduction
This document describes a neighborhood discovery protocol (NHDP) for This document describes a neighborhood discovery protocol (NHDP) for
a mobile ad hoc network (MANET) [8]. This protocol uses an exchange a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an
of HELLO messages in order that each node can determine the presence exchange of HELLO messages in order that each node can determine the
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].
This neighborhood information is recorded in the form of Information This neighborhood information is recorded in the form of Information
Bases. These may be used by other protocols, such as MANET routing Bases. These may be used by other protocols, such as MANET routing
protocols, for determining local connectivity and node configuration. protocols, for determining local connectivity and node configuration.
This protocol is designed to maintain this information in the This protocol is designed to maintain this information in the
presence of a dynamic network topology. presence of a dynamic network topology.
This specification describes both the HELLO message exchange, the
messages being defined as instances of the specification [1], and the
information storage required for neighborhood discovery.
This protocol makes no assumptions about the underlying link layer, 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) [7]. contained in the Optimized Link State Routing Protocol (OLSR)
[RFC3626].
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5]. document are to be interpreted as described in RFC2119 [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
[1]. [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
by this protocol, and included in HELLO messages generated by this
protocol, may be either an address or an address prefix. These
can be represented as a single address object in a HELLO message,
as defined by [packetbb]. An address so represented is considered
to have a prefix length equal to its length (in bits) when
considered as an address object, and a 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
least one interface is heard by the other. least one interface is heard by the other.
skipping to change at page 7, line 23 skipping to change at page 7, 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 Does not require any changes to the format of IP datagrams, thus
any existing IP protocol stack can be used as is.
o Can use the link local multicast address and either the "manet" o Can use the link local multicast address and either the "manet"
UDP port or the "manet" IP protocol number specified in [2]. UDP port or the "manet" IP protocol number specified in
[manet-iana].
o Uses the packet and message formats specified in [1]. 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 [1]. 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.
o Provides each node with local topology information up to two hops o Provides each node with local topology information up to two hops
away. This information is made available to other protocols, of away. This information is made available to other protocols, of
which this protocol may be a part, in Information Bases defined in which this protocol may be a part, in Information Bases defined in
this specification. this specification.
o Is designed to work in a completely distributed manner, and does o Is designed to work in a completely distributed manner, and does
not depend on any central entity. not depend on any central entity.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
o To find the node's symmetric 2-hop neighbors. o To find the node's symmetric 2-hop neighbors.
o To record this information in Information Bases that can be used o To record this information in Information Bases that can be used
by other protocols, of which this neighborhood discovery protocol by other protocols, of which this neighborhood discovery protocol
may be a part. may be a part.
These objectives are achieved using local (one hop) signaling that: These objectives are achieved using local (one hop) signaling that:
o Advertises the presence of a node and its interfaces. o Advertises the presence of a node and its interfaces.
o Discovers links from adjacent nodes. o Discovers links with adjacent nodes.
o Performs bidirectionality checks on the discovered links. o Performs bidirectionality checks on the discovered links.
o Advertises discovered links, and whether each is symmetric, to its o Advertises discovered links, and whether each is symmetric, to its
1-hop neighbors, and hence discovers symmetric 2-hop neighbors. 1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
This specification defines, in turn: This specification defines, in turn:
o Parameters and constants used by the protocol. Parameters used by o Parameters and constants used by the protocol. Parameters used by
this protocol may be, where appropriate, specific to a MANET this protocol may be, where appropriate, specific to a MANET
skipping to change at page 9, line 42 skipping to change at page 9, line 42
Interfaces of both of these types are recorded in a node's Local Interfaces of both of these types are recorded in a node's Local
Information Base, which is used, but not updated, by the signaling of Information Base, which is used, but not updated, by the signaling of
this protocol. this protocol.
4.2. Information Base Overview 4.2. Information Base Overview
Each node maintains the Information Bases described in the following Each node maintains the Information Bases described in the following
sections. These are used for describing the protocol in this sections. These are used for describing the protocol in this
document. An implementation of this protocol MAY maintain this document. An implementation of this protocol MAY maintain this
information in the indicated form, or in any other organization which information in the indicated form, or in any other organization which
offers access to this information. offers access to this information. In particular note that it is not
necessary to remove Tuples from Sets at the exact time indicated,
only to behave as if the Tuples were removed at that time.
4.2.1. Local Information Base 4.2.1. Local Information Base
Each node maintains a Local Information Base, which contains: Each node maintains a Local Information Base, which contains:
o The Local Interface Set, which consists of Local Interface Tuples, o The Local Interface Set, which consists of Local Interface Tuples,
each of which records the addresses of an interface (MANET or non- each of which records the addresses of an interface (MANET or non-
MANET) of the node. MANET) of the node.
o The Removed Interface Address Set, which consists of Removed o The Removed Interface Address Set, which consists of Removed
skipping to change at page 12, line 32 skipping to change at page 12, line 32
indicates the length of time for which the message content is to indicates the length of time for which the message content is to
be considered valid, and included in the receiving node's be considered valid, and included in the receiving node's
Interface Information Base. Interface Information Base.
o A periodically generated HELLO message SHOULD include an o A periodically generated HELLO message SHOULD include an
INTERVAL_TIME message TLV that indicates the current value of INTERVAL_TIME message TLV that indicates the current value of
HELLO_INTERVAL for that MANET interface, i.e. the period within HELLO_INTERVAL for that MANET interface, i.e. the period within
which a further HELLO message is guaranteed to be sent on that which a further HELLO message is guaranteed to be sent on that
MANET interface. MANET interface.
o Additional information may be added by a protocol using thsi o Additional information may be added by a protocol using this
protocol using the TLV mechanisms described in [1]. For example, protocol using the TLV mechanisms described in [packetbb]. For
if multipoint relays (MPRs) are to be calculated similarly to as example, if multipoint relays (MPRs) are to be calculated
in OLSR [7] and signaled to neighbors, then this information may similarly to as in OLSR [RFC3626] and signaled to neighbors, then
be added to HELLO messages using an address block TLV. this information may be added to HELLO messages using an address
block TLV.
4.3.3. HELLO Message Processing 4.3.3. HELLO Message Processing
All HELLO messages received by a node are used to update: All HELLO messages received by a node are used to update:
o The Interface Information Base for the MANET interface on which o The Interface Information Base for the MANET interface on which
that HELLO message is received. that HELLO message is received.
o The Node Information Base. o The Node Information Base.
skipping to change at page 15, line 4 skipping to change at page 15, line 4
o To advertise this node's knowledge of each of its 1-hop neighbors. o To advertise this node's knowledge of each of its 1-hop neighbors.
The frequency of the advertisement of each such neighbor is The frequency of the advertisement of each such neighbor is
regulated by the interface parameter REFRESH_INTERVAL. regulated by the interface parameter REFRESH_INTERVAL.
Specifically, these parameters are as follows: Specifically, these parameters are as follows:
HELLO_INTERVAL - is the maximum time between the transmission of two HELLO_INTERVAL - is the maximum time between the transmission of two
successive HELLO messages on this MANET interface. If using successive HELLO messages on this MANET interface. If using
periodic transmission of HELLO messages, these SHOULD be at a periodic transmission of HELLO messages, these SHOULD be at a
separation of HELLO_INTERVAL, possibly modified by jitter as separation of HELLO_INTERVAL, possibly modified by jitter as
specified in [4]. specified in [RFC5148].
HELLO_MIN_INTERVAL - is the minimum interval between transmission of HELLO_MIN_INTERVAL - is the minimum interval between transmission of
two successive HELLO messages, on this MANET interface. (This two successive HELLO messages, on this MANET interface. (This
minimum interval MAY be modified by jitter, as defined in [4].) minimum interval MAY be modified by jitter, as defined in
[RFC5148].)
REFRESH_INTERVAL - is the maximum interval between advertisements in REFRESH_INTERVAL - is the maximum interval between advertisements in
a HELLO message of each 1-hop neighbor address and its status. In a HELLO message of each 1-hop neighbor address and its status. In
all intervals of length REFRESH_INTERVAL, a node MUST include all all intervals of length REFRESH_INTERVAL, a node MUST include all
1-hop neighbor information which it is specified as sending in at 1-hop neighbor information which it is specified as sending in at
least one HELLO message on this MANET interface. least one HELLO message on this MANET interface.
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o HELLO_INTERVAL > 0 o HELLO_INTERVAL > 0
o HELLO_MIN_INTERVAL >= 0 o HELLO_MIN_INTERVAL >= 0
o HELLO_INTERVAL >= HELLO_MIN_INTERVAL o HELLO_INTERVAL >= HELLO_MIN_INTERVAL
o REFRESH_INTERVAL >= HELLO_INTERVAL o REFRESH_INTERVAL >= HELLO_INTERVAL
o If INTERVAL_TIME message TLVs as defined in [3] are included in o If INTERVAL_TIME message TLVs as defined in [timetlv] are included
HELLO messages, then HELLO_INTERVAL MUST be representable as in HELLO messages, then HELLO_INTERVAL MUST be representable as
described in [3]. described in [timetlv].
If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its If REFRESH_INTERVAL > HELLO_INTERVAL, then a node may distribute its
neighbor advertisements between HELLO messages in any manner, subject neighbor advertisements between HELLO messages in any manner, subject
to the constraints above. to the constraints above.
For a node to employ this protocol in a purely responsive manner on a For a node to employ this protocol in a purely responsive manner on a
MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be
set to a value such that a responsive HELLO message is always set to a value such that a responsive HELLO message is always
expected in a shorter period than this. expected in a shorter period than this value.
5.1.2. Information Validity Times 5.1.2. Information Validity Times
The following interface parameters manage the validity time of link The following interface parameters manage the validity time of link
information: information:
L_HOLD_TIME - is the period of advertisement, on this MANET L_HOLD_TIME - is the period of advertisement, on this MANET
interface, of former 1-hop neighbor addresses as lost in HELLO interface, of former 1-hop neighbor addresses as lost in HELLO
messages, allowing recipients of these HELLO messages to messages, allowing recipients of these HELLO messages to
accelerate removal of information from their Link Sets. accelerate removal of information from their Link Sets.
skipping to change at page 16, line 17 skipping to change at page 16, line 17
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o L_HOLD_TIME >= 0 o L_HOLD_TIME >= 0
o H_HOLD_TIME >= REFRESH_INTERVAL o H_HOLD_TIME >= REFRESH_INTERVAL
o If HELLO messages can be lost then both SHOULD be significantly o If HELLO messages can be lost then both SHOULD be significantly
greater than REFRESH_INTERVAL. greater than REFRESH_INTERVAL.
o H_HOLD_TIME MUST be representable as described in [3]. o H_HOLD_TIME MUST be representable as described in [timetlv].
5.1.3. Link Quality 5.1.3. Link Quality
The following interface parameters manage the usage of link quality: The following interface parameters manage the usage of link quality
(see Section 4.4):
HYST_ACCEPT - is the link quality threshold at or above which a link HYST_ACCEPT - is the link quality threshold at or above which a link
becomes usable, if it was not already so. becomes usable, if it was not already so.
HYST_REJECT - is the link quality threshold below which a link HYST_REJECT - is the link quality threshold below which a link
becomes unusable, if it was not already so. becomes unusable, if it was not already so.
INITIAL_QUALITY - is the initial quality of a newly identified link. INITIAL_QUALITY - is the initial quality of a newly identified link.
INITIAL_PENDING - if true, then a newly identified link is INITIAL_PENDING - if true, then a newly identified link is
skipping to change at page 16, line 50 skipping to change at page 17, line 7
o If link quality is not updated, then INITIAL_QUALITY >= o If link quality is not updated, then INITIAL_QUALITY >=
HYST_ACCEPT. HYST_ACCEPT.
o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING == false. o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING == false.
o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING == true. o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING == true.
5.1.4. Jitter 5.1.4. Jitter
If jitter, as defined in [4], is used then these parameters are as If jitter, as defined in [RFC5148], is used then these parameters are
follows: as follows:
HP_MAXJITTER - represents the value of MAXJITTER used in [4] for HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
periodically generated HELLO messages on this MANET interface. for periodically generated HELLO messages on this MANET interface.
HT_MAXJITTER - represents the value of MAXJITTER used in [4] for HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
externally triggered HELLO messages on this MANET interface. for externally triggered HELLO messages on this MANET interface.
For constraints on these interface parameters see [4]. For constraints on these interface parameters see [RFC5148].
5.2. Node Parameters 5.2. Node Parameters
The two node parameters defined by this specification are in the The two node parameters defined by this specification are in the
category of information validity time. category of information validity time.
5.2.1. Information Validity Time 5.2.1. Information Validity Time
The following node parameter manages the validity time of lost The following node parameter manages the validity time of lost
symmetric 1-hop neighbor information: symmetric 1-hop neighbor information:
skipping to change at page 17, line 49 skipping to change at page 18, line 5
This section presents guidelines, applicable if protocol parameters This section presents guidelines, applicable if protocol parameters
are changed dynamically. are changed dynamically.
HELLO_INTERVAL HELLO_INTERVAL
* If the HELLO_INTERVAL for a MANET interface increases, then the * If the HELLO_INTERVAL for a MANET interface increases, then the
next HELLO message on this MANET interface MUST be generated next HELLO message on this MANET interface MUST be generated
according to the previous, shorter, HELLO_INTERVAL. Additional according to the previous, shorter, HELLO_INTERVAL. Additional
subsequent HELLO messages MAY be generated according to the subsequent HELLO messages MAY be generated according to the
previous, shorter, HELLO_INTERVAL. previous, shorter, HELLO_INTERVAL (but MUST include times
according to current parameters).
* If the HELLO_INTERVAL for a MANET interface decreases, then the * If the HELLO_INTERVAL for a MANET interface decreases, then the
following HELLO messages on this MANET interface MUST be following HELLO messages on this MANET interface MUST be
generated according to this current, shorter, HELLO_INTERVAL. generated according to this current, shorter, HELLO_INTERVAL.
REFRESH_INTERVAL REFRESH_INTERVAL
* If the REFRESH_INTERVAL for a MANET interface increases, then * If the REFRESH_INTERVAL for a MANET interface increases, then
the content of subsequent HELLO messages must be organized such the content of subsequent HELLO messages must be organized such
that the specification of the old value of REFRESH_INTERVAL is that the specification of the old value of REFRESH_INTERVAL is
skipping to change at page 18, line 47 skipping to change at page 19, line 7
* If HP_MAXJITTER changes, then the periodic HELLO message * If HP_MAXJITTER changes, then the periodic HELLO message
schedule on this MANET interface MAY be changed. schedule on this MANET interface MAY be changed.
HT_MAXJITTER HT_MAXJITTER
* If HT_MAXJITTER changes, then externally triggered HELLO * If HT_MAXJITTER changes, then externally triggered HELLO
messages on this MANET interface MAY be rescheduled. messages on this MANET interface MAY be rescheduled.
5.4. Constants 5.4. Constants
The constant C is used as specified in [3]. The constant C (time granularity) is used as specified in [timetlv].
6. Local Information Base 6. Local Information Base
A node maintains a Local Information Base that records information A node maintains a Local Information Base that records information
about its interfaces (MANET and non-MANET). Each interface MUST have about its interfaces (MANET and non-MANET). Each interface MUST have
at least one address, and MAY have more than one address. at least one address, and MAY have more than one address.
All addresses MUST have an associated prefix length. If an address The Local Information Base is not modified by signaling. If a node's
has no specified prefix length, then its prefix length is equal to interface configuration changes, then the Local Information Base MUST
the address length. Two addresses are considered equal if and only reflect these changes. This MAY also result in signaling to
if their associated prefix lengths are also equal. advertise these changes.
The Local Information Base is not modified by signaling. This
protocol responds to changes to this Local Information Base which
MUST reflect corresponding changes in the node's interface
configuration.
6.1. Local Interface Set 6.1. Local Interface Set
A node's Local Interface Set records its local interfaces. It A node's Local Interface Set records its local interfaces. It
consists of Local Interface Tuples, one per interface: consists of Local Interface Tuples, one per interface:
(I_local_iface_addr_list, I_manet) (I_local_iface_addr_list, I_manet)
where: where:
I_local_iface_addr_list is a list of the addresses of this I_local_iface_addr_list is an unordered list of the addresses of
interface. this interface.
I_manet is a boolean flag, describing if this interface is a MANET I_manet is a boolean flag, describing if this interface is a MANET
interface. interface.
6.2. Removed Interface Address Set 6.2. Removed Interface Address Set
A node's Removed Interface Address Set records addresses which were A node's Removed Interface Address Set records addresses which were
recently local interface addresses. If a node's interface addresses recently local interface addresses. If a node's interface addresses
are immutable then this set is always empty and MAY be omitted. It are immutable then this set is always empty and MAY be omitted. It
consists of Removed Interface Address Tuples, one per address: consists of Removed Interface Address Tuples, one per address:
skipping to change at page 21, line 13 skipping to change at page 21, line 13
IR_time specifies when this Tuple expires and MUST be removed. IR_time specifies when this Tuple expires and MUST be removed.
7. Interface Information Base 7. Interface Information Base
A node maintains an Interface Information Base for each of its MANET A node maintains an Interface Information Base for each of its MANET
interfaces. This records information about links to that MANET interfaces. This records information about links to that MANET
interface and symmetric 2-hop neighbors which can be reached in two interface and symmetric 2-hop neighbors which can be reached in two
hops using those links as the first hop. The Interface Information hops using those links as the first hop. The Interface Information
Base includes the Link Set and the 2-Hop Set. Base includes the Link Set and the 2-Hop Set.
A MANET interface address can be present in both the Link Set and as A MANET interface address can be present as of both a 1-hop neighbor
of a symmetric 2-hop neighbor. This allows the node with this MANET and a symmetric 2-hop neighbor. This allows the node with this MANET
interface address to be immediately considered as a symmetric 2-hop interface address to be immediately considered as a symmetric 2-hop
neighbor if it fails to be a symmetric 1-hop neighbor. neighbor if it fails to be a symmetric 1-hop neighbor.
All addresses MUST have an associated prefix length. Prefix lengths
are indicated in HELLO messages as specified in [1]; if an address
has no specified prefix length, then its prefix length is equal to
the address length. Two addresses are considered equal if and only
if their associated prefix lengths are also equal.
7.1. Link Set 7.1. Link Set
A node's Link Set records links from other nodes which are, or A node's Link Set records links from other nodes which are, or
recently were, 1-hop neighbors. It consists of Link Tuples, each recently were, 1-hop neighbors. It consists of Link Tuples, each
representing a single link: representing a single link:
(L_neighbor_iface_addr_list, L_HEARD_time, (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time,
L_SYM_time, L_quality, L_pending, L_lost, L_time) L_quality, L_pending, L_lost, L_time)
where: where:
L_neighbor_iface_addr_list is a list of the addresses of the MANET L_neighbor_iface_addr_list is an unordered list of the addresses of
interface of the 1-hop neighbor; the MANET interface of the 1-hop neighbor;
L_HEARD_time is the time until which the MANET interface of the L_HEARD_time is the time until which the MANET interface of the
1-hop neighbor would be considered heard if not considering link 1-hop neighbor would be considered heard if not considering link
quality; quality;
L_SYM_time is the time until which the link to the 1-hop neighbor L_SYM_time is the time until which the link to the 1-hop neighbor
would be considered symmetric if not considering link quality; would be considered symmetric if not considering link quality;
L_quality is a dimensionless number between 0 (inclusive) and 1 L_quality is a dimensionless number between 0 (inclusive) and 1
(inclusive) describing the quality of a link; a greater value of (inclusive) describing the quality of a link; a greater value of
skipping to change at page 22, line 4 skipping to change at page 21, line 45
L_SYM_time is the time until which the link to the 1-hop neighbor L_SYM_time is the time until which the link to the 1-hop neighbor
would be considered symmetric if not considering link quality; would be considered symmetric if not considering link quality;
L_quality is a dimensionless number between 0 (inclusive) and 1 L_quality is a dimensionless number between 0 (inclusive) and 1
(inclusive) describing the quality of a link; a greater value of (inclusive) describing the quality of a link; a greater value of
L_quality indicating a higher quality link; L_quality indicating a higher quality link;
L_pending is a boolean flag, describing if a link is considered L_pending is a boolean flag, describing if a link is considered
pending (i.e. a candidate, but not yet established, link); pending (i.e. a candidate, but not yet established, link);
L_lost is a boolean flag, describing if a link is considered lost L_lost is a boolean flag, describing if a link is considered lost
due to link quality; due to link quality;
L_time specifies when this Tuple expires and MUST be removed. L_time specifies when this Tuple expires and MUST be removed.
The status of the link, as obtained through HELLO message exchange, The status of the link, as obtained through HELLO message exchange,
and also taking link quality into account, denoted L_status, is and also taking link quality into account is denoted L_status.
defined by:
L_status can take the values PENDING, HEARD, SYMMETRIC and LOST. The
values LOST, SYMMETRIC and HEARD are defined in Section 17.3. The
value PENDING is never used in a message, it is only used locally by
a node, and any value distinct from LOST, SYMMETRIC and HEARD may be
used.
L_status is defined by:
1. If L_pending is true, then L_status = PENDING; 1. If L_pending is true, then L_status = PENDING;
2. otherwise, if L_lost is true, then L_status = LOST; 2. otherwise, if L_lost is true, then L_status = LOST;
3. otherwise, if L_SYM_time is not expired, then L_status = 3. otherwise, if L_SYM_time is not expired, then L_status =
SYMMETRIC; SYMMETRIC;
4. otherwise, if L_HEARD_time is not expired, then L_status = HEARD; 4. otherwise, if L_HEARD_time is not expired, then L_status = HEARD;
skipping to change at page 22, line 37 skipping to change at page 22, line 37
symmetric links to symmetric 1-hop neighbors through which the symmetric links to symmetric 1-hop neighbors through which the
symmetric 2-hop neighbors can be reached. It consists of 2-Hop symmetric 2-hop neighbors can be reached. It consists of 2-Hop
Tuples, each representing a single interface address of a symmetric Tuples, each representing a single interface address of a symmetric
2-hop neighbor, and a single MANET interface of a symmetric 1-hop 2-hop neighbor, and a single MANET interface of a symmetric 1-hop
neighbor. neighbor.
(N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time) (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)
where: where:
N2_neighbor_iface_addr_list is a list of the addresses of the MANET N2_neighbor_iface_addr_list is an unordered list of the addresses of
interface of the symmetric 1-hop neighbor from which this the MANET interface of the symmetric 1-hop neighbor from which
information was received; this information was received;
N2_2hop_iface_addr is an address of an interface of a symmetric N2_2hop_iface_addr is an address of an interface of a symmetric
2-hop neighbor which has a symmetric link (using any MANET 2-hop neighbor which has a symmetric link (using any MANET
interface) to the indicated symmetric 1-hop neighbor; interface) to the indicated symmetric 1-hop neighbor;
N2_time specifies when this Tuple expires and MUST be removed. N2_time specifies when this Tuple expires and MUST be removed.
8. Node Information Base 8. Node Information Base
Each node maintains a Node Information Base that records information Each node maintains a Node Information Base that records information
about addresses of current and recently symmetric 1-hop neighbors. about addresses of current and recently symmetric 1-hop neighbors.
All addresses MUST have an associated prefix length. Prefix lengths
are indicated in HELLO messages as specified in [1]; if an address
has no specified prefix length, then its prefix length is equal to
the address length. Two addresses are considered equal if and only
if their associated prefix lengths are also equal.
8.1. Neighbor Set 8.1. Neighbor Set
A node's Neighbor Set records all interface addresses of each 1-hop A node's Neighbor Set records all interface addresses of each 1-hop
neighbor. It consists of Neighbor Tuples, each representing a single neighbor. It consists of Neighbor Tuples, each representing a single
1-hop neighbor: 1-hop neighbor:
(N_neighbor_iface_addr_list, N_symmetric) (N_neighbor_iface_addr_list, N_symmetric)
where: where:
N_neighbor_iface_addr_list is a list of the interface addresses of a N_neighbor_iface_addr_list is an unordered list of the interface
1-hop neighbor; addresses of a 1-hop neighbor;
N_symmetric is a boolean flag, describing if this is a symmetric N_symmetric is a boolean flag, describing if this is a symmetric
1-hop neighbor. 1-hop neighbor.
8.2. Lost Neighbor Set 8.2. Lost Neighbor Set
A node's Lost Neighbor Set records addresses of all interfaces of A node's Lost Neighbor Set records addresses of all interfaces of
nodes which recently were symmetric 1-hop neighbors, but are now nodes which recently were symmetric 1-hop neighbors, but are now
advertised as lost. It consists of Lost Neighbor Tuples, each advertised as lost. It consists of Lost Neighbor Tuples, each
representing a single such address: representing a single such address:
skipping to change at page 25, line 11 skipping to change at page 25, line 11
1. Remove the Interface Information Base for that MANET 1. Remove the Interface Information Base for that MANET
interface; interface;
2. All Neighbor Tuples for which none of the addresses in its 2. All Neighbor Tuples for which none of the addresses in its
N_neighbor_iface_addr_list are found in any N_neighbor_iface_addr_list are found in any
L_neighbor_iface_addr_list in any remaining Link Set, are L_neighbor_iface_addr_list in any remaining Link Set, are
removed. removed.
If a node removes the Local Interface Tuple that contains the If a node removes the Local Interface Tuple that contains the
interface address that is used to define the node's originator interface address that is used to define the node's originator
address, as defined in [1], then the node MAY change originator address, as defined in [packetbb], then the node MAY change
address. originator address.
If the removed interface is the last MANET interface of the node, If the removed interface is the last MANET interface of the node,
then there will be no remaining Interface Information Bases, and the then there will be no remaining Interface Information Bases, and the
node will longer participate in this protocol. node will longer participate in this protocol.
A HELLO message MAY be sent on all remaining MANET interfaces. After removing the interface and making these changes, a HELLO
message MAY be sent on all remaining MANET interfaces.
9.3. Adding an Address to an Interface 9.3. Adding an Address to an Interface
If an address is added to an interface then this is indicated by the If an address is added to an interface then this is indicated by the
addition of an address to the appropriate I_local_iface_addr_list. addition of an address to the appropriate I_local_iface_addr_list.
The following changes MUST be made to the Information Bases: The following changes MUST be made to the Information Bases:
1. The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list 1. The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list
contains the added address, are removed. contains the added address, are removed.
skipping to change at page 25, line 45 skipping to change at page 25, line 46
Neighbor Tuples, if any Neighbor Tuples, if any
are removed; apply Section 13.1, but not Section 13.3. are removed; apply Section 13.1, but not Section 13.3.
3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr is the 3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr is the
added address, are removed. added address, are removed.
4. Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address, 4. Any 2-Hop Tuples whose N2_2hop_iface_addr is the added address,
are removed. are removed.
A HELLO message MAY be sent on all MANET interfaces. After adding the address and making these changes, a HELLO message
MAY be sent on all MANET interfaces.
9.4. Removing an Address from an Interface 9.4. Removing an Address from an Interface
If an address (henceforth removed address) is removed from an If an address (henceforth removed address) is removed from an
interface then this is indicated by the removal of that address from interface then:
the appropriate I_local_iface_addr_list. If this list is now empty
then the corresponding Local Interface Tuple MUST be removed.
Create a Removed Interface Address Tuple with: 1. Identify the Local Interface Tuple that corresponds to the
interface to be removed.
o IR_local_iface_addr = removed address; 2. If this is the only address of that interface (the only address
in the corresponding I_local_iface_addr_list) then remove that
interface as specified in Section 9.2.
o IR_time = current time + I_HOLD_TIME. 3. Otherwise:
1. Remove the removed address from this I_local_iface_addr_list.
2. Create a Removed Interface Address Tuple with:
+ IR_local_iface_addr = removed address;
+ IR_time = current time + I_HOLD_TIME.
If a node removes the interface address that is used to define the If a node removes the interface address that is used to define the
node's originator address, as defined in [1], then the node MAY node's originator address, as defined in [packetbb], then the node
change originator address. MAY change originator address.
A HELLO message MAY be sent on all MANET interfaces. After removing the address and making these changes, a HELLO message
MAY be sent on all MANET interfaces.
10. Packets and Messages 10. Packets and Messages
The packet and message format used by this protocol is defined in The packet and message format used by this protocol is defined in
[1], which is used with the following considerations: [packetbb], which is used with the following considerations:
o This protocol specifies one message type, the HELLO message. o This protocol specifies one message type, the HELLO message.
o HELLO message header options MAY be used as specified by a o HELLO message header options MAY be used as specified by a
protocol which uses this neighborhood discovery protocol. protocol which uses this neighborhood discovery protocol.
o HELLO messages MUST NOT be forwarded. o HELLO messages MUST NOT be forwarded.
o HELLO messages MAY be included in multi-message packets as o HELLO messages MAY be included in multi-message packets as
specified in [1]. specified in [packetbb].
o Packet header options MAY be used as specified by a protocol which o Packet header options MAY be used as specified by a protocol which
uses this neighborhood discovery protocol. uses this neighborhood discovery protocol.
o Received HELLO messages MUST be parsed in accordance with [1]. A o Received HELLO messages MUST be parsed in accordance with
HELLO message which is not in conformance with [1] MUST be [packetbb]. A HELLO message which is not in conformance with
discarded. [packetbb] MUST be discarded.
o This protocol specifies three address block TLVs. It also uses o This protocol specifies three address block TLVs. It also uses
two message TLVs defined in [3]. These five TLV types are all two message TLVs defined in [timetlv]. These five TLV types are
defined only with Type Extension == 0. TLVs of other types, and all defined only with Type Extension == 0. TLVs of other types,
of these types but without Type Extension == 0, are ignored by and of these types but without Type Extension == 0, are ignored by
this protocol. All references in this protocol to, for example, a this protocol. All references in this protocol to, for example, a
TLV with Type == LINK_STATUS, are to be considered as referring to TLV with Type == LINK_STATUS, are to be considered as referring to
a TLV with Type == LINK_STATUS and Type Extension == 0. a TLV with Type == LINK_STATUS and Type Extension == 0.
10.1. HELLO Messages 10.1. HELLO Messages
A HELLO message MUST contain: A HELLO message MUST contain:
o A VALIDITY_TIME message TLV as specified in [3], representing o A VALIDITY_TIME message TLV as specified in [timetlv],
H_HOLD_TIME for the transmitting MANET interface. The options representing H_HOLD_TIME for the transmitting MANET interface.
included in [3] for representing zero and infinite times MUST NOT The options included in [timetlv] for representing zero and
be used. infinite times MUST NOT be used.
A HELLO message which is transmitted periodically SHOULD contain, and A HELLO message which is transmitted periodically SHOULD contain, and
otherwise MAY contain: otherwise MAY contain:
o An INTERVAL_TIME message TLV as specified in [3], representing o An INTERVAL_TIME message TLV as specified in [timetlv],
HELLO_INTERVAL for the transmitting MANET interface. The options representing HELLO_INTERVAL for the transmitting MANET interface.
included in [3] for representing zero and infinite times MUST NOT The options included in [timetlv] for representing zero and
be used. infinite times MUST NOT be used.
A HELLO message MAY contain: A HELLO message MAY contain:
o One or more address blocks, each with an associated TLV block. o One or more address blocks, each with an associated TLV block.
o Other message TLVs. o Other message TLVs.
10.1.1. Address Blocks 10.1.1. Address Blocks
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
skipping to change at page 28, line 24 skipping to change at page 28, line 24
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 | 8 bits | Specifies that the address is an address | | LOCAL_IF | 1 | Specifies that the address is an address |
| | | associated with the interface on which the | | | octet | associated with the interface on which the |
| | | message was sent (THIS_IF), another interface | | | | message was sent (THIS_IF), another interface |
| | | of the sending node (OTHER_IF), or an | | | | of the sending node (OTHER_IF), or an |
| | | unspecified interface of the sending node | | | | 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. Note that the value UNSPEC_IF is not used by this protocol. It is
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 | 8 bits | Specifies the status of the link from the | | LINK_STATUS | 1 | Specifies the status of the link from the |
| | | indicated address (LOST, SYMMETRIC or | | | octet | indicated address (LOST, SYMMETRIC or |
| | | HEARD). | | | | HEARD). |
| | | | | | | |
| OTHER_NEIGHB | 8 bits | Specifies that the address is (SYMMETRIC) | | OTHER_NEIGHB | 1 | Specifies that the address is (SYMMETRIC) |
| | | or was (LOST) of an interface of a | | | octet | or was (LOST) of an interface of a |
| | | symmetric 1-hop neighbor of the node | | | | symmetric 1-hop neighbor of the node |
| | | transmitting the HELLO message. | | | | transmitting the HELLO message. |
+--------------+--------+-------------------------------------------+ +--------------+--------+-------------------------------------------+
Table 2 Table 2
A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value == A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value ==
LOST) also performs the function of a TLV with Type == OTHER_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
skipping to change at page 32, line 8 skipping to change at page 32, line 8
excluded from each HELLO message. Each such TLV MUST be included excluded from each HELLO message. Each such TLV MUST be included
associated with that address in a HELLO message sent on that MANET associated with that address in a HELLO message sent on that MANET
interface in every interval of length equal to that MANET interface's interface in every interval of length equal to that MANET interface's
parameter REFRESH_INTERVAL. TLVs associated with the same address parameter REFRESH_INTERVAL. TLVs associated with the same address
included in the same HELLO message MAY be applied to the same or included in the same HELLO message MAY be applied to the same or
different copies of that address. different copies of that address.
11.2. HELLO Message Transmission 11.2. HELLO Message Transmission
HELLO messages are transmitted in the packet/message format specified HELLO messages are transmitted in the packet/message format specified
by [1] using the "LL-MANET-Routers" multicast address specified by by [packetbb] using the "LL-MANET-Routers" multicast address
[2] as destination IP address, using either the "manet" UDP port, or specified by [manet-iana] as destination IP address, using either the
the "manet" IP protocol number specified in [2]. "manet" UDP port, or the "manet" IP protocol number specified in
[manet-iana].
11.2.1. HELLO Message Jitter 11.2.1. HELLO Message Jitter
HELLO messages MAY be sent using periodic message generation or HELLO messages MAY be sent using periodic message generation or
externally triggered message generation. If using data link and externally triggered message generation. If using data link and
physical layers which are subject to packet loss due to collisions, physical layers which are subject to packet loss due to collisions,
HELLO messages SHOULD be jittered as described in [4]. HELLO messages SHOULD be jittered as described in [RFC5148].
Internally triggered message generation (such as due to a change in Internally triggered message generation (such as due to a change in
local interfaces) MAY be treated as if externally generated message local interfaces) MAY be treated as if externally generated message
generation, or MAY be not jittered. generation, or MAY be not jittered.
HELLO messages MUST NOT be forwarded, and thus message forwarding HELLO messages MUST NOT be forwarded, and thus message forwarding
jitter does not apply to HELLO messages. jitter does not apply to HELLO messages.
Each form of jitter described in [4] requires a parameter MAXJITTER. Each form of jitter described in [RFC5148] requires a parameter
These interface parameters may be dynamic, and are specified by: MAXJITTER. These interface parameters may be dynamic, and are
specified by:
o For periodic message generation: HP_MAXJITTER. o For periodic message generation: HP_MAXJITTER.
o For externally triggered message generation: HT_MAXJITTER. o For externally triggered message generation: HT_MAXJITTER.
When HELLO message generation is delayed in order that a HELLO When HELLO message generation is delayed in order that a HELLO
message is not sent within HELLO_MIN_INTERVAL of the previous HELLO message is not sent within HELLO_MIN_INTERVAL of the previous HELLO
message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
be reduced by jitter, with maximum reduction HP_MAXJITTER. In this be reduced by jitter, with maximum reduction HP_MAXJITTER. In this
case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL. case HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL.
skipping to change at page 33, line 16 skipping to change at page 33, line 16
On receiving a HELLO message, a node MUST first check if any address On receiving a HELLO message, a node MUST first check if any address
associated with a TLV with Type == LOCAL_IF is one of the receiving associated with a TLV with Type == LOCAL_IF is one of the receiving
node's current or recently used interface addresses (i.e. is in any node's current or recently used interface addresses (i.e. is in any
I_local_iface_addr_list in the Local Interface Set or is equal to any I_local_iface_addr_list in the Local Interface Set or is equal to any
IR_local_iface_addr in the Removed Interface Address Set). If so IR_local_iface_addr in the Removed Interface Address Set). If so
then the HELLO message MUST be discarded. then the HELLO message MUST be discarded.
Otherwise the receiving node MUST update its appropriate Interface Otherwise the receiving node MUST update its appropriate Interface
Information Base and its Node Information Base according to this Information Base and its Node Information Base according to this
section. If any changes satisfy any of the conditions described in section. Section 12.1 to Section 12.4 MUST be performed in the order
presented. If any changes satisfy any of the conditions described in
Section 13 then the indicated consequences MUST be applied Section 13 then the indicated consequences MUST be applied
immediately, unless noted otherwise. immediately, unless noted otherwise.
For the purpose of this section, note the following definitions: For the purpose of this section, note the following definitions:
o "validity time" is calculated from the VALIDITY_TIME message TLV o "validity time" is calculated from the VALIDITY_TIME message TLV
of the HELLO message as specified in [3]. All information in the of the HELLO message as specified in [timetlv]. All information
HELLO message has the same validity time. in the HELLO message has the same validity time.
o "Receiving Address List" is the I_local_iface_addr_list o "Receiving Address List" is the I_local_iface_addr_list
corresponding to the MANET interface on which the HELLO message corresponding to the MANET interface on which the HELLO message
was received was received
o "Sending Address List" is the list of the addresses contained in o "Sending Address List" is the list of the addresses contained in
the HELLO message with an associated TLV with Type == LOCAL_IF and the HELLO message with an associated TLV with Type == LOCAL_IF and
Value == THIS_IF. If the Sending Address List is otherwise empty, Value == THIS_IF. If the Sending Address List is otherwise empty,
then the Sending Address List contains a single address (with then the Sending Address List contains a single address (with
maximum prefix length) equal to the sending address of the IP maximum prefix length) equal to the sending address of the IP
skipping to change at page 41, line 20 skipping to change at page 41, line 20
o the Link Tuple is removed; o the Link Tuple is removed;
then: then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list, if no Link Tuples for any MANET L_neighbor_iface_addr_list, if no Link Tuples for any MANET
interface remain with: interface remain with:
* L_neighbor_iface_addr_list contained in * L_neighbor_iface_addr_list contained in
N_neighbor_iface_addr_list; N_neighbor_iface_addr_list; AND
* L_HEARD_time is not expired; * L_HEARD_time is not expired;
then remove the Neighbor Tuple. then remove the Neighbor Tuple.
14. Link Quality 14. Link Quality
Link quality is a mechanism whereby a node MAY take considerations Link quality is a mechanism whereby a node MAY take considerations
other than message exchange into account for determining when a link other than message exchange into account for determining when a link
is and is not a candidate for being considered as HEARD or SYMMETRIC. is and is not a candidate for being considered as HEARD or SYMMETRIC.
skipping to change at page 44, line 9 skipping to change at page 44, line 9
+ L_lost = true + L_lost = true
+ L_time = min(L_time, current time + L_HOLD_TIME) + L_time = min(L_time, current time + L_HOLD_TIME)
Any appropriate action indicted in Section 13 MUST also be taken. Any appropriate action indicted in Section 13 MUST also be taken.
If L_quality for a link is updated based on HELLO message reception, If L_quality for a link is updated based on HELLO message reception,
or on reception of a packet including a HELLO message, then L_quality or on reception of a packet including a HELLO message, then L_quality
MUST be updated prior to the HELLO message processing described in MUST be updated prior to the HELLO message processing described in
Section 12. (If the receipt of the HELLO message, or the packet Section 12. (If the receipt of the HELLO message, or the packet
containing it, creates the Link Tuple then instead the Link Tuple containing it, creates the Link Tuple then the Link Tuple MUST be
MUST be created with the updated, from INITIAL_QUALITY, L_quality created with the appropriately updated L_quality value, rather than
value.) with L_quality = INITIAL_QUALITY.)
14.4. Updating Link Quality 14.4. Updating Link Quality
A node MAY update link quality based on any information available to A node MAY update link quality based on any information available to
it. Particular cases that MAY be used include: it. Particular cases that MAY be used include:
o Information from the link layer, such as signal to noise ratio. o Information from the link layer, such as signal to noise ratio or
acknowledgement reception and loss information.
o Receipt or loss of packets. If packets include a packet sequence o Receipt or loss of packets. If packets include a packet sequence
number as defined in [1], then packets on a link SHOULD have number as defined in [packetbb], then packets on a link SHOULD
sequential packet sequence numbers, whether or not they include have sequential packet sequence numbers, whether or not they
HELLO messages. Link quality can be updated when a packet is include HELLO messages. Link quality can be updated when a packet
received based on, for example, whether the last N out of M is received based on, for example, whether the last N out of M
packets on the link were received, or a "leaky integrator" packets on the link were received, or a "leaky integrator"
tracking packets. tracking packets.
o Receipt or loss of HELLO messages. If the maximum interval o Receipt or loss of HELLO messages. If the maximum interval
between HELLO messages is known (such as by inclusion of a message between HELLO messages is known (such as by inclusion of a message
TLV with Type == INTERVAL_TIME, as defined in [3], in HELLO TLV with Type == INTERVAL_TIME, as defined in [timetlv], in HELLO
messages) then the loss of HELLO messages can be determined messages) then the loss of HELLO messages can be determined
without the need to receive a HELLO message. Note that if this without the need to receive a HELLO message. Note that if this
case is combined with the previous case then care must be taken to case is combined with the previous case then care must be taken to
avoid "double counting" a lost HELLO message in a lost packet. avoid "double counting" a lost HELLO message in a lost packet.
15. Proposed Values for Parameters and Constants 15. Proposed Values for Parameters and Constants
This section lists the parameters and constants used in the This section lists the parameters and constants used in the
specification of the protocol, and proposed values of each which may specification of the protocol, and proposed values of each which may
be used when a single value of each is used. be used when a single value of each is used.
skipping to change at page 49, line 10 skipping to change at page 49, line 10
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, which must be allocated
from the "Assigned Message Types" repository of [1] with assignment from the "Assigned Message Types" repository of [packetbb] with
as specified in Table 3. assignment 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. TLV Types
This specification defines three address block TLV types, which must This specification defines three address block TLV types, which must
be allocated from the "Assigned Address Block TLV Types" repository be allocated from the "Assigned Address Block TLV Types" repository
of [1] with assignments as specified in Table 4. of [packetbb] with assignments as specified in Table 4.
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
| 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 of the sending node. | | | | | interface of the sending node. |
| | | | | | | | | |
| | | 1-255 | RESERVED | | | | 1-255 | RESERVED |
skipping to change at page 50, line 5 skipping to change at page 50, line 5
| | | | (SYMMETRIC) or recently was | | | | | (SYMMETRIC) or recently was |
| | | | (LOST) of an interface of a | | | | | (LOST) of an interface of a |
| | | | symmetric 1-hop neighbor of the | | | | | symmetric 1-hop neighbor of the |
| | | | node transmitting the message. | | | | | node transmitting the message. |
| | | | | | | | | |
| | | 1-255 | RESERVED | | | | 1-255 | RESERVED |
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
Table 4 Table 4
Type extensions indicated as RESERVED may be allocated by standards Type extensions indicated as RESERVED may be allocated by standards
action, as specified in [6]. action, as specified in [RFC2434].
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 51, 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
[1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized [packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
MANET Packet/Message Format", Work In "Generalized MANET Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-11.txt, November 2007. Progress draft-ietf-manet-packetbb-12.txt, March 2008.
[2] Chakeres, I., "IANA Allocations for MANET Protocols", Work In [manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
Progress draft-ietf-manet-iana-07.txt, November 2007. Work In Progress draft-ietf-manet-iana-07.txt,
November 2007.
[3] Clausen, T. and C. Dearlove, "Representing multi-value time in [timetlv] Clausen, T. and C. Dearlove, "Representing multi-value
MANETs", Work In Progress draft-ietf-manet-timetlv-04.txt, time in MANETs", Work In
Progress draft-ietf-manet-timetlv-04.txt,
November 2007. November 2007.
[4] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", Work In considerations in MANETs", RFC 5148, February 2008.
Progress draft-ietf-manet-jitter-04.txt, December 2007.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. an IANA Considerations Section in RFCs", RFC 2434,
BCP 26, October 1998.
18.2. Informative References 18.2. Informative References
[7] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[8] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
Routing Protocol Performance Issues and Evaluation (MANET): Routing Protocol Performance Issues and
Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
Appendix A. Address Block TLV Combinations Appendix A. Address Block TLV Combinations
The algorithm for generating HELLO messages in Section 11 specifies The algorithm for generating HELLO messages in Section 11 specifies
which 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
skipping to change at page 53, line 11 skipping to change at page 53, line 11
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
Table 5 Table 5
Appendix B. HELLO Message Example Appendix B. HELLO Message Example
An example HELLO message, transmitted by an originator node with a An example HELLO message, transmitted by an originator node with a
single MANET interface, is as follows. The message uses IPv4 (four single MANET interface, is as follows. The message uses IPv4 (four
octet) addresses without 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 other than version number
(message semantics octet is 0) with a hop limit of 1 and a hop count (message semantics octet is 30) with a hop limit of 1 and a hop count
of 0. The overall message length is 49 octets. of 0. The overall message length is 49 octets.
The message contains a message TLV block with content length 8 octets The message contains a message TLV block with content length 8 octets
containing two message TLVs, of types VALIDITY_TIME and containing two message TLVs, of types VALIDITY_TIME and
INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating
that no start and stop indexes are included, and each has a value that each has a value. Each has a value length of 1 octet; the
length of 1 octet. The values included (0x6C and 0x58) are time values included (0x64 and 0x58) are time codes representing the
codes representing the default values of parameters H_HOLD_TIME and default values of parameters H_HOLD_TIME and HELLO_INTERVAL,
HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the respectively (6 seconds and 2 seconds) assuming the default value of
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 2 indicates no address tail, the head length of semantics octet value 1 indicates an address head but no address
3 octets indicates address mid sections of one octet each (Mid 0 to tail. The head length of 3 octets indicates address mid sections of
Mid 4). one 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 16) indicates The first is a LOCAL_IF TLV which (with semantics value 10) indicates
that a single address, with index 0 (i.e. Head:Mid 0) is the single that a single address, with index 0 (i.e. Head:Mid 0) is the single
local interface address of this node. The second is a LINK_STATUS local interface address of this node (the 1 octet value LOCAL_IF
TLV which (with semantics octet 32) specifies the link status values indicates that this address is of this interface). The second is a
of all reported neighbors in a single multivalue TLV which covers the LINK_STATUS TLV which (with semantics octet 44) specifies the link
addresses with indexes 1 to 4. The TLV value length of 4 octets status values of all reported neighbors in a single multivalue TLV
indicates one octet per value per address. The last four addresses which covers the addresses with indexes 1 to 4. The TLV value length
are first and second HEARD, third SYMMETRIC, and fourth LOST. of 4 octets indicates one octet per value per address. The last four
addresses are first and second HEARD, third 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 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 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 0 1 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 1 0| |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS |0 0 1 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| | 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 1 1 1 1 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 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 1 0 0|0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0| |0 0 0 0 0 0 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 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 1 0 1 0 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 |
skipping to change at page 60, line 8 skipping to change at page 60, line 8
A node MUST ensure that two successive HELLO messages sent on the A node MUST ensure that two successive HELLO messages sent on the
same MANET interface are separated by at least HELLO_MIN_INTERVAL. same MANET interface are separated by at least HELLO_MIN_INTERVAL.
(If using jitter then this may be reduced to a mean minimum value of (If using jitter then this may be reduced to a mean minimum value of
HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound
on the control traffic generated by each node in the network on the control traffic generated by each node in the network
employing this protocol. employing this protocol.
Appendix E. Contributors Appendix E. Contributors
This specification is the result of the joint efforts of the This specification is the result of the joint efforts of the
following contributors -- listed alphabetically. following contributors, listed alphabetically.
o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil> o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org> o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil> o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, o Christopher Dearlove, BAE Systems, UK,
skipping to change at page 62, line 11 skipping to change at page 62, line 11
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components: Joe Macker (NRL), Alan Cullen (BAE specification and its components: Joe Macker (NRL), Alan Cullen (BAE
Systems), and the entire IETF MANET working group. Systems), and the entire IETF MANET working group.
Authors' Addresses Authors' Addresses
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/
Christopher Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
Phone: +44 1245 242194 Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Justin W. Dean Justin W. Dean
Naval Research Laboratory Naval Research Laboratory
Phone: +1 202 767 3397 Phone: +1 202 767 3397
Email: jdean@itd.nrl.navy.mil EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/ URI: http://pf.itd.nrl.navy.mil/
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 63, line 44 skipping to change at line 2399
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 102 change blocks. 
198 lines changed or deleted 217 lines changed or added

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