draft-ietf-manet-nhdp-15.txt   rfc6130.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Internet Engineering Task Force (IETF) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Request for Comments: 6130 LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Category: Standards Track C. Dearlove
Expires: June 22, 2011 BAE Systems ATC ISSN: 2070-1721 BAE Systems ATC
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
The OLSRv2 Design Team April 2011
MANET Working Group
December 19, 2010
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-15
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).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 22, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6130.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 15
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction .....................................................4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation .................................................5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology .....................................................6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement .........................................9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning ..............................10
4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11 4.1. Routers and Interfaces ....................................11
4.2. Information Base Overview . . . . . . . . . . . . . . . . 12 4.2. Information Base Overview .................................12
4.2.1. Local Information Base . . . . . . . . . . . . . . . . 13 4.2.1. Local Information Base .............................13
4.2.2. Interface Information Bases . . . . . . . . . . . . . 13 4.2.2. Interface Information Bases ........................13
4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 14 4.2.3. Neighbor Information Base ..........................14
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14 4.3. Signaling Overview ........................................14
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 15 4.3.1. HELLO Message Generation ...........................15
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 16 4.3.2. HELLO Message Content ..............................16
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 17 4.3.3. HELLO Message Processing ...........................17
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Link Quality ..............................................17
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 18 5. Protocol Parameters and Constants ..............................18
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 18 5.1. Protocol and Port Numbers .................................18
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 18 5.2. Multicast Address .........................................18
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 18 5.3. Interface Parameters ......................................18
5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 19 5.3.1. Message Intervals ..................................19
5.3.2. Information Validity Times . . . . . . . . . . . . . . 21 5.3.2. Information Validity Times .........................21
5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 21 5.3.3. Link Quality .......................................22
5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.4. Jitter .............................................22
5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 22 5.4. Router Parameters .........................................23
5.4.1. Information Validity Time . . . . . . . . . . . . . . 22 5.4.1. Information Validity Time ..........................23
5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 23 5.5. Parameter Change Constraints ..............................23
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 24 5.6. Constants .................................................24
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 24 6. Local Information Base .........................................24
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 25 6.1. Local Interface Set .......................................25
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 25 6.2. Removed Interface Address Set .............................26
7. Interface Information Bases . . . . . . . . . . . . . . . . . 26 7. Interface Information Bases ....................................26
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Link Set ..................................................27
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2. 2-Hop Set .................................................28
8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 28 8. Neighbor Information Base ......................................28
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Neighbor Set ..............................................28
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 28 8.2. Lost Neighbor Set .........................................29
9. Local Information Base Changes . . . . . . . . . . . . . . . . 29 9. Local Information Base Changes .................................29
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 29 9.1. Adding an Interface .......................................29
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 29 9.2. Removing an Interface .....................................30
9.3. Adding a Network Address to an Interface . . . . . . . . . 30 9.3. Adding a Network Address to an Interface ..................30
9.4. Removing a Network Address from an Interface . . . . . . . 31 9.4. Removing a Network Address from an Interface ..............31
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31 10. Packets and Messages ..........................................32
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 32 10.1. HELLO Messages ...........................................32
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 33 10.1.1. Address Blocks ....................................33
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 34 11. HELLO Message Generation ......................................34
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 35 11.1. HELLO Message Specification ..............................35
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 37 11.2. HELLO Message Transmission ...............................37
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 37 11.2.1. HELLO Message Jitter ..............................37
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 38 12. HELLO Message Processing ......................................38
12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 38 12.1. Invalid Message ..........................................38
12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40 12.2. Definitions ..............................................40
12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 41 12.3. Updating the Neighbor Set ................................41
12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 42 12.4. Updating the Lost Neighbor Set ...........................42
12.5. Updating the Link Sets . . . . . . . . . . . . . . . . . . 42 12.5. Updating the Link Sets ...................................42
12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 44 12.6. Updating the 2-Hop Set ...................................44
13. Other Information Base Changes . . . . . . . . . . . . . . . . 45 13. Other Information Base Changes ................................45
13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 46 13.1. Link Tuple Symmetric .....................................46
13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 46 13.2. Link Tuple Not Symmetric .................................47
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 47 13.3. Link Tuple Heard Timeout .................................48
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 48 14. Link Quality ..................................................48
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 48 14.1. Deployment without Link Quality ..........................49
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 48 14.2. Basic Principles of Link Quality .........................49
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 49 14.3. When Link Quality Changes ................................50
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 50 14.4. Updating Link Quality ....................................51
15. Proposed Values for Parameters and Constants . . . . . . . . . 51 15. Proposed Values for Parameters and Constants ..................51
15.1. Message Interval Interface Parameters . . . . . . . . . . 51 15.1. Message Interval Interface Parameters ....................51
15.2. Information Validity Time Interface Parameters . . . . . . 51 15.2. Information Validity Time Interface Parameters ...........51
15.3. Information Validity Time Router Parameters . . . . . . . 51 15.3. Information Validity Time Router Parameters ..............52
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 51 15.4. Link Quality Interface Parameters ........................52
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 51 15.5. Jitter Interface Parameters ..............................52
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 52 15.6. Constants ................................................52
16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 52 16. Usage with Other Protocols ....................................52
17. Security Considerations . . . . . . . . . . . . . . . . . . . 54 17. Security Considerations .......................................54
17.1. Invalid HELLO Messages . . . . . . . . . . . . . . . . . . 55 17.1. Invalid HELLO Messages ...................................56
17.2. Authentication, Integrity and Confidentiality 17.2. Authentication, Integrity, and Confidentiality
Suggestions . . . . . . . . . . . . . . . . . . . . . . . 56 Suggestions ..............................................57
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 18. IANA Considerations ...........................................57
18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 57 18.1. Expert Review: Evaluation Guidelines .....................58
18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 57 18.2. Message Types ............................................58
18.3. Message-Type-Specific TLV Type Registries . . . . . . . . 57 18.3. Message-Type-Specific TLV Type Registries ................58
18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 58 18.4. Address Block TLV Types ..................................59
18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 60 18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values ...........60
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 61 19. Contributors ..................................................61
20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61 20. Acknowledgments ...............................................61
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 21. References ....................................................62
21.1. Normative References . . . . . . . . . . . . . . . . . . . 61 21.1. Normative References .....................................62
21.2. Informative References . . . . . . . . . . . . . . . . . . 62 21.2. Informative References ...................................62
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 62 Appendix A. Address Block TLV Combinations ........................63
Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 63 Appendix B. Constraints ...........................................64
Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 66 Appendix C. HELLO Message Example .................................66
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 68 Appendix D. Flow and Congestion Control ...........................69
Appendix E. Interval and Timer Illustrations . . . . . . . . . . 69 Appendix E. Interval and Timer Illustrations ......................70
E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 69 E.1. HELLO Message Generation Timing ..........................70
E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 75 E.2. HELLO Message Processing Timing ..........................76
E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 76 E.3. Other HELLO Message Timing ...............................77
Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 78 Appendix F. Topology Pictures ....................................79
F.1. Example 1: Standard Single Interface Topology . . . . . . 78 F.1. Example 1: Standard Single Interface Topology ............79
F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor . . 79 F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor ....80
F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor . . 80 F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor ....81
F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 80 F.4. Example 4: Dual Addressed Interfaces .....................81
F.5. Example 5: Dual Interface on 2-Hop Neighbor . . . . . . . 81 F.5. Example 5: Dual Interface on 2-Hop Neighbor ..............82
F.6. Example 6: Dual interface on 1-Hop Neighbor . . . . . . . 81 F.6. Example 6: Dual interface on 1-Hop Neighbor ..............82
F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors . . 82 F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors ...83
F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor . 83 F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor ..84
F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 83 F.9. Example 9: Dual Interface on All Routers .................85
F.10. Example 10: Dual Addressed Dual Interfaces on All F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers . . . . . . . . . . . . . . . . . . . . . . . . . 84 Routers ......................................86
F.11. Example 11: Single Addressed Dual Interface Locally . . . 85 F.11. Example 11: Single Addressed Dual Interface Locally ......87
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 a a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a
local exchange of HELLO messages in order that each router can local exchange of HELLO messages so that each router can determine
determine the presence of, and connectivity to, its 1-hop and the presence of, and connectivity to, its 1-hop and symmetric 2-hop
symmetric 2-hop neighbors. Messages are defined and sent in packets neighbors. Messages are defined and sent in packets according to the
according to the specification [RFC5444]. specification [RFC5444].
1-hop neighborhood information is recorded for use by MANET routing 1-hop neighborhood information is recorded for use by MANET routing
protocols to determine direct (1-hop) connectivity to neighboring protocols to determine direct (1-hop) connectivity to neighboring
routers. 2-hop symmetric neighborhood information is recorded so as routers. 2-hop symmetric neighborhood information is recorded so as
to enable MANET routing protocols to employ flooding reduction to enable MANET routing protocols to employ flooding reduction
techniques, e.g., to select reduced relay sets for use for network techniques, e.g., to select reduced relay sets for efficient network-
wide link state advertisements. wide traffic dissemination.
1-hop and symmetric 2-hop neighborhood information is recorded in the 1-hop and symmetric 2-hop neighborhood information is recorded in the
form of Information Bases. These are available for use by other form of Information Bases. These are available for use by other
protocols, such as MANET routing protocols, which require information protocols, such as MANET routing protocols, that require information
regarding the local network connectivity. This protocol is designed regarding the local network connectivity. This protocol is designed
to maintain the information in these Information Bases even in the to maintain the information in these Information Bases even in the
presence of a dynamic network topology and wireless communication presence of a dynamic network topology and wireless communication
channel characteristics. channel characteristics.
This protocol makes no assumptions about the underlying link layer, This protocol makes no assumptions about the underlying link layer,
other than support of local broadcast or multicast for communication other than support of local broadcast or multicast for communication
to 1-hop neighbor routers. Link layer information may be used if to 1-hop neighbor routers. Link-layer information may be used if
available and applicable. 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 (OLSR) Protocol
[RFC3626]. [RFC3626].
1.1. Motivation 1.1. Motivation
MANETs differ from more traditional wired and infrastructure-based MANETs differ from more traditional wired and infrastructure-based
wireless networks, due to their envisioned applicability also over wireless networks due to their envisioned applicability over more
more challenging communication channels (e.g., wireless, lossy, challenging communication channels (e.g., wireless, lossy, broadcast
broadcast channels with moderate and shared bandwidth, hidden and channels with moderate and shared bandwidth, hidden and exposed
exposed terminals and interference from other network devices and the terminals, and interference from other network devices and the
environment) and in more challenging topological conditions (e.g., environment) and in more challenging topological conditions (e.g.,
rapid and unpredictable mobility, dynamic and non-predetermined rapid and unpredictable mobility, dynamic and non-predetermined
network membership). network membership).
Due to the properties of wireless transmissions, communication Due to the properties of wireless transmissions, communication
between two neighboring routers may not be bi-directional; even if between two neighboring routers may not be bi-directional; even if
router A is able to receive packets from router B, the converse is router A is able to receive packets from router B, the converse is
not guaranteed to be true. Furthermore, because of the localized not guaranteed to be true. Furthermore, because of the localized
nature of wireless broadcast communication, neighboring routers nature of wireless broadcast communication, neighboring routers
within the same communications channel may have different sets of within the same communications channel may have different sets of
neighbors. That is, when using the same communication channel, even neighbors. That is, when using the same communication channel, even
if router A is able to exchange packets with router B and router B is if router A is able to exchange packets with router B, and router B
able to exchange packets with router C, then this does not guarantee is able to exchange packets with router C, this does not guarantee
that router A and router C can exchange packets directly. that router A and router C can exchange packets directly.
Each router in a MANET may use more than one communication channel. Each router in a MANET may use more than one communication channel.
In particular, between the same pair of routers, more than one In particular, between the same pair of routers, more than one
distinct communication channel may exist, each with different distinct communication channel may exist, each with different
properties. This may, for example, be the case where MANET routers properties. This may, for example, be the case where MANET routers
are equipped with multiple distinct wireless interfaces, operating at are equipped with multiple distinct wireless interfaces, operating at
different frequencies. different frequencies.
For use by MANET routing protocols, as well as for establishing a For use by MANET routing protocols, as well as for establishing a
router's neighbors, a router may also need to determine whether each router's neighbors, a router may also need to determine whether each
communication channel with that neighbor is bi-directional. communication channel with that neighbor is bi-directional.
The set of neighbor routers of a given MANET router may be The set of neighbor routers of a given MANET router may be
continuously changing, often due to router mobility or a changing continuously changing, often due to router mobility or a changing
physical environment in which the MANET is located. There is physical environment in which the MANET is located. There is
typically no information from lower layers which would enable an IP typically no information from lower layers that would enable an IP
routing protocol to detect and, as appropriate, react to such routing protocol to detect and, as appropriate, react to such
changes. Such changes can often take place on a short timescale, changes. Such changes can often take place on a short timescale,
such as of the order of seconds, requiring MANET routing protocols to such as of the order of seconds, requiring MANET routing protocols to
act rapidly to ensure suitable convergence properties. act rapidly to ensure suitable convergence properties.
MANET routing protocols, for example [RFC3626] and [RFC5449], often MANET routing protocols, for example [RFC3626] and [RFC5449], often
employ relay set reductions in order to conserve network capacity employ relay set reductions in order to conserve network capacity
when maintaining network-wide topological information, with when maintaining network-wide topological information, with
calculation of these reduced relay sets employing up to two hop calculation of these reduced relay sets employing up to two hop
information. information.
The neighborhood discovery protocol specified in this document The neighborhood discovery protocol specified in this document
provides continued tracking of neighborhood changes, link bi- provides continued tracking of neighborhood changes, link bi-
directionality, and local topological information up to two hops. directionality, and local topological information up to two hops.
Combined, this allows a MANET routing protocol access to information Combined, this allows a MANET routing protocol access to information
describing link establishment/disappearance, and provides the describing link establishment/disappearance and provides the
necessary topological information for reduced relay set selection and necessary topological information for reduced relay set selection and
other purposes. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
All terms introduced in [RFC5444], including "packet", "message", All terms introduced in [RFC5444], including "packet", "message",
"Address Block", "TLV Block", "TLV", "address", "address prefix", and "Address Block", "TLV Block", "TLV", "address", "address prefix", and
"address object" are to be interpreted as described therein. "address object" are to be interpreted as described therein.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Network Address - An address plus an associated prefix length. This Network Address:
may be an address with an associated maximum prefix length, or an An address plus an associated prefix length. This may be an
address prefix including a prefix length. A Network Address thus address with an associated maximum prefix length or an address
prefix including a prefix length. A network address thus
represents a range of addresses. represents a range of addresses.
Router - A MANET router which implements this neighborhood discovery Router:
A MANET router that implements this neighborhood discovery
protocol. protocol.
Interface - A router's attachment to a communications medium. An Interface:
interface is assigned one or more addresses. A router's attachment to a communications medium. An interface is
assigned one or more addresses.
MANET interface - An interface participating in a MANET and using MANET interface:
this neighborhood discovery protocol. A router may have several An interface participating in a MANET and using this neighborhood
MANET interfaces. discovery protocol. A router may have several MANET interfaces.
Heard - A MANET interface of router X is considered heard on a MANET Heard:
A MANET interface of router X is considered heard on a MANET
interface of a router Y if the latter can receive control interface of a router Y if the latter can receive control
messages, according to this specification, from the former. messages, according to this specification, from the former.
Link - A link between two MANET interfaces exists if either can be Link:
heard by the other. A link between two MANET interfaces exists if either can be heard
by the other.
Symmetric link - A symmetric link between two MANET interfaces Symmetric link:
exists if both can be heard by the other. A symmetric link between two MANET interfaces exists if both can
be heard by the other.
1-hop neighbor - A router X is a 1-hop neighbor of a router Y if a 1-hop neighbor:
MANET interface of router X is heard by a MANET interface of A router X is a 1-hop neighbor of a router Y if a MANET interface
router Y. of router X is heard by a MANET interface of router Y.
Symmetric 1-hop neighbor - A router X is a symmetric 1-hop neighbor Symmetric 1-hop neighbor:
of a router Y if a symmetric link exists between a MANET interface A router X is a symmetric 1-hop neighbor of a router Y if a
on router X and a MANET interface on router Y. symmetric link exists between a MANET interface on router X and a
MANET interface on router Y.
2-hop neighbor - A router X is a 2-hop neighbor of a router Y if 2-hop neighbor:
router X is a 1-hop neighbor of a 1-hop neighbor of router Y, but A router X is a 2-hop neighbor of a router Y if router X is a
is not router Y itself. 1-hop neighbor of a 1-hop neighbor of router Y, but is not router
Y itself.
Symmetric 2-hop neighbor - A router X is a symmetric 2-hop neighbor Symmetric 2-hop neighbor:
of a router Y if router X is a symmetric 1-hop neighbor of a A router X is a symmetric 2-hop neighbor of a router Y if router X
symmetric 1-hop neighbor of router Y, but is not router Y itself. is a symmetric 1-hop neighbor of a symmetric 1-hop neighbor of
router Y, but is not router Y itself.
1-hop neighborhood - The 1-hop neighborhood of a router X is the set 1-hop neighborhood:
of the 1-hop neighbors of router X. The 1-hop neighborhood of a router X is the set of the 1-hop
neighbors of router X.
Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a Symmetric 1-hop neighborhood:
router X is the set of the symmetric 1-hop neighbors of router X. The symmetric 1-hop neighborhood of a router X is the set of the
symmetric 1-hop neighbors of router X.
2-hop neighborhood - The 2-hop neighborhood of a router X is the set 2-hop neighborhood:
of the 2-hop neighbors of router X. (This may include routers in The 2-hop neighborhood of a router X is the set of the 2-hop
the 1-hop neighborhood of router X.) neighbors of router X. (This may include routers in the 1-hop
neighborhood of router X.)
Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a Symmetric 2-hop neighborhood:
router X is the set of the symmetric 2-hop neighbors of router X. The symmetric 2-hop neighborhood of a router X is the set of the
(This may include routers in the 1-hop neighborhood, or even in symmetric 2-hop neighbors of router X. (This may include routers
the symmetric 1-hop neighborhood, of router X.) in the 1-hop neighborhood, or even in the symmetric 1-hop
neighborhood, of router X.)
Constant - A numerical value which MUST be the same for all MANET Constant:
interfaces of all routers in the MANET, at all times. A numerical value that MUST be the same for all MANET interfaces
of all routers in the MANET, at all times.
Interface parameter - A boolean or numerical value, specified Interface parameter:
separately for each MANET interface of each router. A router MAY A boolean or numerical value, specified separately for each MANET
change interface parameter values at any time, subject to some interface of each router. A router MAY change interface parameter
constraints. values at any time, subject to some constraints.
Router parameter - A boolean or numerical value, specified for each Router parameter:
router, and not specific to an interface. A router MAY change A boolean or numerical value, specified for each router, and not
router parameter values at any time, subject to some constraints. specific to an interface. A router MAY change router parameter
values at any time, subject to some constraints.
Information Base - A collection of information maintained by this Information Base:
protocol, and which is to be made available to MANET routing A collection of information maintained by this protocol and which
protocols. An Information Base may be associated with a MANET is to be made available to MANET routing protocols. An
interface, or with a router. Information Base may be associated with a MANET interface or with
a router.
Furthermore, this document uses the following notational conventions: Furthermore, this document uses the following notational conventions:
X contains y, or y is contained in X, is an unordered list X contains y, or y is contained in X
membership operator. X is an unordered list and y is an element. An unordered list membership operator. X is an unordered list and
"X contains y" or "y is contained in X" returns true if the y is an element. "X contains y" or "y is contained in X" returns
unordered list X includes the element y, and returns false true if the unordered list X includes the element y, and returns
otherwise. false otherwise.
X contains Y, or Y is contained in X, is an unordered list inclusion X contains Y, or Y is contained in X
operator. X and Y are both unordered lists. "X contains Y" or "Y An unordered list inclusion operator. X and Y are both unordered
is contained in X" returns true if the unordered list X contains lists. "X contains Y" or "Y is contained in X" returns true if
all elements y which are contained in Y, and returns false the unordered list X contains all elements y which are contained
otherwise. in Y, and returns false otherwise.
A overlaps B, if A and B are network addresses, and the range of A overlaps B
addresses represented by A, and the range of addresses represented If A and B are network addresses, and the range of addresses
by B both contain at least one common address. (This is only represented by A and the range of addresses represented by B both
possible if one range is a sub-range of the other.) contain at least one common address. (This is only possible if
one range is a sub-range of the other.)
a := b, is an assignment operator, whereby the left side (a) is a := b
assigned the value of the right side (b). a and b may be values, An assignment operator, whereby the left side (a) is assigned the
network addresses, or unordered lists (they must be of the same value of the right side (b). a and b may be values, network
type). addresses, or unordered lists (they must be of the same type).
c = d, is a comparison operator, returning true if the value of the c = d
left side (c) is equal to the value of the right side (d). c and d A comparison operator, returning true if the value of the left
may be values, network addresses, or unordered lists (they must be side (c) is equal to the value of the right side (d). c and d may
of the same type). If c and d are unordered lists, then they are be values, network addresses, or unordered lists (they must be of
the same type). If c and d are unordered lists, then they are
considered to be equal if c contains d and d contains c (i.e., considered to be equal if c contains d and d contains c (i.e.,
they contain the same set of elements, regardless of the order in they contain the same set of elements, regardless of the order in
which they are recorded in the lists). If c and d are network which they are recorded in the lists). If c and d are network
addresses, they are considered equal only if both addresses and addresses, they are considered equal only if both addresses and
prefix lengths are equal (i.e., they represent the same ). prefix lengths are equal (i.e., they represent the same).
e != f, is a comparison operator, returning not (e = f). i.e., e != f
returning true where (e = f) would have returned false, and A comparison operator, returning not (e = f), i.e., returning true
returning false where (e = f) would have returned true. where (e = f) would have returned false, and returning false where
(e = f) would have returned true.
3. Applicability Statement 3. Applicability Statement
This protocol: This protocol:
o Is applicable to networks, especially wireless networks, in which o Is applicable to networks, especially wireless networks, in which
unknown neighbors can be reached by local broadcast or multicast unknown neighbors can be reached by local broadcast or multicast
packets. packets.
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
skipping to change at page 10, line 11 skipping to change at page 10, line 8
o Uses the packet and message formats specified in [RFC5444]. This o Uses the packet and message formats specified in [RFC5444]. This
includes the definition of a HELLO Message Type, used for includes the definition of a HELLO Message Type, used for
signaling local topology information. signaling local topology information.
o Allows "external" and "internal" extensibility as enabled by o Allows "external" and "internal" extensibility as enabled by
[RFC5444]. [RFC5444].
o May interact with, and be extended by, other protocols, such as o May interact with, and be extended by, other protocols, such as
MANET routing protocols, see Section 16. MANET routing protocols, see Section 16.
o Can use relevant link layer information if it is available. o Can use relevant link-layer information if it is available.
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.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The objective of this protocol is, for each router: The objective of this protocol is, for each router:
o To identify 1-hop neighbors and symmetric 1-hop neighbors of this o To identify 1-hop neighbors and symmetric 1-hop neighbors of this
router. router.
skipping to change at page 10, line 52 skipping to change at page 10, line 49
o Performs bi-directionality checks on the discovered links. o Performs bi-directionality 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, where appropriate, be specific to a given MANET this protocol may, where appropriate, be specific to a given MANET
interface, or to a MANET router. This protocol allows all interface or to a MANET router. This protocol allows all
parameters to be changed dynamically, and to be set independently parameters to be changed dynamically, and to be set independently
for each MANET router or MANET interface, as appropriate. for each MANET router or MANET interface, as appropriate.
o The Information Bases describing local interfaces, discovered o The Information Bases describing local interfaces, discovered
links and their status, current and former 1-hop neighbors, and links and their status, current and former 1-hop neighbors, and
symmetric 2-hop neighbors. symmetric 2-hop neighbors.
o The format of the HELLO message that is used for local signaling. o The format of the HELLO message that is used for local signaling.
o The generation of HELLO messages from some of the information in o The generation of HELLO messages from some of the information in
skipping to change at page 11, line 40 skipping to change at page 11, line 38
the range of addresses represented by that network address MUST the range of addresses represented by that network address MUST
satisfy the following properties: satisfy the following properties:
o It MUST be unique to this router, i.e., it MUST NOT be assigned o It MUST be unique to this router, i.e., it MUST NOT be assigned
to any interface of any other router. to any interface of any other router.
o If assigned to other MANET interfaces, on the same router, o If assigned to other MANET interfaces, on the same router,
these MANET interfaces MUST be isolated, i.e., addresses may these MANET interfaces MUST be isolated, i.e., addresses may
only be assigned to different interfaces on the same router if only be assigned to different interfaces on the same router if
no MANET interface on another router can communicate with both. no MANET interface on another router can communicate with both.
For example interfaces using distinct radio "channels" MAY be For example, interfaces using distinct radio "channels" MAY be
assigned the same address. assigned the same address.
o Has a set of interface parameters, defining the behavior of this o Has a set of interface parameters, defining the behavior of this
MANET interface. Each MANET interface MAY be individually MANET interface. Each MANET interface MAY be individually
parameterized. parameterized.
o Has an Interface Information Base, recording information regarding o Has an Interface Information Base, recording information regarding
links to this MANET interface and symmetric 2-hop neighbors which links to this MANET interface and symmetric 2-hop neighbors that
can be reached through such links. can be reached through such links.
o Generates and processes HELLO messages. o Generates and processes HELLO messages.
In addition to a set of MANET interfaces as described above, each In addition to a set of MANET interfaces as described above, each
router has: router has:
o A Local Information Base, containing the network addresses of the o A Local Information Base, containing the network addresses of the
interfaces (MANET and non-MANET) of this router. The contents of interfaces (MANET and non-MANET) of this router. The contents of
this Information Base are not changed by signaling. this Information Base are not changed by signaling.
skipping to change at page 12, line 30 skipping to change at page 12, line 28
this protocol. this protocol.
4.2. Information Base Overview 4.2. Information Base Overview
Each router maintains protocol state using Information Bases, Each router maintains protocol state using Information Bases,
described in the following sections. Each Information Base consists described in the following sections. Each Information Base consists
of a number of Protocol Sets. Each Protocol Set contains a number of of a number of Protocol Sets. Each Protocol Set contains a number of
Protocol Tuples. Protocol Tuples.
An implementation of this protocol MAY maintain this information in An implementation of this protocol MAY maintain this information in
the indicated form, or in any other organization which offers access the indicated form, or in any other organization that offers access
to this information. In particular, note that it is not necessary to to this information. In particular, note that it is not necessary to
remove Protocol Tuples from Protocol Sets at the exact time remove Protocol Tuples from Protocol Sets at the exact time
indicated, only to behave as if the Protocol Tuples were removed at indicated, only to behave as if the Protocol Tuples were removed at
that time. that time.
Information in the Local Information Base is defined locally, and Information in the Local Information Base is defined locally and
included in HELLO messages. Information in the Interface Information included in HELLO messages. Information in the Interface Information
Base and the Neighbor Information Base is determined from received Base and the Neighbor Information Base is determined from received
HELLO messages; some of this information may also be included in HELLO messages; some of this information may also be included in
transmitted HELLO messages. Such information has a limited duration transmitted HELLO messages. Such information has a limited duration
in which it is considered valid. This duration is determined from in which it is considered valid. This duration is determined from
the VALIDITY_TIME TLV in the HELLO message in which the information the VALIDITY_TIME TLV in the HELLO message in which the information
is received, which in turn is set by the router that originated the is received, which in turn is set by the router that originated the
HELLO message, using its corresponding interface parameter HELLO message, using its corresponding interface parameter
H_HOLD_TIME. H_HOLD_TIME.
skipping to change at page 14, line 6 skipping to change at page 14, line 8
o A 2-Hop Set, which records the existence of symmetric links o A 2-Hop Set, which records the existence of symmetric links
between symmetric 1-hop neighbors of this MANET interface and between symmetric 1-hop neighbors of this MANET interface and
other routers (symmetric 2-hop neighbors). The 2-Hop Set consists other routers (symmetric 2-hop neighbors). The 2-Hop Set consists
of 2-Hop Tuples, each of which records a network address of a of 2-Hop Tuples, each of which records a network address of a
symmetric 2-hop neighbor, and all network addresses of the symmetric 2-hop neighbor, and all network addresses of the
corresponding symmetric 1-hop neighbor. corresponding symmetric 1-hop neighbor.
The Link Set for a MANET interface is used for generating HELLO The Link Set for a MANET interface is used for generating HELLO
messages. Specifically, the Link Set information is included to both messages. Specifically, the Link Set information is included to both
allow other routers to identify symmetric links and to populate the allow other routers to identify symmetric links and to populate the
2-Hop Set. Recently lost links are recorded in the Link Set for a 2-Hop Set. Recently lost links are recorded in the Link Set for a
MANET interface so that they can be advertised in HELLO messages, MANET interface so that they can be advertised in HELLO messages,
accelerating their removal from relevant 1-hop neighbors' Link Sets. accelerating their removal from relevant 1-hop neighbors' Link Sets.
The Link Set for a MANET interface is itself updated on receiving a The Link Set for a MANET interface is itself updated on receiving a
HELLO message, including recording symmetric links as indicated HELLO message, including recording symmetric links as indicated
above. The 2-Hop Set for a MANET interface is updated as indicated above. The 2-Hop Set for a MANET interface is updated as indicated
above, and is not itself used in generating HELLO messages. above, and is not itself used in generating HELLO messages.
4.2.3. Neighbor Information Base 4.2.3. Neighbor Information Base
skipping to change at page 14, line 33 skipping to change at page 14, line 35
Neighbor Tuples are maintained as long as there are corresponding Neighbor Tuples are maintained as long as there are corresponding
Link Tuples. Link Tuples.
o The Lost Neighbor Set consists of Lost Neighbor Tuples, each of o The Lost Neighbor Set consists of Lost Neighbor Tuples, each of
which records a network address of a recently lost symmetric 1-hop which records a network address of a recently lost symmetric 1-hop
neighbor. neighbor.
The Neighbor Set associates all network addresses of each 1-hop The Neighbor Set associates all network addresses of each 1-hop
neighbor. These network addresses may be included when generating a neighbor. These network addresses may be included when generating a
HELLO message, so that other symmetric 1-hop neighbors can record HELLO message, so that other symmetric 1-hop neighbors can record
this information in a 2-Hop Set. The Neighbor Set can be updated on this information in a 2-Hop Set. The Neighbor Set can be updated on
receiving a HELLO message. receiving a HELLO message.
The Lost Neighbor Set is used to determine which network addresses The Lost Neighbor Set is used to determine which network addresses
are to be included in a HELLO message as being lost (of a recently are to be included in a HELLO message as being lost (of a recently
symmetric 1-hop neighbor). The Lost Neighbor Set can itself be symmetric 1-hop neighbor). The Lost Neighbor Set can itself be
updated on receiving a HELLO message. updated on receiving a HELLO message.
4.3. Signaling Overview 4.3. Signaling Overview
This protocol contains a signaling mechanism for maintaining the This protocol contains a signaling mechanism for maintaining the
skipping to change at page 15, line 36 skipping to change at page 15, line 39
by timers and validity information included in HELLO messages through by timers and validity information included in HELLO messages through
TLVs. The relationship between message timers and intervals is TLVs. The relationship between message timers and intervals is
illustrated in Appendix E. illustrated in Appendix E.
4.3.1. HELLO Message Generation 4.3.1. HELLO Message Generation
HELLO messages are generated by a router for each of its MANET HELLO messages are generated by a router for each of its MANET
interfaces, and MAY be sent: interfaces, and MAY be sent:
o Proactively, at a regular interval, known as HELLO_INTERVAL. o Proactively, at a regular interval, known as HELLO_INTERVAL.
HELLO_INTERVAL may be fixed, or may be dynamic. For example HELLO_INTERVAL may be fixed, or may be dynamic. For example,
HELLO_INTERVAL may be backed off due to congestion or network HELLO_INTERVAL may be backed off due to congestion or network
stability. stability.
o As a response to a change in the router itself, or its 1-hop o As a response to a change in the router itself, or its 1-hop
neighborhood, for example on first becoming active or in response neighborhood, for example, on first becoming active or in response
to a new, lost, or changed status link. to a new, lost, or changed status link.
o In a combination of these proactive and responsive mechanisms. o In a combination of these proactive and responsive mechanisms.
Jittering of HELLO message generation and transmission SHOULD be used Jittering of HELLO message generation and transmission SHOULD be used
as described in Section 11.2, unless the medium access control as described in Section 11.2, unless the medium access control
mechanism in use prevents any simultaneous transmissions by mechanism in use prevents any simultaneous transmissions by
potentially interfering routers. potentially interfering routers.
HELLO messages MAY be scheduled independently for each MANET HELLO messages MAY be scheduled independently for each MANET
skipping to change at page 16, line 21 skipping to change at page 16, line 23
o A HELLO message MUST contain all of the network addresses in the o A HELLO message MUST contain all of the network addresses in the
Local Interface Set of the router on which the HELLO message is Local Interface Set of the router on which the HELLO message is
being generated. This includes: being generated. This includes:
o At least one network address of each MANET interface of the o At least one network address of each MANET interface of the
router. router.
o Network addresses that include all source addresses of any IP o Network addresses that include all source addresses of any IP
datagrams sent by the router on any MANET interface. datagrams sent by the router on any MANET interface.
o All other network addresses of the router which are to be made o All other network addresses of the router that are to be made
known to any other router for any reason. known to any other router for any reason.
o For each MANET interface, within every time interval equal to the o For each MANET interface, within every time interval equal to the
corresponding REFRESH_INTERVAL, sent HELLO messages MUST corresponding REFRESH_INTERVAL, sent HELLO messages MUST
collectively include all of the relevant information in the collectively include all of the relevant information in the
corresponding Link Set and the Neighbor Information Base. Note corresponding Link Set and the Neighbor Information Base. Note
that when determining whether to include information in a HELLO that when determining whether to include information in a HELLO
message, the sender MUST consider all times up to the latest time message, the sender MUST consider all times up to the latest time
when it may send its next HELLO message on this MANET interface. when it may send its next HELLO message on this MANET interface.
skipping to change at page 16, line 51 skipping to change at page 17, line 4
consider the interval of length REFRESH_INTERVAL that will end at consider the interval of length REFRESH_INTERVAL that will end at
the latest possible time at which the next HELLO message will be the latest possible time at which the next HELLO message will be
sent on this MANET interface. (Normally, this will be sent on this MANET interface. (Normally, this will be
HELLO_INTERVAL past the current time, but MAY be earlier if this HELLO_INTERVAL past the current time, but MAY be earlier if this
router elects to divide its neighbor information among more than router elects to divide its neighbor information among more than
one HELLO message in order to reduce the size of its HELLO one HELLO message in order to reduce the size of its HELLO
messages.) All neighbor information MUST be sent in this messages.) All neighbor information MUST be sent in this
interval, i.e., the router MUST ensure that this HELLO message interval, i.e., the router MUST ensure that this HELLO message
includes all neighbor information that has not already been includes all neighbor information that has not already been
included in any HELLO messages sent since the start of this included in any HELLO messages sent since the start of this
interval (normally the current time - (REFRESH_INTERVAL - interval (normally, the current time - (REFRESH_INTERVAL -
HELLO_INTERVAL)). HELLO_INTERVAL)).
o A HELLO message MUST include exactly one VALIDITY_TIME Message o A HELLO message MUST include exactly one VALIDITY_TIME Message
TLV, as specified in [RFC5497], that indicates the length of time TLV, as specified in [RFC5497], that indicates the length of time
for which the message content is to be considered valid, and is for which the message content is to be considered valid, and is
therefore to be included in the receiving router's Interface therefore to be included in the receiving router's Interface
Information Base. Information Base.
o A periodically generated HELLO message SHOULD include exactly one o A periodically generated HELLO message SHOULD include exactly one
INTERVAL_TIME Message TLV, as specified in [RFC5497], that INTERVAL_TIME Message TLV, as specified in [RFC5497], that
skipping to change at page 17, line 51 skipping to change at page 18, line 4
and erroneous information in a HELLO message, maintaining the and erroneous information in a HELLO message, maintaining the
constraints on Information Base contents specified in Appendix B. constraints on Information Base contents specified in Appendix B.
4.4. Link Quality 4.4. Link Quality
Some links in a MANET may be marginal, e.g., due to adverse wireless Some links in a MANET may be marginal, e.g., due to adverse wireless
propagation. In order to avoid using such marginal links, a link propagation. In order to avoid using such marginal links, a link
quality value is recorded in each Link Tuple. A MANET router quality value is recorded in each Link Tuple. A MANET router
considers links for which an insufficient link quality is recorded as considers links for which an insufficient link quality is recorded as
lost. Modifying the recorded link quality in a Link Tuple is lost. Modifying the recorded link quality in a Link Tuple is
OPTIONAL. If link quality is not to be modified it MUST be set to OPTIONAL. If link quality is not to be modified, it MUST be set to
indicate an always usable quality link. indicate an always usable quality link.
Note that Link Quality is a "link admittance" mechanism, allowing a Note that link quality is a "link admittance" mechanism, allowing a
router to determine that a given link is too unstable to even router to determine that a given link is too unstable to even
consider for use. It is specifically not a link metric nor a consider for use. It is specifically not a link metric nor is it a
substitute for one. substitute for one.
Link quality information is only used locally and is not used in Link quality information is only used locally and is not used in
signaling. Routers may interoperate whether they are using the same, signaling. Routers may interoperate whether they are using the same,
different, or no, link quality information. Link quality information different, or no link quality information. Link quality information
is thus not equivalent to a link metric. is thus not equivalent to a link metric.
Link quality information is defined in this specification as a Link quality information is defined in this specification as a
normalized, dimensionless, value in the interval zero to one, normalized, dimensionless value in the interval zero to one,
inclusive, where the greater the value, the better the link quality. inclusive, where the greater the value, the better the link quality.
See Section 14 for further details. See Section 14 for further details.
5. Protocol Parameters and Constants 5. Protocol Parameters and Constants
The parameters and constants used in this specification are described The parameters and constants used in this specification are described
in this section. in this section.
5.1. Protocol and Port Numbers 5.1. Protocol and Port Numbers
This protocol specifies HELLO messages, which are included in packets This protocol specifies HELLO messages, which are included in packets
as defined by [RFC5444]. These packets may be sent either using the as defined by [RFC5444]. These packets may be sent using either the
"manet" protocol number or the "manet" well-known UDP port number, as "manet" protocol number or the "manet" well-known UDP port number, as
specified in [RFC5498]. specified in [RFC5498].
5.2. Multicast Address 5.2. Multicast Address
This protocol specifies HELLO messages, which are included in packets This protocol specifies HELLO messages, which are included in packets
as defined by [RFC5444]. These packets may be locally transmitted as defined by [RFC5444]. These packets may be locally transmitted
using the link local multicast address "LL-MANET-Routers", as using the link-local multicast address "LL-MANET-Routers", as
specified in [RFC5498]. specified in [RFC5498].
5.3. Interface Parameters 5.3. Interface Parameters
The interface parameters used by this specification may be classified The interface parameters used by this specification may be classified
into the following four categories: into the following four categories:
o Message intervals o Message intervals
o Information validity times o Information validity times
o Link quality o Link quality
o Jitter o Jitter
These are detailed in the following sections. These are detailed in the following sections.
Different MANET interfaces (on the same or on different routers) MAY Different MANET interfaces (on the same or on different routers) MAY
employ different interface parameter values, and MAY change their employ different interface parameter values and MAY change their
interface parameter values dynamically, subject to the constraints interface parameter values dynamically, subject to the constraints
given in this section. A particular case is where all MANET given in this section. A particular case is where all MANET
interfaces on all MANET routers within a given MANET employ the same interfaces on all MANET routers within a given MANET employ the same
set of interface parameter values. set of interface parameter values.
5.3.1. Message Intervals 5.3.1. Message Intervals
HELLO messages serve two principal functions: HELLO messages serve two principal functions:
o To advertise network addresses of this router's interface to its o To advertise network addresses of this router's interface to its
1-hop neighbors. The frequency of these advertisements is 1-hop neighbors. The frequency of these advertisements is
regulated by the interface parameters HELLO_INTERVAL and regulated by the interface parameters HELLO_INTERVAL and
HELLO_MIN_INTERVAL. HELLO_MIN_INTERVAL.
o To advertise this router's knowledge of each of its 1-hop o To advertise this router's knowledge of each of its 1-hop
neighbors. The frequency of the advertisement of each such neighbors. The frequency of the advertisement of each such
neighbor is regulated by the interface parameter REFRESH_INTERVAL. neighbor is 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:
successive HELLO messages on this MANET interface. If using The maximum time between the transmission of two successive HELLO
periodic transmission of HELLO messages, these SHOULD be at a messages on this MANET interface. If using periodic transmission
separation of HELLO_INTERVAL, possibly modified by jitter as of HELLO messages, these SHOULD be at a separation of
specified in [RFC5148]. HELLO_INTERVAL, possibly modified by jitter as specified in
[RFC5148].
HELLO_MIN_INTERVAL - is the minimum interval between transmission of HELLO_MIN_INTERVAL:
two successive HELLO messages, on this MANET interface. (This The minimum interval between transmission of two successive HELLO
minimum interval MAY be modified by jitter, as defined in messages on this MANET interface. (This minimum interval MAY be
[RFC5148].) modified by jitter, as defined in [RFC5148].)
REFRESH_INTERVAL - is the maximum interval between advertisements, REFRESH_INTERVAL:
in a HELLO message on this MANET interface, of each 1-hop neighbor The maximum interval between advertisements, in a HELLO message on
network address and its status. In all intervals of length this MANET interface, of each 1-hop neighbor network address and
REFRESH_INTERVAL, a router MUST include each 1-hop neighbor its status. In all intervals of length REFRESH_INTERVAL, a router
network address and its status in at least one HELLO message on MUST include each 1-hop neighbor network address and its status in
this MANET interface. (This may be in the same or in different at least one HELLO message on this MANET interface. (This may be
HELLO messages.) in the same or in different HELLO messages.)
REFRESH_INTERVAL thus represents the frequency at which a piece of REFRESH_INTERVAL thus represents the frequency at which a piece of
information, as received in HELLO messages, can be expected to be information, as received in HELLO messages, can be expected to be
refreshed. Thus, the REFRESH_INTERVAL is used as a basis for refreshed. Thus, the REFRESH_INTERVAL is used as a basis for
determining when such information expires in receiving routers (see determining when such information expires in receiving routers (see
Section 5.3.2). HELLO_INTERVAL represents the frequency of HELLO Section 5.3.2). HELLO_INTERVAL represents the frequency of HELLO
message emissions. Logically, HELLO_INTERVAL cannot be greater than message emissions. Logically, HELLO_INTERVAL cannot be greater than
the REFRESH_INTERVAL, otherwise information cannot be refreshed in a the REFRESH_INTERVAL; otherwise, information cannot be refreshed in a
timely manner. timely manner.
HELLO messages can, however, be sent with a higher frequency. A HELLO messages can, however, be sent with a higher frequency. A
possible use for sending HELLO messages at such a higher frequency possible use for sending HELLO messages at such a higher frequency
includes sending partial HELLO messages (e.g., accommodating includes sending partial HELLO messages (e.g., accommodating
constraints on packet sizes from the underlying medium) refreshing constraints on packet sizes from the underlying medium) refreshing
only part of the information in each HELLO message. Another use is only part of the information in each HELLO message. Another use is
for a router to send "empty HELLO messages", advertising its own for a router to send "empty HELLO messages", advertising its own
presence frequently in smaller HELLO messages (e.g., in case HELLO presence frequently in smaller HELLO messages (e.g., in case HELLO
message exchange success rates are used for link quality estimation, message exchange success rates are used for link quality estimation,
skipping to change at page 20, line 33 skipping to change at page 20, line 37
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 an INTERVAL_TIME Message TLV as defined in [RFC5497] is o If an INTERVAL_TIME Message TLV as defined in [RFC5497] is
included in a HELLO messages, then HELLO_INTERVAL MUST be included in a HELLO message, then HELLO_INTERVAL MUST be
representable as described in [RFC5497]. representable as described in [RFC5497].
If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute
its neighbor advertisements between HELLO messages in any manner, its neighbor advertisements between HELLO messages in any manner,
subject to the constraints above. subject to the constraints above.
In the absence of any changes to the local neighborhood, a router In the absence of any changes to the local neighborhood, a router
will send a HELLO message on a MANET interface after a (possibly will send a HELLO message on a MANET interface after an (possibly
jittered) interval of length HELLO_INTERVAL. For a router to employ jittered) interval of length HELLO_INTERVAL. For a router to employ
this protocol in a purely responsive manner on a MANET interface, this protocol in a purely responsive manner on a MANET interface,
i.e., for the router to only send HELLO messages on that MANET i.e., for the router to only send HELLO messages on that MANET
interface as a response to external events, HELLO_INTERVAL (and hence interface as a response to external events, HELLO_INTERVAL (and hence
also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such
that a responsive HELLO message is always expected with a shorter that a responsive HELLO message is always expected with a shorter
period than this value. period than this value.
If a router has more than one MANET interface, then, even if the If a router has more than one MANET interface, then, even if the
router configures different values of HELLO_INTERVAL on each MANET router configures different values of HELLO_INTERVAL on each MANET
interface, the router SHOULD configure the same value of interface, the router SHOULD configure the same value of
HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO
messages may be sent. (This ensures that changes observed on one messages may be sent. (This ensures that changes observed on one
MANET interface are reported on other MANET interfaces, so that 1-hop MANET interface are reported on other MANET interfaces, so that 1-hop
neighbors connected to the latter can maintain up to date 2-hop neighbors connected to the latter can maintain up-to-date 2-hop
neighborhood information.) neighborhood information.)
5.3.2. Information Validity Times 5.3.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:
interface, of former 1-hop neighbor network addresses as lost in The period of advertisement, on this MANET interface, of former
HELLO messages, allowing recipients of these HELLO messages to 1-hop neighbor network addresses as lost in HELLO messages,
accelerate removal of this information from their Link Sets. allowing recipients of these HELLO messages to accelerate removal
L_HOLD_TIME MAY be set to zero, if accelerated information removal of this information from their Link Sets. L_HOLD_TIME MAY be set
is not required. to zero, if accelerated information removal is not required.
H_HOLD_TIME - is used as the Value in the VALIDITY_TIME Message TLV H_HOLD_TIME:
included in all HELLO messages on this MANET interface. It is Used as the Value in the VALIDITY_TIME Message TLV included in all
then used by each router receiving such a HELLO message to HELLO messages on this MANET interface. It is then used by each
indicate the validity of the information taken from that HELLO router receiving such a HELLO message to indicate the validity of
message and recorded in the receiving router's Information Bases. the information taken from that HELLO message and recorded in the
receiving router's Information Bases.
Note that as each item of neighbor information is included in HELLO Note that as each item of neighbor information is included in HELLO
messages within an interval of length REFRESH_INTERVAL, constraints messages within an interval of length REFRESH_INTERVAL, constraints
on H_HOLD_TIME are based on REFRESH_INTERVAL, not on HELLO_INTERVAL. on H_HOLD_TIME are based on REFRESH_INTERVAL, not on HELLO_INTERVAL.
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 parameters SHOULD be o If HELLO messages can be lost, then both parameters SHOULD be
significantly greater than REFRESH_INTERVAL. significantly greater than REFRESH_INTERVAL.
o H_HOLD_TIME MUST be representable as described in [RFC5497]. o H_HOLD_TIME MUST be representable as described in [RFC5497].
5.3.3. Link Quality 5.3.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 14): (see Section 14):
HYST_ACCEPT - is the link quality threshold at or above which a link HYST_ACCEPT:
becomes usable, if it was not already so. The link quality threshold at or above which a link becomes
usable, if it was not already so.
HYST_REJECT - is the link quality threshold below which a link HYST_REJECT:
becomes unusable, if it was not already so. The link quality threshold below which a link becomes unusable, if
it was not already so.
INITIAL_QUALITY - is the initial quality of a newly identified link. INITIAL_QUALITY:
The initial quality of a newly identified link.
INITIAL_PENDING - if true, then a newly identified link is INITIAL_PENDING:
considered pending, and is not usable until the link quality has If true, then a newly identified link is considered pending, and
reached or exceeded the HYST_ACCEPT threshold. is not usable until the link quality has reached or exceeded the
HYST_ACCEPT threshold.
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1 o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1
o 0 <= INITIAL_QUALITY <= 1. o 0 <= INITIAL_QUALITY <= 1.
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.3.4. Jitter 5.3.4. Jitter
If jitter, as defined in [RFC5148], is used then these parameters are If jitter, as defined in [RFC5148], is used, then these parameters
as follows: are as follows:
HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] HP_MAXJITTER:
for periodically generated HELLO messages on this MANET interface. Represents the value of MAXJITTER used in [RFC5148] for
periodically generated HELLO messages on this MANET interface.
HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] HT_MAXJITTER:
for externally triggered HELLO messages on this MANET interface. Represents the value of MAXJITTER used in [RFC5148] for externally
triggered HELLO messages on this MANET interface.
For constraints on these interface parameters see [RFC5148]. For constraints on these interface parameters, see [RFC5148].
5.4. Router Parameters 5.4. Router Parameters
The two router parameters defined by this specification are in the The two router parameters defined by this specification are in the
category of information validity time. category of information validity time.
5.4.1. Information Validity Time 5.4.1. Information Validity Time
The following router parameter manages the validity time of lost The following router parameter manages the validity time of lost
symmetric 1-hop neighbor information: symmetric 1-hop neighbor information:
N_HOLD_TIME - is used as the period during which former 1-hop N_HOLD_TIME:
neighbor network addresses are advertised as lost in HELLO Used as the period during which former 1-hop neighbor network
messages, allowing recipients of these HELLO messages to addresses are advertised as lost in HELLO messages, allowing
accelerate removal of this information from their 2-Hop Sets. recipients of these HELLO messages to accelerate removal of this
N_HOLD_TIME MAY be set to zero, if accelerated information removal information from their 2-Hop Sets. N_HOLD_TIME MAY be set to
is not required. zero, if accelerated information removal is not required.
I_HOLD_TIME - is the period for which a recently used local I_HOLD_TIME:
interface network address is recorded. The period for which a recently used local interface network
address is recorded.
The following constraints applies to these router parameters: The following constraints apply to these router parameters:
o N_HOLD_TIME >= 0 o N_HOLD_TIME >= 0
o I_HOLD_TIME >= 0 o I_HOLD_TIME >= 0
5.5. Parameter Change Constraints 5.5. Parameter Change Constraints
If protocol parameters are changed dynamically, the constraints in If protocol parameters are changed dynamically, the constraints in
this section apply. this section apply.
HELLO_INTERVAL HELLO_INTERVAL
o If the HELLO_INTERVAL for a MANET interface increases, then the o 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. A number according to the previous, shorter, HELLO_INTERVAL. A number
of subsequent HELLO messages MAY be generated according to the of subsequent HELLO messages MAY be generated according to the
previous, shorter, HELLO_INTERVAL (but MUST include times previous, shorter, HELLO_INTERVAL (but MUST include times
according to current parameters). This ensures that "promises" according to current parameters). This ensures that "promises"
as to timely transmission of a future HELLO message is kept as to timely transmission of a future HELLO message are kept
until these previous promises have expired. until these previous promises have expired.
o If the HELLO_INTERVAL for a MANET interface decreases, then the o 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
o If the REFRESH_INTERVAL for a MANET interface increases, then o If the REFRESH_INTERVAL for a MANET interface increases, then
the content of subsequent HELLO messages must be organized such the content of subsequent HELLO messages must be organized such
that the specification of the old value of REFRESH_INTERVAL is that the specification of the old value of REFRESH_INTERVAL is
satisfied for a further period equal to the old value of satisfied for a further period equal to the old value of
REFRESH_INTERVAL. REFRESH_INTERVAL.
o If the REFRESH_INTERVAL for a MANET interface decreases, then o If the REFRESH_INTERVAL for a MANET interface decreases, then
it MAY be necessary to reschedule HELLO message generation on it MAY be necessary to reschedule HELLO message generation on
that MANET interface, in order that the specification of that MANET interface, in order for the specification of
REFRESH_INTERVAL is satisfied from the time of change. REFRESH_INTERVAL is satisfied from the time of change.
HYST_ACCEPT and HYST_REJECT HYST_ACCEPT and HYST_REJECT
o If HYST_ACCEPT or HYST_REJECT changes, then the appropriate o If HYST_ACCEPT or HYST_REJECT changes, then the appropriate
actions for link quality change, as specified in Section 14.3, actions for link quality change, as specified in Section 14.3,
MUST be taken. MUST be taken.
L_HOLD_TIME L_HOLD_TIME
skipping to change at page 24, line 49 skipping to change at page 25, line 13
router MUST be identified by at least one network address. Such router MUST be identified by at least one network address. Such
network addresses MAY be specific to that interface, or MAY in some network addresses MAY be specific to that interface, or MAY in some
circumstances be used by more than one interface as specified below. circumstances be used by more than one interface as specified below.
The Local Information Base is not modified by signaling. If a The Local Information Base is not modified by signaling. If a
router's interface configuration changes, then the Local Information router's interface configuration changes, then the Local Information
Base MUST reflect these changes. This MAY also result in signaling Base MUST reflect these changes. This MAY also result in signaling
to advertise these changes. to advertise these changes.
It is not necessary to include all addresses of an interface in the It is not necessary to include all addresses of an interface in the
Local Information Base, and hence in HELLO messages. However any Local Information Base, and hence in HELLO messages. However, any
address that may be the source address of an IP datagram sent from address that may be the source address of an IP datagram sent from
that interface MUST be included (and at least one address MUST be that interface MUST be included (and at least one address MUST be
included). A protocol using this specification MAY add additional included). A protocol using this specification MAY add additional
requirements to these, e.g., that any address that may be the requirements to these, e.g., that any address that may be the
destination address of an IP datagram is also included. destination address of an IP datagram is also included.
The addresses assigned to an interface are "owned" by the router, and The addresses assigned to an interface are "owned" by the router, and
MUST NOT be used by any other router as an interface address. If an MUST NOT be used by any other router as an interface address. If an
address has a prefix length and represents a range of addresses, this address has a prefix length and represents a range of addresses, this
applies to all addresses in that range (i.e., such ranges MUST NOT applies to all addresses in that range (i.e., such ranges MUST NOT
overlap). overlap).
The addresses assigned to different interfaces on the same router The addresses assigned to different interfaces on the same router
MUST be distinct (hence network address ranges MUST NOT overlap) MUST be distinct (hence, network address ranges MUST NOT overlap)
except that: except that:
o The same address MAY be assigned to any number of non-MANET o The same address MAY be assigned to any number of non-MANET
interfaces as well as to one (or more if the following condition interfaces as well as to one (or more if the following condition
also applies) MANET interface. also applies) MANET interface.
o The same address MAY be assigned to two (or more if each pair o The same address MAY be assigned to two (or more if each pair
satisfies this condition) MANET interfaces if those two MANET satisfies this condition) MANET interfaces if those two MANET
interfaces cannot communicate to, from, or one to and one from, interfaces cannot communicate to, from, or one to and one from any
any other MANET interface of another router. other MANET interface of another router.
6.1. Local Interface Set 6.1. Local Interface Set
A router's Local Interface Set records its local interfaces. It A router'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 an unordered list of the network I_local_iface_addr_list is an unordered list of the network
addresses of this interface. addresses of 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.
Local Interface Tuples are removed from the Local Interface Set only Local Interface Tuples are removed from the Local Interface Set only
when the routers' interface configuration changes, subject to when the routers' interface configuration changes, subject to
Section 9, i.e., they are not subject to timer-based expiration. Section 9, i.e., they are not subject to timer-based expiration.
6.2. Removed Interface Address Set 6.2. Removed Interface Address Set
A router's Removed Interface Address Set records network addresses A router's Removed Interface Address Set records network addresses
which were recently used as local interface network addresses. If a that were recently used as local interface network addresses. If a
router's interface network addresses are immutable then the Removed router's interface network addresses are immutable, then the Removed
Interface Address Set is always empty and MAY be omitted. It Interface Address Set is always empty and MAY be omitted. It
consists of Removed Interface Address Tuples, one per network consists of Removed Interface Address Tuples, one per network
address: address:
(IR_local_iface_addr, IR_time) (IR_local_iface_addr, IR_time)
where: where:
IR_local_iface_addr - is a recently used network address of an IR_local_iface_addr is a recently used network address of an
interface of this router. interface of this router.
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 Bases 7. Interface Information Bases
A router maintains an Interface Information Base for each of its A router maintains an Interface Information Base for each of its
MANET interfaces. This records information about links to that MANET 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 that can be reached in two
hops using those links as the first hop. Each Interface Information hops using those links as the first hop. Each Interface Information
Base includes a Link Set and a 2-Hop Set. Base includes a Link Set and a 2-Hop Set.
A network address of a symmetric 2-hop neighbor can also be present A network address of a symmetric 2-hop neighbor can also be present
as the network address of a 1-hop neighbor. This allows the router as the network address of a 1-hop neighbor. This allows the router
using this network address to be immediately considered as a using this network address to be immediately considered as a
symmetric 2-hop neighbor if it fails to be a symmetric 1-hop symmetric 2-hop neighbor if it fails to be a symmetric 1-hop
neighbor. neighbor.
An element which specifies a time is considered expired if the An element that specifies a time is considered expired if the current
current time is greater than or equal to that time. One such time is greater than or equal to that time. One such element,
element, present in most Tuples, indicates when expired that the present in most Tuples, indicates, when expired, that the Tuple
Tuple itself is considered expired and MUST be removed. Tuples which itself is considered expired and MUST be removed. Tuples that do not
do not have such a time element are removed at other times as have such a time element are removed at other times as specified; for
specified, for example a Neighbor Tuple is removed when all example, a Neighbor Tuple is removed when all corresponding Link
corresponding Link Tuples have been removed. Tuples have been removed.
7.1. Link Set 7.1. Link Set
An interface's Link Set records links from other routers which are, An interface's Link Set records links from other routers that are, or
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_SYM_time, (L_neighbor_iface_addr_list, L_HEARD_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 an unordered list of the network L_neighbor_iface_addr_list is an unordered list of the network
addresses of the MANET interface of the 1-hop neighbor; addresses of the MANET interface of the 1-hop neighbor;
L_HEARD_time - is the time up to which the MANET interface of the L_HEARD_time is the time up to 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 up to which the link to the 1-hop neighbor L_SYM_time is the time up to 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 low link quality; due to low 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 using link quality, is denoted L_status. L_status can take the and using link quality, is denoted L_status. L_status can take the
Values PENDING, HEARD, SYMMETRIC and LOST. The values LOST, Values PENDING, HEARD, SYMMETRIC, and LOST. The values LOST,
SYMMETRIC and HEARD are defined in Section 18.5. The Value PENDING SYMMETRIC, and HEARD are defined in Section 18.5. The Value PENDING
is never used in a HELLO message, it is only used locally by a is never used in a HELLO message, it is only used locally by a
router, and any Value distinct from LOST, SYMMETRIC and HEARD may be router, and any Value distinct from LOST, SYMMETRIC, and HEARD may be
used. used.
L_status is defined by: L_status is defined by:
1. If L_pending = true, then L_status := PENDING; 1. If L_pending = true, then L_status := PENDING;
2. otherwise, if L_lost = true, then L_status := LOST; 2. otherwise, if L_lost = 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 := 4. otherwise, if L_HEARD_time is not expired, then L_status :=
HEARD; HEARD;
5. otherwise, L_status := LOST. 5. otherwise, L_status := LOST.
7.2. 2-Hop Set 7.2. 2-Hop Set
skipping to change at page 28, line 10 skipping to change at page 28, line 25
neighbors, and the symmetric links to symmetric 1-hop neighbors neighbors, and the symmetric links to symmetric 1-hop neighbors
through which these symmetric 2-hop neighbors can be reached. It through which these symmetric 2-hop neighbors can be reached. It
consists of 2-Hop Tuples, each representing a single network address consists of 2-Hop Tuples, each representing a single network address
of a symmetric 2-hop neighbor, and a single MANET interface of a of a symmetric 2-hop neighbor, and a single MANET interface of a
symmetric 1-hop neighbor. symmetric 1-hop neighbor.
(N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time) (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)
where: where:
N2_neighbor_iface_addr_list - is an unordered list of the network N2_neighbor_iface_addr_list is an unordered list of the network
addresses of the MANET interface of the symmetric 1-hop neighbor addresses of the MANET interface of the symmetric 1-hop neighbor
from which this information was received; from which this information was received;
N2_2hop_addr - is a network address of a symmetric 2-hop neighbor N2_2hop_addr is a network address of a symmetric 2-hop neighbor
which has a symmetric link (using any MANET interface) to the that has a symmetric link (using any MANET interface) to the
indicated symmetric 1-hop neighbor; 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. Neighbor Information Base 8. Neighbor Information Base
Each router maintains a Neighbor Information Base that records Each router maintains a Neighbor Information Base that records
information about network addresses of current and recently symmetric information about network addresses of current and recently symmetric
1-hop neighbors. 1-hop neighbors.
8.1. Neighbor Set 8.1. Neighbor Set
A router's Neighbor Set records all network addresses of each 1-hop A router's Neighbor Set records all network 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_addr_list, N_symmetric) (N_neighbor_addr_list, N_symmetric)
where: where:
N_neighbor_addr_list - is an unordered list of the network addresses N_neighbor_addr_list is an unordered list of the network addresses
of a 1-hop neighbor; 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.
Neighbor Tuples are removed from the Neighbor Set only when Neighbor Tuples are removed from the Neighbor Set only when
corresponding Link Tuples expire from the routers' Link Set, i.e., corresponding Link Tuples expire from the routers' Link Set, i.e.,
Neighbor Tuples are not directly subject to timer-based expiration. Neighbor Tuples are not directly subject to timer-based expiration.
8.2. Lost Neighbor Set 8.2. Lost Neighbor Set
A router's Lost Neighbor Set records network addresses of routers A router's Lost Neighbor Set records network addresses of routers
which recently were symmetric 1-hop neighbors, but which are now that recently were symmetric 1-hop neighbors but that 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 network address: representing a single such network address:
(NL_neighbor_addr, NL_time) (NL_neighbor_addr, NL_time)
where: where:
NL_neighbor_addr - is a network address of a router which recently NL_neighbor_addr is a network address of a router that recently
was a symmetric 1-hop neighbor of this router; was a symmetric 1-hop neighbor of this router;
NL_time - specifies when this Tuple expires and MUST be removed. NL_time specifies when this Tuple expires and MUST be removed.
9. Local Information Base Changes 9. Local Information Base Changes
The Local Information Base MUST be updated in response to changes in The Local Information Base MUST be updated in response to changes in
the router's local interface configuration. These MAY also change the router's local interface configuration. These MAY also change
the Interface Information Base and the Neighbor Information Base. If the Interface Information Base and the Neighbor Information Base. If
any changes to the latter Information Bases satisfy any of the any changes to the latter Information Bases satisfy any of the
conditions described in Section 13, then those changes MUST be conditions described in Section 13, then those changes MUST be
applied immediately, unless noted otherwise below. applied immediately, unless noted otherwise below.
A router MAY transmit HELLO messages in response to these changes. A router MAY transmit HELLO messages in response to these changes.
9.1. Adding an Interface 9.1. Adding an Interface
If an interface is added to the router, then this is indicated by the If an interface is added to the router, then this is indicated by the
addition of a Local Interface Tuple to the Local Interface Set. If addition of a Local Interface Tuple to the Local Interface Set. If
the new interface is a MANET interface, then an initially empty the new interface is a MANET interface, then an initially empty
Interface Information Base MUST be created for this new MANET Interface Information Base MUST be created for this new MANET
interface. The actions in Section 9.3 MUST be taken for each network interface. The actions in Section 9.3 MUST be taken for each network
address of this added interface. A HELLO message MAY be sent on all address of this added interface. A HELLO message MAY be sent on all
MANET interfaces, it SHOULD be sent on the new interface if it is a MANET interfaces, it SHOULD be sent on the new interface if it is a
MANET interface. If using scheduled messages, then a message MANET interface. If using scheduled messages, then a message
schedule MUST be established on the new MANET interface. schedule MUST be established on the new MANET interface.
9.2. Removing an Interface 9.2. Removing an Interface
skipping to change at page 30, line 12 skipping to change at page 30, line 29
other Local Interface Tuple, then create a Removed Interface other Local Interface Tuple, then create a Removed Interface
Address Tuple with: Address Tuple with:
o IR_local_iface_addr := removed address; o IR_local_iface_addr := removed address;
o IR_time := current time + I_HOLD_TIME. o IR_time := current time + I_HOLD_TIME.
3. Remove that Local Interface Tuple from the Local Interface Set. 3. Remove that Local Interface Tuple from the Local Interface Set.
4. If the interface to be removed is a MANET interface (i.e., with 4. If the interface to be removed is a MANET interface (i.e., with
I_manet = true) then: I_manet = true), then:
1. Remove the Interface Information Base for that MANET 1. Remove the Interface Information Base for that MANET
interface; interface;
2. All Neighbor Tuples for which none of the network addresses 2. All Neighbor Tuples for which none of the network addresses
in its N_neighbor_addr_list are contained in any in its N_neighbor_addr_list are contained in any
L_neighbor_iface_addr_list in any remaining Link Tuple, are L_neighbor_iface_addr_list in any remaining Link Tuple are
removed. removed.
If the removed interface is the last MANET interface of the router, If the removed interface is the last MANET interface of the router,
then there will be no remaining Interface Information Bases, and the then there will be no remaining Interface Information Bases, and the
router will no longer participate in this protocol. router will no longer participate in this protocol.
After removing the interface and making these changes, a HELLO After removing the interface and making these changes, a HELLO
message MAY be sent on all remaining MANET interfaces. message MAY be sent on all remaining MANET interfaces.
9.3. Adding a Network Address to an Interface 9.3. Adding a Network Address to an Interface
If a network address is added to an interface then this is indicated If a network address is added to an interface, then this is indicated
by the addition of a network address to the appropriate by the addition of a network address to the appropriate
I_local_iface_addr_list. The following changes MUST be made to the I_local_iface_addr_list. The following changes MUST be made to the
Information Bases: Information Bases:
1. Remove any Removed Interface Address Tuple whose 1. Remove any Removed Interface Address Tuple whose
IR_local_iface_addr is the added network address. IR_local_iface_addr is the added network address.
2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a 2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a
network address that overlaps the added network address. network address that overlaps the added network address.
3. Remove any Link Tuples, in any Link Set, for which either: 3. Remove any Link Tuples, in any Link Set, for which either:
o L_neighbor_iface_addr_list contains any network address in the o L_neighbor_iface_addr_list contains any network address in the
N_neighbor_addr_list of any removed Neighbor Tuple; OR N_neighbor_addr_list of any removed Neighbor Tuple; OR
o L_neighbor_iface_addr_list contains a network address that o L_neighbor_iface_addr_list contains a network address that
overlaps the added network address. overlaps the added network address.
Apply Section 13.2, but not Section 13.3. Apply Section 13.2 but not Section 13.3.
4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps 4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps
the added network address. the added network address.
5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added 5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added
network address. network address.
After adding the network address and making these changes, a HELLO After adding the network address and making these changes, a HELLO
message MAY be sent on all MANET interfaces. message MAY be sent on all MANET interfaces.
These changes, other than to the appropriate I_local_iface_addr_list, These changes, other than to the appropriate I_local_iface_addr_list,
are made in order to maintain consistency of the Information Bases. are made in order to maintain consistency of the Information Bases.
Specifically, these changes remove any record of any use of this Specifically, these changes remove any record of any use of this
network address by routers in the 1-hop neighborhood or in the network address by routers in the 1-hop neighborhood or in the
symmetric 2-hop neighborhood of this router. symmetric 2-hop neighborhood of this router.
9.4. Removing a Network Address from an Interface 9.4. Removing a Network Address from an Interface
If a network address (henceforth removed address) is removed from an If a network address (henceforth removed address) is removed from an
interface then: interface, then:
1. Identify the Local Interface Tuple that corresponds to the 1. Identify the Local Interface Tuple that corresponds to the
removed address. removed address.
2. If this is the only network address of that interface (the only 2. If this is the only network address of that interface (the only
network address in the corresponding I_local_iface_addr_list) network address in the corresponding I_local_iface_addr_list),
then remove that interface as specified in Section 9.2. then remove that interface as specified in Section 9.2.
3. Otherwise: 3. Otherwise:
1. Remove the removed address from this I_local_iface_addr_list. 1. Remove the removed address from this I_local_iface_addr_list.
2. If the removed address is not in the I_local_iface_addr_list 2. If the removed address is not in the I_local_iface_addr_list
of any other Local Interface Tuple, then create a Removed of any other Local Interface Tuple, then create a Removed
Interface Address Tuple with: Interface Address Tuple with:
skipping to change at page 32, line 17 skipping to change at page 32, line 33
o A HELLO message MAY use any combination of Message Header options o A HELLO message MAY use any combination of Message Header options
specified in [RFC5444]. specified in [RFC5444].
o HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if o HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if
present, MUST have the value 1. present, MUST have the value 1.
o HELLO messages MAY be included in multi-message packets as o HELLO messages MAY be included in multi-message packets as
specified in [RFC5444]. specified in [RFC5444].
o Received HELLO messages MUST be parsed in accordance with o Received HELLO messages MUST be parsed in accordance with
[RFC5444]. A HELLO message which is not in conformance with [RFC5444]. A HELLO message that is not in conformance with
[RFC5444] MUST be discarded without being processed. A HELLO [RFC5444] MUST be discarded without being processed. A HELLO
message can also be discarded without being processed for other message can also be discarded without being processed for other
reasons, see Section 12.1. reasons, see Section 12.1.
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 [RFC5497]. These five TLV Types are two Message TLVs defined in [RFC5497]. These five TLV Types are
all defined only with Type Extension = 0. TLVs of other types, all defined only with Type Extension = 0. TLVs of other types,
and 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 specification to, for this protocol. All references in this specification to, for
example, an Address Block TLV with Type = LINK_STATUS, are to be example, an Address Block TLV with Type = LINK_STATUS, are to be
skipping to change at page 33, line 36 skipping to change at page 33, line 52
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
| LOCAL_IF | 1 octet | Specifies that the network address is | | LOCAL_IF | 1 octet | Specifies that the network address is |
| | | associated with the MANET interface on which | | | | associated with the MANET interface on which |
| | | the message was sent (THIS_IF) or another | | | | the message was sent (THIS_IF) or another |
| | | interface of the sending router (OTHER_IF). | | | | interface of the sending router (OTHER_IF). |
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
Table 1: LOCAL_IF TLV definition Table 1: LOCAL_IF TLV Definition
Address Blocks MAY contain current or recently lost 1-hop neighbors' Address Blocks MAY contain current or recently lost 1-hop neighbors'
network addresses, represented as address objects (see [RFC5444]), network addresses, represented as address objects (see [RFC5444]),
each of which is associated with one or both Address Block TLVs as each of which is associated with one or both Address Block TLVs as
described in Table 2. described in Table 2.
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
| LINK_STATUS | 1 octet | Specifies the status of the link from | | LINK_STATUS | 1 octet | Specifies the status of the link from |
| | | the indicated network address and to the | | | | the indicated network address and to the |
| | | MANET interface over which the HELLO | | | | MANET interface over which the HELLO |
| | | message is transmitted (LOST, SYMMETRIC | | | | message is transmitted (LOST, SYMMETRIC, |
| | | or HEARD). | | | | or HEARD). |
| OTHER_NEIGHB | 1 octet | Specifies that the network address is | | OTHER_NEIGHB | 1 octet | Specifies that the network address is |
| | | (SYMMETRIC) or was (LOST) of a MANET | | | | (SYMMETRIC) or was (LOST) of a MANET |
| | | interface of a symmetric 1-hop neighbor | | | | interface of a symmetric 1-hop neighbor |
| | | of the router transmitting the HELLO | | | | of the router transmitting the HELLO |
| | | message. | | | | message. |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition Table 2: LINK_STATUS and OTHER_NEIGHB TLV Definition
An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or
Value = LOST also performs the function of an Address Block TLV with Value = LOST also performs the function of an Address Block TLV with
Type = OTHER_NEIGHB and the same Value. Including the latter Type = OTHER_NEIGHB and the same Value. Including the latter
associated with the same address object is discouraged for efficiency associated with the same address object is discouraged for efficiency
reasons. If an Address Block TLV with Type = LINK_STATUS and Value = reasons. If an Address Block TLV with Type = LINK_STATUS and Value =
SYMMETRIC is combined with an Address Block TLV with Type = SYMMETRIC is combined with an Address Block TLV with Type =
OTHER_NEIGHB and Value = LOST associated with the same address OTHER_NEIGHB and Value = LOST associated with the same address
object, then the latter MUST be ignored, and SHOULD NOT be included. object, then the latter MUST be ignored and SHOULD NOT be included.
See Appendix A. See Appendix A.
Other network addresses MAY be represented as address objects (see Other network addresses MAY be represented as address objects (see
[RFC5444]) and included in Address Blocks, but MUST NOT be associated [RFC5444]) and included in Address Blocks, but MUST NOT be associated
with any of the Address Block TLVs specified in this specification. with any of the Address Block TLVs specified in this specification.
11. HELLO Message Generation 11. HELLO Message Generation
Each MANET interface MUST generate HELLO messages according to the Each MANET interface MUST generate HELLO messages according to the
specification in this section. HELLO messages are generated for each specification in this section. HELLO messages are generated for each
MANET interface independently. HELLO message generation and MANET interface independently. HELLO message generation and
scheduling MUST be according to the interface parameters for that scheduling MUST be according to the interface parameters for that
MANET interface, and MAY be independent for each MANET interface or, MANET interface, and MAY be independent for each MANET interface or,
interface parameters permitting, MANET interfaces MAY use the same interface parameters permitting, MANET interfaces MAY use the same
schedule. schedule.
If transmitting periodic HELLO messages then, following a HELLO If transmitting periodic HELLO messages, then, following a HELLO
message transmission on a MANET interface, another HELLO message MUST message transmission on a MANET interface, another HELLO message MUST
be transmitted on the same MANET interface after an interval not be transmitted on the same MANET interface after an interval not
greater than HELLO_INTERVAL. Two successive HELLO message greater than HELLO_INTERVAL. Two successive HELLO message
transmissions on the same MANET interface MUST be separated by at transmissions on the same MANET interface MUST be separated by at
least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1. least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.
11.1. HELLO Message Specification 11.1. HELLO Message Specification
HELLO messages are generated independently on each MANET interface. HELLO messages are generated independently on each MANET interface.
All network addresses in any I_local_iface_addr_list MUST be All network addresses in any I_local_iface_addr_list MUST be
included, represented as address objects (see [RFC5444]), except included, represented as address objects (see [RFC5444]), except
that: that:
o If the interface on which the HELLO message is to be sent has a o If the interface on which the HELLO message is to be sent has a
single address with maximum prefix length (i.e., /32 for IPv4, single address with maximum prefix length (i.e., /32 for IPv4,
/128 for IPv6) then that address MAY be omitted, provided that /128 for IPv6), then that address MAY be omitted, provided that
this address is included as the sending address of the IP datagram this address is included as the sending address of the IP datagram
in which the HELLO message is included. in which the HELLO message is included.
All such included address objects MUST be associated with an Address All such included address objects MUST be associated with an Address
Block TLV with Type := LOCAL_IF and Value according to the following: Block TLV with Type := LOCAL_IF and Value according to the following:
o If the address object represents a network address of the sending o If the address object represents a network address of the sending
MANET interface, then Value := THIS_IF. MANET interface, then Value := THIS_IF.
o Otherwise, Value := OTHER_IF. o Otherwise, Value := OTHER_IF.
If such a network address is included in more than one If such a network address is included in more than one
I_local_iface_addr_list, then, for efficiency reasons, it is I_local_iface_addr_list, then, for efficiency reasons, it is
encouraged that the corresponding address object is associated with encouraged that the corresponding address object is associated with
only one Value using an Address Block TLV with Type := LOCAL_IF, this only one Value using an Address Block TLV with Type := LOCAL_IF; this
MUST be Value := THIS_IF if the address object represents a network MUST be Value := THIS_IF if the address object represents a network
address of the sending MANET interface. address of the sending MANET interface.
The following network addresses of current or former 1-hop neighbors The following network addresses of current or former 1-hop neighbors
MAY be represented as address objects (see [RFC5444]) and included in MAY be represented as address objects (see [RFC5444]) and included in
any HELLO message, respecting the parameter REFRESH_INTERVAL for each any HELLO message, respecting the parameter REFRESH_INTERVAL for each
association for that MANET interface, and according to the following: association for that MANET interface, and according to the following:
o Network addresses of MANET interfaces of 1-hop neighbors from the o Network addresses of MANET interfaces of 1-hop neighbors from the
Link Set of the Interface Information Base for this MANET Link Set of the Interface Information Base for this MANET
skipping to change at page 36, line 12 skipping to change at page 36, line 22
interface (i.e., from an L_neighbor_iface_addr_list with L_status interface (i.e., from an L_neighbor_iface_addr_list with L_status
= LOST). = LOST).
o Other network addresses of previously symmetric 1-hop neighbors o Other network addresses of previously symmetric 1-hop neighbors
from the Lost Neighbor Set of this router's Neighbor Information from the Lost Neighbor Set of this router's Neighbor Information
Base (i.e., from an NL_neighbor_addr). Base (i.e., from an NL_neighbor_addr).
Each such address object (see [RFC5444]) MUST be associated with one Each such address object (see [RFC5444]) MUST be associated with one
or more appropriate Address Block TLVs. Specifically: or more appropriate Address Block TLVs. Specifically:
1. For each address object (henceforth linked address) which 1. For each address object (henceforth linked address) that
represents a network address contained in an represents a network address contained in an
L_neighbor_iface_addr_list of a Link Tuple in the Link Set for L_neighbor_iface_addr_list of a Link Tuple in the Link Set for
this MANET interface, for which L_status != PENDING, include the this MANET interface, for which L_status != PENDING, include the
linked address with an associated Address Block TLV with: linked address with an associated Address Block TLV with:
o Type := LINK_STATUS; AND o Type := LINK_STATUS; AND
o Value := L_status. o Value := L_status.
2. For each address object (henceforth neighbor address) which 2. For each address object (henceforth neighbor address) that
represents a network address contained in an N_neighbor_addr_list represents a network address contained in an N_neighbor_addr_list
in a Neighbor Tuple with N_symmetric = true, and which has not in a Neighbor Tuple with N_symmetric = true and that has not
already been included with an associated Address Block TLV with already been included with an associated Address Block TLV with
Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor
network address with an associated Address Block TLV with: network address with an associated Address Block TLV with:
o Type := OTHER_NEIGHB; AND o Type := OTHER_NEIGHB; AND
o Value := SYMMETRIC. o Value := SYMMETRIC.
3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth 3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth
lost address) has not already been represented as an address lost address) has not already been represented as an address
skipping to change at page 37, line 14 skipping to change at page 37, line 26
included or excluded from each HELLO message. Each such Address included or excluded from each HELLO message. Each such Address
Block TLV MUST be included associated with the address object Block TLV MUST be included associated with the address object
representation of that network address in a HELLO message sent on representation of that network address in a HELLO message sent on
that MANET interface in every interval of length equal to that MANET that MANET interface in every interval of length equal to that MANET
interface's parameter REFRESH_INTERVAL. Address Block TLVs interface's parameter REFRESH_INTERVAL. Address Block TLVs
associated with the same address object included in the same HELLO associated with the same address object included in the same HELLO
message MAY be applied to the same or different copies of that message MAY be applied to the same or different copies of that
address object. address object.
An implementation of this protocol MAY limit the information included An implementation of this protocol MAY limit the information included
in each HELLO message, for example to accommodate smaller MTU sizes. in each HELLO message, for example, to accommodate smaller MTU sizes.
HELLO messages remain constrained by the above requirements, in HELLO messages remain constrained by the above requirements, in
particular that all local interface information MUST be included in particular, that all local interface information MUST be included in
all HELLO messages, and that all neighbor information MUST be sent all HELLO messages, and that all neighbor information MUST be sent
within each interval of length REFRESH_INTERVAL. This neighbor within each interval of length REFRESH_INTERVAL. This neighbor
information MAY, however, be sent in the same or in different HELLO information MAY, however, be sent in the same or in different HELLO
messages. messages.
11.2. HELLO Message Transmission 11.2. HELLO Message Transmission
HELLO messages are transmitted in the format specified by [RFC5444]. HELLO messages are transmitted in the format specified by [RFC5444].
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 that are subject to packet loss due to collisions,
HELLO messages SHOULD be jittered as described in [RFC5148]. 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 [RFC5148] requires a parameter Each form of jitter described in [RFC5148] requires a parameter
MAXJITTER. These interface parameters may be dynamic, and are MAXJITTER. These interface parameters may be dynamic and are
specified by: 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, as be reduced by jitter, with maximum reduction HP_MAXJITTER, as
described in [RFC5148]. In this case HP_MAXJITTER MUST NOT be described in [RFC5148]. In this case, HP_MAXJITTER MUST NOT be
greater than HELLO_MIN_INTERVAL. greater than HELLO_MIN_INTERVAL.
12. HELLO Message Processing 12. HELLO Message Processing
On receiving a HELLO message, a router MUST first check if the On receiving a HELLO message, a router MUST first check if the
message is invalid for processing by this router, as defined in message is invalid for processing by this router, as defined in
Section 12.1 and, if so, discard the message without further Section 12.1 and, if so, discard the message without further
processing. Otherwise, for each received and valid HELLO message the processing. Otherwise, for each received and valid HELLO message,
receiving router MUST update its appropriate Interface Information the receiving router MUST update its appropriate Interface
Base and its Neighbor Information Base as specified in Section 12.3 Information Base and its Neighbor Information Base as specified in
to Section 12.6. These updates MUST be performed in the order in Section 12.3 to Section 12.6. These updates MUST be performed in the
which they are presented in this specification. If any changes order in which they are presented in this specification. If any
satisfy any of the conditions described in Section 13 then the changes satisfy any of the conditions described in Section 13, then
indicated consequences in that section MUST be applied immediately, the indicated consequences in that section MUST be applied
unless noted otherwise. immediately, unless noted otherwise.
All message processing, including determination of whether a message All message processing, including determination of whether a message
is invalid, considers only TLVs with Type Extension = 0. TLVs with is invalid, considers only TLVs with Type Extension = 0. TLVs with
any other type extension are ignored. All references to, for any other type extension are ignored. All references to, for
example, a TLV with Type = LINK_STATUS refer to a TLV with Type = example, a TLV with Type = LINK_STATUS refer to a TLV with Type =
LINK_STATUS and Type Extension = 0. LINK_STATUS and Type Extension = 0.
12.1. Invalid Message 12.1. Invalid Message
A received HELLO message is invalid for processing by this router if A received HELLO message is invalid for processing by this router if
skipping to change at page 40, line 30 skipping to change at page 40, line 46
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 an unordered list of network addresses o "Sending Address List" is an unordered list of network addresses
of the MANET interface over which the HELLO message was sent, of the MANET interface over which the HELLO message was sent,
i.e., is an unordered list of the network addresses represented by i.e., is an unordered list of the network addresses represented by
address objects contained in the HELLO message with an associated address objects contained in the HELLO message with an associated
Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If
the Sending Address List is otherwise empty, then the Sending the Sending Address List is otherwise empty, then the Sending
Address List contains a single network address with maximum prefix Address List contains a single network address with maximum prefix
length (i.e., /32 for IPv4, /128 for IPv6) with address equal to length (i.e., /32 for IPv4, /128 for IPv6) with an address equal
the sending address of the IP datagram in which the HELLO message to the sending address of the IP datagram in which the HELLO
was included. message was included.
o "Neighbor Address List" is an unordered list of all the network o "Neighbor Address List" is an unordered list of all the network
addresses of all the interfaces of the router which generated the addresses of all the interfaces of the router that generated the
HELLO message, i.e., is the Sending Address List, plus the network HELLO message, i.e., is the Sending Address List, plus the network
addresses represented by address objects contained in the HELLO addresses represented by address objects contained in the HELLO
message with an associated Address Block TLV with Type = LOCAL_IF message with an associated Address Block TLV with Type = LOCAL_IF
and Value = OTHER_IF. and Value = OTHER_IF.
o "EXPIRED" indicates that a timer is set to a value clearly o "EXPIRED" indicates that a timer is set to a value clearly
preceding the current time (e.g., , current time - 1). preceding the current time (e.g., current time - 1).
o "Removed Address List" is a list of network addresses created by o "Removed Address List" is a list of network addresses created by
this HELLO message processing which were formerly reported as this HELLO message processing that were formerly reported as local
local by the router originating the HELLO message, but which are by the router originating the HELLO message but that are not
not included in the Neighbor Address List. This list is included in the Neighbor Address List. This list is initialized
initialized as empty. as empty.
o "Lost Address List" is a subset of the Removed Address List o "Lost Address List" is a subset of the Removed Address List
containing network addresses which were formerly considered as containing network addresses that were formerly considered as
symmetric. This list is initialized as empty. symmetric. This list is initialized as empty.
12.3. Updating the Neighbor Set 12.3. Updating the Neighbor Set
On receiving a HELLO message, the router MUST update its Neighbor Set On receiving a HELLO message, the router MUST update its Neighbor Set
and populate the Removed Address List and Lost Address List: and populate the Removed Address List and Lost Address List:
1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples) 1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples)
where N_neighbor_addr_list contains any network address which where N_neighbor_addr_list contains any network address that
overlaps with any network address in the Neighbor Address List. overlaps with any network address in the Neighbor Address List.
2. If there are no matching Neighbor Tuples, then: 2. If there are no matching Neighbor Tuples, then:
1. Create a new Neighbor Tuple with: 1. Create a new Neighbor Tuple with:
o N_neighbor_addr_list := Neighbor Address List; o N_neighbor_addr_list := Neighbor Address List;
o N_symmetric := false. o N_symmetric := false.
3. If there is one matching Neighbor Tuple, then: 3. If there is one matching Neighbor Tuple, then:
1. If the matching Neighbor Tuple's N_neighbor_addr_list != 1. If the matching Neighbor Tuple's N_neighbor_addr_list !=
Neighbor Address List, then: Neighbor Address List, then:
1. For each network address (henceforth removed address) 1. For each network address (henceforth removed address)
which is contained in that N_neighbor_addr_list, but is that is contained in that N_neighbor_addr_list but that
not contained in the Neighbor Address List: is not contained in the Neighbor Address List:
1. Add removed address to the Removed Address List. 1. Add the removed address to the Removed Address List.
2. If N_symmetric = true, then add removed address to 2. If N_symmetric = true, then add the removed address
the Lost Address List. to the Lost Address List.
2. Update the matching Neighbor Tuple by: 2. Update the matching Neighbor Tuple by:
o N_neighbor_addr_list := Neighbor Address List. o N_neighbor_addr_list := Neighbor Address List.
4. If there are two or more matching Neighbor Tuples, then: 4. If there are two or more matching Neighbor Tuples, then:
1. For each network address (henceforth removed address) which 1. For each network address (henceforth removed address) that is
is contained in the N_neighbor_addr_list of any of the contained in the N_neighbor_addr_list of any of the matching
matching Neighbor Tuples but is not contained in the Neighbor Neighbor Tuples but is not contained in the Neighbor Address
Address List: List:
1. Add removed address to the Removed Address List. 1. Add removed address to the Removed Address List.
2. If N_symmetric = true, then add removed address to the 2. If N_symmetric = true, then add removed address to the
Lost Address List. Lost Address List.
2. Replace the matching Neighbor Tuples by a single Neighbor 2. Replace the matching Neighbor Tuples by a single Neighbor
Tuple with: Tuple with:
o N_neighbor_addr_list := Neighbor Address List; o N_neighbor_addr_list := Neighbor Address List;
o N_symmetric := false o N_symmetric := false
12.4. Updating the Lost Neighbor Set 12.4. Updating the Lost Neighbor Set
On receiving a HELLO message, a router MUST update its Lost Neighbor On receiving a HELLO message, a router MUST update its Lost Neighbor
Set: Set:
1. For each network address (henceforth lost address) which is 1. For each network address (henceforth lost address) that is
contained in the Lost Address List, if no Lost Neighbor Tuple contained in the Lost Address List, if no Lost Neighbor Tuple
with NL_neighbor_addr = lost address exists, then add a Lost with NL_neighbor_addr = lost address exists, then add a Lost
Neighbor Tuple with: Neighbor Tuple with:
o NL_neighbor_addr := lost address; o NL_neighbor_addr := lost address;
o NL_time := current time + N_HOLD_TIME. o NL_time := current time + N_HOLD_TIME.
12.5. Updating the Link Sets 12.5. Updating the Link Sets
On receiving a HELLO message, a router MUST update its Link Sets: On receiving a HELLO message, a router MUST update its Link Sets:
1. Remove all network addresses in the Removed Address List from the 1. Remove all network addresses in the Removed Address List from the
L_neighbor_iface_addr_list of all Link Tuples. L_neighbor_iface_addr_list of all Link Tuples.
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now 2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now
empty; apply Section 13.2, but not Section 13.3. empty; apply Section 13.2 but not Section 13.3.
The router MUST then update its Link Set for the MANET interface on The router MUST then update its Link Set for the MANET interface on
which the HELLO message is received: which the HELLO message is received:
1. Find all Link Tuples (henceforth matching Link Tuples) where: 1. Find all Link Tuples (henceforth matching Link Tuples) where:
o L_neighbor_iface_addr_list contains one or more network o L_neighbor_iface_addr_list contains one or more network
addresses in the Sending Address List. addresses in the Sending Address List.
2. If there is more than one matching Link Tuple, then remove them 2. If there is more than one matching Link Tuple, then remove them
all; apply Section 13.2, but not Section 13.3. all; apply Section 13.2 but not Section 13.3.
3. If no matching Link Tuples remain, then create a new matching 3. If no matching Link Tuples remain, then create a new matching
Link Tuple with: Link Tuple with:
o L_neighbor_iface_addr_list := empty; o L_neighbor_iface_addr_list := empty;
o L_HEARD_time := EXPIRED; o L_HEARD_time := EXPIRED;
o L_SYM_time := EXPIRED; o L_SYM_time := EXPIRED;
o L_quality := INITIAL_QUALITY; o L_quality := INITIAL_QUALITY;
o L_pending := INITIAL_PENDING; o L_pending := INITIAL_PENDING;
o L_lost := false; o L_lost := false;
skipping to change at page 43, line 26 skipping to change at page 43, line 43
4. The matching Link Tuple, existing or new, is then modified as 4. The matching Link Tuple, existing or new, is then modified as
follows: follows:
1. If the router finds any network address (henceforth receiving 1. If the router finds any network address (henceforth receiving
address) in the Receiving Address List in an Address Block in address) in the Receiving Address List in an Address Block in
the HELLO message, then the Link Tuple is modified as the HELLO message, then the Link Tuple is modified as
follows: follows:
1. If any receiving address in the HELLO message is 1. If any receiving address in the HELLO message is
associated with an Address Block TLV with Type = associated with an Address Block TLV with Type =
LINK_STATUS and with Value = HEARD or Value = SYMMETRIC LINK_STATUS and with Value = HEARD or Value = SYMMETRIC,
then: then:
o L_SYM_time := current time + validity time. o L_SYM_time := current time + validity time.
2. Otherwise if any receiving address in the HELLO message 2. Otherwise, if any receiving address in the HELLO message
is associated with an Address Block TLV with Type = is associated with an Address Block TLV with Type =
LINK_STATUS and Value = LOST then: LINK_STATUS and Value = LOST, then:
1. if L_SYM_time has not expired, then: 1. if L_SYM_time has not expired, then:
1. L_SYM_time := EXPIRED. 1. L_SYM_time := EXPIRED.
2. if L_status = HEARD, then: 2. if L_status = HEARD, then:
o L_time := current time + L_HOLD_TIME. o L_time := current time + L_HOLD_TIME.
2. L_neighbor_iface_addr_list := Sending Address List. 2. L_neighbor_iface_addr_list := Sending Address List.
3. L_HEARD_time := max(current time + validity time, 3. L_HEARD_time := max(current time + validity time,
L_SYM_time). L_SYM_time).
4. If L_status = PENDING, then: 4. If L_status = PENDING, then:
o L_time := max(L_time, L_HEARD_time). o L_time := max(L_time, L_HEARD_time).
5. Otherwise if L_status = HEARD or L_status = SYMMETRIC, then: 5. Otherwise, if L_status = HEARD or L_status = SYMMETRIC, then:
o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME). o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
12.6. Updating the 2-Hop Set 12.6. Updating the 2-Hop Set
On receiving a HELLO message a router MUST update its 2-Hop Set for On receiving a HELLO message, a router MUST update its 2-Hop Set for
the MANET interface on which the HELLO message was received: the MANET interface on which the HELLO message was received:
1. Remove all network addresses in the Removed Address List from the 1. Remove all network addresses in the Removed Address List from the
N2_neighbor_iface_addr_list of all 2-Hop Tuples. N2_neighbor_iface_addr_list of all 2-Hop Tuples.
2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending 2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending
Address List, has L_status = SYMMETRIC then: Address List, has L_status = SYMMETRIC, then:
1. For each network address (henceforth 2-hop address) in an 1. For each network address (henceforth 2-hop address) in an
Address Block of the HELLO message, where: Address Block of the HELLO message, where:
o 2-hop address is not contained in the Neighbor Address o a 2-hop address is not contained in the Neighbor Address
List; List;
o 2-hop address is not contained in any o a 2-hop address is not contained in any
I_local_iface_addr_list; AND I_local_iface_addr_list; AND
o 2-hop address != any IR_local_iface_addr o a 2-hop address != any IR_local_iface_addr
perform the following processing: perform the following processing:
1. If 2-hop address has an associated Address Block TLV 1. If the 2-hop address has an associated Address Block TLV
with: with:
o Type = LINK_STATUS and Value = SYMMETRIC; OR o Type = LINK_STATUS and Value = SYMMETRIC; OR
o Type = OTHER_NEIGHB and Value = SYMMETRIC, o Type = OTHER_NEIGHB and Value = SYMMETRIC,
then, if there is no 2-Hop Tuple such that: then, if there is no 2-Hop Tuple such that:
o N2_neighbor_iface_addr_list contains one or more o N2_neighbor_iface_addr_list contains one or more
network addresses in the Sending Address List; AND network addresses in the Sending Address List; AND
o N2_2hop_addr = 2-hop address. o N2_2hop_addr = 2-hop address,
then create a 2-Hop Neighbor Tuple with: then create a 2-Hop Neighbor Tuple with:
o N2_2hop_addr := 2-hop address. o N2_2hop_addr := 2-hop address.
This 2-Hop Tuple (existing or new) is then modified as This 2-Hop Tuple (existing or new) is then modified as
follows: follows:
o N2_neighbor_iface_addr_list := Sending Address List; o N2_neighbor_iface_addr_list := Sending Address List;
o N2_time := current time + validity time. o N2_time := current time + validity time.
2. Otherwise if 2-hop address has an Address Block TLV with: 2. Otherwise, if a 2-hop address has an Address Block TLV
with:
o Type = LINK_STATUS and Value = LOST or Value = HEARD; o Type = LINK_STATUS and Value = LOST or Value = HEARD;
OR OR
o Type = OTHER_NEIGHB and Value = LOST; o Type = OTHER_NEIGHB and Value = LOST;
then remove all 2-Hop Tuples with: then remove all 2-Hop Tuples with:
o N2_neighbor_iface_addr_list contains one or more o N2_neighbor_iface_addr_list containing one or more
network addresses in the Sending Address List; AND network addresses in the Sending Address List; AND
o N2_2hop_addr = 2-hop address. o N2_2hop_addr = 2-hop address.
13. Other Information Base Changes 13. Other Information Base Changes
The Interface and Neighbor Information Bases MUST be changed when The Interface and Neighbor Information Bases MUST be changed when
certain events occur. These events may result from HELLO message certain events occur. These events may result from HELLO message
processing, or may be otherwise generated (e.g., expiry of timers or processing or may be otherwise generated (e.g., expiry of timers or
link quality changes). link quality changes).
Events which cause changes in the Information Bases are: Events that cause changes in the Information Bases are:
o A Link Tuple's L_status changes to SYMMETRIC. In this case, the o A Link Tuple's L_status changes to SYMMETRIC. In this case, the
actions specified in Section 13.1 are performed. actions specified in Section 13.1 are performed.
o A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple o A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple
is removed. In this case, the actions specified in Section 13.2 is removed. In this case, the actions specified in Section 13.2
are performed. are performed.
o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed. o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed.
In this case, the actions specified in Section 13.3 are performed. In this case, the actions specified in Section 13.3 are performed.
skipping to change at page 46, line 9 skipping to change at page 46, line 27
If a Link Tuple is removed, or if L_status changes from SYMMETRIC and If a Link Tuple is removed, or if L_status changes from SYMMETRIC and
L_HEARD_time expires, then the actions specified in Section 13.2 MUST L_HEARD_time expires, then the actions specified in Section 13.2 MUST
be performed before the actions specified in Section 13.3 are be performed before the actions specified in Section 13.3 are
performed for that Link Tuple. performed for that Link Tuple.
A router MAY report updated information in response to any of these A router MAY report updated information in response to any of these
changes in HELLO message(s), subject to the constraints in changes in HELLO message(s), subject to the constraints in
Section 11. Section 11.
A router which transmits HELLO messages in response to such changes A router that transmits HELLO messages in response to such changes
SHOULD transmit a HELLO message: SHOULD transmit a HELLO message:
o On all MANET interfaces, if the Neighbor Set changes such as to o On all MANET interfaces, if the Neighbor Set changes such as to
indicate the change in symmetry of any 1-hop neighbors (including indicate the change in symmetry of any 1-hop neighbors (including
addition or removal of symmetric 1-hop neighbors). addition or removal of symmetric 1-hop neighbors).
o Otherwise, on all those MANET interfaces whose Link Set changes o Otherwise, on all those MANET interfaces whose Link Set changes
such as to indicate a change in L_status of any 1-hop neighbors such as to indicate a change in L_status of any 1-hop neighbors
(including the addition or removal of any 1-hop neighbors, other (including the addition or removal of any 1-hop neighbors, other
than those considered pending). than those considered pending).
13.1. Link Tuple Symmetric 13.1. Link Tuple Symmetric
If, for any Link Tuple which does not have L_status = SYMMETRIC: If, for any Link Tuple that does not have L_status = SYMMETRIC:
o L_status changes to SYMMETRIC; o L_status changes to SYMMETRIC;
then: then:
1. For the Neighbor Tuple whose N_neighbor_addr_list contains 1. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list, set: L_neighbor_iface_addr_list, set:
o N_symmetric := true. o N_symmetric := true.
2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is 2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is
contained in that N_neighbor_addr_list. contained in that N_neighbor_addr_list.
This includes any newly created Link Tuples whose status is This includes any newly created Link Tuples whose status is
immediately updated such that L_status = SYMMETRIC. (Note that in immediately updated such that L_status = SYMMETRIC. (Note that in
this specification all Link Tuples are created such that their this specification, all Link Tuples are created such that their
L_status is not SYMMETRIC, but a Link Tuple may be immediately L_status is not SYMMETRIC, but a Link Tuple may be immediately
updated by subsequent processing of the same HELLO message that updated by subsequent processing of the same HELLO message that
caused the creation of the Link Tuple such that the Link Tuple's caused the creation of the Link Tuple such that the Link Tuple's
L_status changes to SYMMETRIC.) L_status changes to SYMMETRIC.)
13.2. Link Tuple Not Symmetric 13.2. Link Tuple Not Symmetric
If for any Link Tuple with L_status = SYMMETRIC: If for any Link Tuple with L_status = SYMMETRIC:
o L_status changes to any other value; OR o L_status changes to any other value; OR
skipping to change at page 48, line 28 skipping to change at page 48, line 46
information from the link layer) and used only locally, i.e., is not information from the link layer) and used only locally, i.e., is not
included in signaling, and routers may interoperate whether they are included in signaling, and routers may interoperate whether they are
using the same, different, or no, link quality information. Link using the same, different, or no, link quality information. Link
quality information is specified as a normalized, dimensionless quality information is specified as a normalized, dimensionless
figure in the interval zero to one, inclusive, a higher value figure in the interval zero to one, inclusive, a higher value
indicating a better link quality. indicating a better link quality.
For deployments where no link quality is used, the considerations in For deployments where no link quality is used, the considerations in
Section 14.1 apply. For deployments where link quality is used, the Section 14.1 apply. For deployments where link quality is used, the
general principles of link quality usage are described in general principles of link quality usage are described in
Section 14.2. Section 14.3 and Section 14.4 detail link quality Section 14.2. Sections 14.3 and 14.4 detail link quality
functioning. functioning.
14.1. Deployment Without Link Quality 14.1. Deployment without Link Quality
In order for a router to not employ link quality, the router MUST In order for a router to not employ link quality, the router MUST
define: define:
o INITIAL_PENDING := false; o INITIAL_PENDING := false;
o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define
INITIAL_QUALITY := 1). INITIAL_QUALITY := 1).
14.2. Basic Principles of Link Quality 14.2. Basic Principles of Link Quality
To enable link quality usage, the L_quality value of a Link Tuple is To enable link quality usage, the L_quality value of a Link Tuple is
used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT, used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT,
to set the flags L_pending and L_lost of that Link Tuple. Based on to set the flags L_pending and L_lost of that Link Tuple. Based on
these flags, the link status to advertise for that Link Tuple is these flags, the link status to advertise for that Link Tuple is
determined as described in Section 7.1. determined as described in Section 7.1.
The use of two thresholds implements link hysteresis, whereby a link The use of two thresholds implements link hysteresis, whereby a link
which has HYST_REJECT <= L_quality < HYST_ACCEPT may be either that has HYST_REJECT <= L_quality < HYST_ACCEPT may be either
accepted or rejected (depending on which threshold it has most accepted or rejected (depending on which threshold it has most
recently crossed, or, if neither, on the value of parameter recently crossed, or, if neither, on the value of parameter
INITIAL_PENDING). With appropriate values of these parameters, this INITIAL_PENDING). With appropriate values of these parameters, this
prevents over-rapid changes of link status. prevents overly rapid changes of link status.
The basic principles of link quality usage are as follows: The basic principles of link quality usage are as follows:
o A router does not advertise a neighbor interface in any state o A router does not advertise a neighbor interface in any state
until L_quality is acceptable: until L_quality is acceptable:
o If INITIAL_PENDING = true, then the link is advertised when o If INITIAL_PENDING = true, then the link is advertised when
link L_quality >= HYST_ACCEPT. link L_quality >= HYST_ACCEPT.
o Otherwise the link is advertised when L_quality >= HYST_REJECT. o Otherwise, the link is advertised when L_quality >=
HYST_REJECT.
A link which is not yet advertised has L_pending = true. A link that is not yet advertised has L_pending = true.
o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false, o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false,
indicating that the link can be advertised. indicating that the link can be advertised.
o A link for which L_pending = false is advertised until its o A link for which L_pending = false is advertised until its
L_quality drops below HYST_REJECT. L_quality drops below HYST_REJECT.
o If a link has L_pending = false and L_quality < HYST_REJECT, the o If a link has L_pending = false and L_quality < HYST_REJECT, the
link is LOST and is advertised as such. This link is not link is LOST and is advertised as such. This link is not
reconsidered as a candidate HEARD or SYMMETRIC link until reconsidered as a candidate HEARD or SYMMETRIC link until
L_quality >= HYST_ACCEPT. L_quality >= HYST_ACCEPT.
o A link which has an acceptable quality may be advertised as HEARD, o A link that has an acceptable quality may be advertised as HEARD,
SYMMETRIC or LOST according to the exchange of HELLO messages. SYMMETRIC or LOST according to the exchange of HELLO messages.
In order that these principles can all hold, a router MUST NOT In order that these principles can all hold, a router MUST NOT
define: define:
o INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR o INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR
o INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT. o INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT.
14.3. When Link Quality Changes 14.3. When Link Quality Changes
If L_quality for a link changes, then the following actions MUST be If L_quality for a link changes, then the following actions MUST be
taken: taken:
1. If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is 1. If L_quality >= HYST_ACCEPT, then the corresponding Link Tuple is
modified by: modified by:
1. L_pending := false; 1. L_pending := false;
2. L_lost := false; 2. L_lost := false;
3. If L_status = HEARD or L_status = SYMMETRIC, then: 3. If L_status = HEARD or L_status = SYMMETRIC, then:
o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME). o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
2. If L_status != PENDING, and L_quality < HYST_REJECT then the 2. If L_status != PENDING, and L_quality < HYST_REJECT, then the
corresponding Link Tuple is modified by: corresponding Link Tuple is modified by:
1. If L_lost = false, then: 1. If L_lost = false, then:
o L_lost := true; o L_lost := true;
o L_time := min(L_time, current time + L_HOLD_TIME). o L_time := min(L_time, current time + L_HOLD_TIME).
As a result of this processing, the L_STATUS of a Link Tuple may As a result of this processing, the L_STATUS of a Link Tuple may
change. In this case, the processing actions corresponding to this change. In this case, the processing actions corresponding to this
skipping to change at page 50, line 34 skipping to change at page 51, line 10
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 the Link Tuple MUST be containing it, creates the Link Tuple, then the Link Tuple MUST be
created with the appropriately updated L_quality value, rather than created with the appropriately updated L_quality value, rather than
with L_quality := INITIAL_QUALITY.) with L_quality := INITIAL_QUALITY.)
14.4. Updating Link Quality 14.4. Updating Link Quality
A router MAY update link quality based on any information available A router MAY update link quality based on any information available
to it. Particular cases that MAY be used include: to it. Particular cases that MAY be used include:
o Information from the link layer, such as signal to noise ratio or o Information from the link layer, such as signal-to-noise ratio or
packet acknowledgment reception and loss information. packet acknowledgment reception and loss information.
o Receipt or loss of control packets. If control packets include a o Receipt or loss of control packets. If control packets include a
sequential packet sequence number, as defined in [RFC5444], then sequential packet sequence number, as defined in [RFC5444], then
link quality can be updated when a control packet is received, link quality can be updated when a control packet is received,
whether or not it contains a HELLO message. The link quality may whether or not it contains a HELLO message. The link quality may
then, for example, be based on whether the last N out of M control then, for example, be based on whether the last N out of M control
packets on the link were received, or may use a "leaky integrator" packets on the link were received, or may use a "leaky integrator"
tracking packet reception and loss. tracking packet reception and loss.
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 in HELLO between HELLO messages is known (such as by inclusion in HELLO
messages of a Message TLV with Type := INTERVAL_TIME, as defined messages of a Message TLV with Type := INTERVAL_TIME, as defined
in [RFC5497]) then the loss of HELLO messages can be determined in [RFC5497]), then the loss of HELLO messages can be determined
without the need to receive a later HELLO message. Note that if without the need to receive a later HELLO message. Note that if
this case is combined with the previous case then care must be this case is combined with the previous case, then care must be
taken to avoid "double counting" a lost HELLO message in a lost taken to avoid "double counting" a lost HELLO message in a lost
packet. 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 that MAY
be used when a single value of each is used. be used when a single value of each is used.
15.1. Message Interval Interface Parameters 15.1. Message Interval Interface Parameters
o HELLO_INTERVAL := 2 seconds o HELLO_INTERVAL := 2 seconds
o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4 o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4
o REFRESH_INTERVAL := HELLO_INTERVAL o REFRESH_INTERVAL := HELLO_INTERVAL
skipping to change at page 52, line 11 skipping to change at page 52, line 36
o HP_MAXJITTER := HELLO_INTERVAL/4 o HP_MAXJITTER := HELLO_INTERVAL/4
o HT_MAXJITTER := HP_MAXJITTER o HT_MAXJITTER := HP_MAXJITTER
15.6. Constants 15.6. Constants
o C := 1/1024 second o C := 1/1024 second
16. Usage with Other Protocols 16. Usage with Other Protocols
Other protocols, such as MANET routing protocols, which use Other protocols, such as MANET routing protocols, that use
neighborhood discovery, may need to interact with this protocol. neighborhood discovery, may need to interact with this protocol.
This protocol is designed to permit such interactions, in particular: This protocol is designed to permit such interactions, in particular:
o Through accessing, and possibly extending, the information in the o Through accessing, and possibly extending, the information in the
Local Information Base (Section 6), the Interface Information Base Local Information Base (Section 6), the Interface Information Base
(Section 7) and the Neighbor Information Base (Section 8). These (Section 7), and the Neighbor Information Base (Section 8). These
Information Bases record the interface configuration of the Information Bases record the interface configuration of the
router, as well as the local connectivity, up to two hops away. router, as well as the local connectivity, up to two hops away.
All updates to the elements specified in this document are subject All updates to the elements specified in this document are subject
to the constraints specified in Appendix B. to the constraints specified in Appendix B.
o Through accessing an outgoing HELLO message prior to it being o Through accessing an outgoing HELLO message prior to it being
transmitted over any MANET interface, and to add information transmitted over any MANET interface, and to add information
(e.g., , TLVs) as specified in [RFC5444]. This may, for example, (e.g., TLVs) as specified in [RFC5444]. This may, for example, be
be to allow a security protocol, as suggested in Section 17, to to allow a security protocol, as suggested in Section 17, to add a
add a TLV containing a cryptographic signature to the message, or TLV containing a cryptographic signature to the message, or be to
be to allow inserting relay selection information into a HELLO allow inserting relay selection information into a HELLO message
message by way of adding a TLV to an outgoing HELLO message prior by way of adding a TLV to an outgoing HELLO message prior to it
to it being transmitted. being transmitted.
o Through accessing an incoming HELLO message, and potentially o Through accessing an incoming HELLO message, and potentially
discarding it prior to processing by this protocol. This may, for discarding it prior to processing by this protocol. This may, for
example, allow a security protocol as suggested in Section 17 to example, allow a security protocol as suggested in Section 17 to
perform verification of HELLO message signatures and prevent perform verification of HELLO message signatures and prevent
processing of unverifiable HELLO messages by this protocol. processing of unverifiable HELLO messages by this protocol.
o Through accessing an incoming HELLO message after it has been o Through accessing an incoming HELLO message after it has been
completely processed by this protocol. This may, in particular, completely processed by this protocol. This may, in particular,
allow a protocol which has added information, such as relay allow a protocol that has added information, such as relay
selection information by way of inclusion of appropriate TLVs, selection information by way of inclusion of appropriate TLVs,
access to such information after appropriate updates have been access to such information after appropriate updates have been
recorded in the Information Bases in this protocol. recorded in the Information Bases in this protocol.
o Through requesting that a HELLO message be generated at a specific o Through requesting that a HELLO message be generated at a specific
time. In that case, HELLO message generation MUST still respect time. In that case, HELLO message generation MUST still respect
the constraints in Appendix B. the constraints in Appendix B.
Address objects in HELLO messages are processed according to their Address objects in HELLO messages are processed according to their
associated Address Block TLVs. All such address objects are to be associated Address Block TLVs. All such address objects are to be
processed according to this specification are associated with Address processed according to this specification are associated with Address
Block TLVs with Type of LOCAL_IF, OTHER_NEIGHB or LINK_STATUS (and Block TLVs with Type of LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS (and
type extension zero). Address objects not associated with an Address type extension zero). Address objects not associated with an Address
Block TLV of any of these Types are therefore not processed by the Block TLV of any of these Types are therefore not processed by the
protocol described in this specification. protocol described in this specification.
A protocol, such as a MANET routing protocol, interacting with this A protocol, such as a MANET routing protocol, interacting with this
protocol may need to add information to HELLO messages. This may be protocol may need to add information to HELLO messages. This may be
in form of associating TLVs (of Type other than LOCAL_IF, in the form of associating TLVs (of Type other than LOCAL_IF,
OTHER_NEIGHB or LINK_STATUS) to address objects already included by OTHER_NEIGHB, or LINK_STATUS) to address objects already included by
this specification. this specification.
A protocol, such as a MANET routing protocol, interacting with this A protocol, such as a MANET routing protocol, interacting with this
protocol may also add information to HELLO messages by inserting protocol may also add information to HELLO messages by inserting
address objects not already included by this specification. Such address objects not already included by this specification. Such
address objects are in the following called "inserted addresses". address objects are in the following called "inserted addresses".
These inserted addresses may added to Address Blocks already present These inserted addresses may added to Address Blocks already present
by virtue of the HELLO message generation in this specification, or by virtue of the HELLO message generation in this specification, or
may appear in new Address Blocks. In both cases, the following MUST may appear in new Address Blocks. In both cases, the following MUST
be observed: be observed:
o An inserted address MUST NOT be associated with an Address Block o An inserted address MUST NOT be associated with an Address Block
TLV of Type LOCAL_IF, OTHER_NEIGHB or LINK_STATUS. Consequently, TLV of Type LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS. Consequently,
the processing in this specification will ignore such address the processing in this specification will ignore such address
objects. objects.
o Each inserted address MUST be associated with an Address Block o Each inserted address MUST be associated with an Address Block
TLV, to be defined by the specification of the protocol inserting TLV, to be defined by the specification of the protocol inserting
the address object. In this way, all addresses present in a HELLO the address object. In this way, all addresses present in a HELLO
message are associated with an Address Block TLV defining their message are associated with an Address Block TLV defining their
semantics. semantics.
Informally speaking, Address Block TLVs define the semantics of Informally speaking, Address Block TLVs define the semantics of
skipping to change at page 54, line 5 skipping to change at page 54, line 29
with any Address Block TLV, MUST be silently ignored; the mere with any Address Block TLV, MUST be silently ignored; the mere
presence of an address object without an associated Address Block presence of an address object without an associated Address Block
TLV in a HELLO message MUST NOT cause any processing. TLV in a HELLO message MUST NOT cause any processing.
A protocol interacting with this protocol MAY also add an originator A protocol interacting with this protocol MAY also add an originator
address to HELLO messages, as specified in [RFC5444]. Such an address to HELLO messages, as specified in [RFC5444]. Such an
originator address MUST be unique to the originating router, it MAY originator address MUST be unique to the originating router, it MAY
be a local interface address of the router. It SHOULD be used be a local interface address of the router. It SHOULD be used
consistently, but SHOULD NOT be constrained in any other way. consistently, but SHOULD NOT be constrained in any other way.
Strict adherence to these points will enable unambiguous co-existence Strict adherence to these points will enable unambiguous coexistence
of future "extensions" to HELLO messages. of future "extensions" to HELLO messages.
In some cases, a protocol interacting with the protocol defined in In some cases, a protocol interacting with the protocol defined in
this specification, may need to recognize which HELLO messages to this specification, may need to recognize which HELLO messages to
process and which HELLO messages to discard. It is the process and which HELLO messages to discard. It is the
responsibility of that protocol to ensure that such messages are responsibility of that protocol to ensure that such messages are
suitably identifiable, e.g., through inclusion of a Message TLV or suitably identifiable, e.g., through inclusion of a Message TLV or
through recognizing an administrative configuration (such as address through recognizing an administrative configuration (such as address
ranges). Note that such a protocol interacting with this protocol ranges). Note that such a protocol interacting with this protocol
MAY specify such interaction by recognizing an additional reason for MAY specify such interaction by recognizing an additional reason for
discarding a message. As suggested in Section 17 this might, for discarding a message. As suggested in Section 17 this might, for
example, be a security protocol discarding a message which does not example, be a security protocol discarding a message that does not
carry a Message TLV containing a cryptographic signature. carry a Message TLV containing a cryptographic signature.
17. Security Considerations 17. Security Considerations
The objective of this protocol is to allow each router in the network The objective of this protocol is to allow each router in the network
to acquire information describing its 1-hop neighborhood and to acquire information describing its 1-hop neighborhood and
symmetric 2-hop neighborhood. This is acquired through HELLO message symmetric 2-hop neighborhood. This is acquired through HELLO message
exchange between neighboring routers. This information is made exchange between neighboring routers. This information is made
available through the Interface Information Bases and Neighbor available through the Interface Information Bases and Neighbor
Information Base, describing the router's 1-hop neighborhood and Information Base, describing the router's 1-hop neighborhood and
symmetric 2-hop neighborhood. symmetric 2-hop neighborhood.
Under normal circumstances, the information recorded in these Under normal circumstances, the information recorded in these
Information Bases is correct, i.e., corresponds to the actual network Information Bases is correct, i.e., corresponds to the actual network
topology, apart from any changes which have not (yet) been tracked by topology, apart from any changes that have not (yet) been tracked by
the HELLO message exchanges. the HELLO message exchanges.
If a router for some reason, whether malice or malfunction, transmits If a router for some reason, whether malice or malfunction, transmits
invalid HELLO messages, incorrect information may be recorded in invalid HELLO messages, incorrect information may be recorded in
other routers' Information Bases. This protocol specification does, other routers' Information Bases. This protocol specification does,
however, prevent inconsistent information from being included in the however, prevent inconsistent information from being included in the
Information Bases through the specified processing, which maintains Information Bases through the specified processing, which maintains
the constraints in Appendix B. The exact consequence of information the constraints in Appendix B. The exact consequence of information
inexactness depends on the use of these Information Bases, and SHOULD inexactness depends on the use of these Information Bases, and SHOULD
therefore be reflected in the specification of protocols which use therefore be reflected in the specification of protocols that use
information provided by this neighborhood discovery protocol. information provided by this neighborhood discovery protocol.
This section, therefore, firstly outlines the ways in which correctly This section, therefore, firstly outlines the ways in which correctly
formed, but still invalid, HELLO messages may appear, in formed, but still invalid, HELLO messages may appear, in
Section 17.1. Section 17.1.
Injection of invalid HELLO messages into a network may be prevented Injection of invalid HELLO messages into a network may be prevented
in a number of ways. If, for example, a network is deployed in a in a number of ways. If, for example, a network is deployed in a
site to which access is strictly regulated, so that physical access site to which access is strictly regulated, so that physical access
and proximity to the network is prevented, then further security and proximity to the network is prevented, then further security
mechanisms to protect against malicious routers injecting invalid mechanisms to protect against malicious routers injecting invalid
HELLO messages may not be required. Similarly, if the link layer HELLO messages may not be required. Similarly, if the link layer
over which the network is formed provides appropriate over which the network is formed provides appropriate
confidentiality, authentication, and integrity, then this may, for a confidentiality, authentication, and integrity, then this may, for a
given deployment, suffice to appropriately protect against disclosure given deployment, suffice to appropriately protect against disclosure
of information to an eavesdropper, and against a malicious router of information to an eavesdropper, and against a malicious router
injecting invalid HELLO messages. In the latter case the link layer injecting invalid HELLO messages. In the latter case, the link layer
would discard frames that fail the link layer checks, without would discard frames that fail the link-layer checks, without
attempting to deliver such frames to IP. Finally, certain usage may attempting to deliver such frames to IP. Finally, certain usage may
be of a nature where disruption of service is of no consequence, or be of a nature where disruption of service is of no consequence, or
at least not of sufficient consequence to warrant deployment of at least not of sufficient consequence to warrant deployment of
additional security mechanisms. additional security mechanisms.
A further point to stress, and which follows from the discussions A further point to stress, and which follows from the discussions
above is, that it will not be the case that "one size security fits above is, that it will not be the case that "one size security fits
all". Different deployments may have different requirements. For all". Different deployments may have different requirements. For
example in a deployment of a low value sensor network, authentication example, in a deployment of a low-value sensor network,
using a simple message authentication code and shared symmetric keys authentication using a simple message authentication code and shared
may suffice, while anything beyond that may require too many symmetric keys may suffice, while anything beyond that may require
computational resources to be viable. Conversely, in, for example, a too many computational resources to be viable. Conversely, in, for
community network, verifying not only that the originator of a HELLO example, a community network, verifying not only that the originator
message "has the right key" but also the precise identity of the of a HELLO message "has the right key" but also the precise identity
originator may be required to be proved, and computational resources of the originator may be required to be proved, and computational
may be available to make such a requirement feasible. resources may be available to make such a requirement feasible.
Section 17.2, therefore, does not specify a single "one-size-fits- Section 17.2, therefore, does not specify a single "one-size-fits-
all" mechanism, but rather details how the security suggestions in all" mechanism, but rather details how the security suggestions in
[RFC5444] are considered for applicability within the context of this [RFC5444] are considered for applicability within the context of this
protocol, and with the purpose of aiding deployment-specific security protocol, and with the purpose of aiding deployment-specific security
mechanisms to be developed. mechanisms to be developed.
17.1. Invalid HELLO Messages 17.1. Invalid HELLO Messages
A correctly formed, but still invalid, HELLO message may take any of A correctly formed, but still invalid, HELLO message may take any of
the following forms. Note that a present or absent address object in the following forms. Note that a present or absent address object in
an Address Block, does not by itself cause a problem. It is the an Address Block, does not by itself cause a problem. It is the
presence, absence, or incorrectness of associated LOCAL_IF, presence, absence, or incorrectness of associated LOCAL_IF,
LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems. LINK_STATUS, and OTHER_NEIGHB Address Block TLVs that causes
problems.
A router may provide false information about its own identity: A router may provide false information about its own identity:
o The HELLO message may contain address objects with an o The HELLO message may contain address objects with an
associated LOCAL_IF Address Block TLV which do not correspond associated LOCAL_IF Address Block TLV that do not correspond to
to addresses of interfaces of the router transmitting the HELLO addresses of interfaces of the router transmitting the HELLO
message. message.
o The HELLO message may omit network addresses, or their o The HELLO message may omit network addresses, or their
associated LOCAL_IF Address Block TLV, of interfaces of the associated LOCAL_IF Address Block TLV, of interfaces of the
router transmitting the HELLO message (other than the allowed router transmitting the HELLO message (other than the allowed
omission of the only local interface network address of the omission of the only local interface network address of the
MANET interface over which the HELLO message is transmitted, if MANET interface over which the HELLO message is transmitted, if
that is the case). that is the case).
o The HELLO message may incorrectly specify the LOCAL_IF Address o The HELLO message may incorrectly specify the LOCAL_IF Address
Block TLV Value associated with one or more local interface Block TLV Value associated with one or more local interface
network addresses, indicating incorrectly whether they are network addresses, indicating incorrectly whether they are
associated with the MANET interface over which the HELLO associated with the MANET interface over which the HELLO
message is transmitted. message is transmitted.
A router may provide false information about the identity of other A router may provide false information about the identity of other
routers: routers:
o A present LINK_STATUS Address Block TLV may, incorrectly, o A present LINK_STATUS Address Block TLV may, incorrectly,
identify a network address as being of a MANET interface which identify a network address as being of a MANET interface that
is or was heard on the MANET interface over which the HELLO is or was heard on the MANET interface over which the HELLO
message is transmitted. message is transmitted.
o A consistently absent LINK_STATUS Address Block TLV may, o A consistently absent LINK_STATUS Address Block TLV may,
incorrectly, fail to identify a network address as being of a incorrectly, fail to identify a network address as being of a
MANET interface which is or was heard on the MANET interface MANET interface that is or was heard on the MANET interface
over which the HELLO message is transmitted. over which the HELLO message is transmitted.
o A present OTHER_NEIGHB Address Block TLV may, incorrectly, o A present OTHER_NEIGHB Address Block TLV may, incorrectly,
identify a network address as being of a router which is or was identify a network address as being of a router that is or was
in the sending router's symmetric 1-hop neighborhood. in the sending router's symmetric 1-hop neighborhood.
o A consistently absent OTHER_NEIGHB Address Block TLV may, o A consistently absent OTHER_NEIGHB Address Block TLV may,
incorrectly, fail to identify a network address as being of a incorrectly, fail to identify a network address as being of a
router which is or was in the sending router's symmetric 1-hop router that is or was in the sending router's symmetric 1-hop
neighborhood. neighborhood.
o The Value of a LINK_STATUS Address Block TLV may incorrectly o The Value of a LINK_STATUS Address Block TLV may incorrectly
indicate the status (LOST, SYMMETRIC or HEARD) of the link from indicate the status (LOST, SYMMETRIC or HEARD) of the link from
a 1-hop neighbor. a 1-hop neighbor.
o The Value of an OTHER_NEIGHB Address Block TLV may incorrectly o The Value of an OTHER_NEIGHB Address Block TLV may incorrectly
indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop
neighbor. neighbor.
17.2. Authentication, Integrity and Confidentiality Suggestions 17.2. Authentication, Integrity, and Confidentiality Suggestions
The security suggestions in [RFC5444] regarding inclusion of a The security suggestions in [RFC5444] regarding inclusion of a
cryptographic signature in a Message TLV or a Packet TLV can be cryptographic signature in a Message TLV or a Packet TLV can be
applied to this protocol. Failure to verify either form of applied to this protocol. Failure to verify either form of
cryptographic signature should cause a HELLO message to be rejected cryptographic signature should cause a HELLO message to be rejected
without being processed. without being processed.
The following simplification of the suggestions for end-to-end The following simplification of the suggestions for end-to-end
authentication for integrity in [RFC5444] may be applied to HELLO authentication for integrity in [RFC5444] may be applied to HELLO
messages: messages:
skipping to change at page 57, line 20 skipping to change at page 57, line 45
are either omitted or will always have the values 0 and 1, are either omitted or will always have the values 0 and 1,
respectively, an end to end cryptographic signature can be respectively, an end to end cryptographic signature can be
calculated based on the entire HELLO message, including its calculated based on the entire HELLO message, including its
unmodified Message Header. unmodified Message Header.
The security mechanisms suggested in [RFC5444] with respect to The security mechanisms suggested in [RFC5444] with respect to
confidentiality can be directly applied to this protocol. confidentiality can be directly applied to this protocol.
18. IANA Considerations 18. IANA Considerations
This specification defines one Message Type, which must be allocated This specification defines one Message Type, which has been allocated
from the "Message Types" registry of [RFC5444], and three Address from the "Message Types" registry of [RFC5444], and three Address
Block TLV Types, which must be allocated from the "Address Block TLV Block TLV Types, which have been allocated from the "Address Block
Types" registry of [RFC5444]. TLV Types" registry of [RFC5444].
18.1. Expert Review: Evaluation Guidelines 18.1. Expert Review: Evaluation Guidelines
For the registries where an Expert Review is required, the designated For the registries where an Expert Review is required, the designated
expert SHOULD take the same general recommendations into expert SHOULD take the same general recommendations into
consideration as are specified by [RFC5444]. consideration as are specified by [RFC5444].
18.2. Message Types 18.2. Message Types
This specification defines one Message Type, to be allocated from the This specification defines one Message Type, which has been allocated
0-223 range of the "Message Types" namespace defined in [RFC5444], as from the 0-223 range of the "Message Types" namespace defined in
specified in Table 3. [RFC5444], as specified in Table 3.
+------+-------------------------+ +------+-------------------------+
| Type | Description | | Type | Description |
+------+-------------------------+ +------+-------------------------+
| TBD1 | HELLO : Local signaling | | 0 | HELLO : Local signaling |
+------+-------------------------+ +------+-------------------------+
Table 3: Message Type assignment Table 3: Message Type Assignment
18.3. Message-Type-Specific TLV Type Registries 18.3. Message-Type-Specific TLV Type Registries
IANA is requested to create a registry for Message-Type-specific IANA has created a registry for Message-Type-specific Message TLVs
Message TLVs for HELLO messages, in accordance with Section 6.2.1 of for HELLO messages, in accordance with Section 6.2.1 of [RFC5444],
[RFC5444], and with initial assignments and allocation policies as and with initial assignments and allocation policies as specified in
specified in Table 4. Table 4.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review | | 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
Table 4: HELLO Message-Type-specific Message TLV Types Table 4: HELLO Message-Type-specific Message TLV Types
IANA is requested to create a registry for Message-Type-specific IANA has created a registry for Message-Type-specific Address Block
Address Block TLVs for HELLO messages, in accordance with Section TLVs for HELLO messages, in accordance with Section 6.2.1 of
6.2.1 of [RFC5444], and with initial assignments and allocation [RFC5444], and with initial assignments and allocation policies as
policies as specified in Table 5. specified in Table 5.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review | | 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
Table 5: HELLO Message-Type-specific Address Block TLV Types Table 5: HELLO Message-Type-specific Address Block TLV Types
18.4. Address Block TLV Types 18.4. Address Block TLV Types
This specification defines three Address Block TLV Types, which must This specification defines three Address Block TLV Types, which have
be allocated from the "Address Block TLV Types" namespace defined in been allocated from the "Address Block TLV Types" namespace defined
[RFC5444]. IANA are requested to make allocations in the 0-127 range in [RFC5444]. IANA has made allocations in the 0-127 range for these
for these types. This will create three new type extension types. Three new type extension registries have been created, with
registries with assignments as specified in Table 6, Table 7 and assignments as specified in Tables 6, 7, and 8. Specifications of
Table 8. Specifications of these Address Block TLVs are in these Address Block TLVs are in Section 10.1.1, with Value Constants
Section 10.1.1, with Value Constants defined in Section 18.5. defined in Section 18.5.
+----------+------+-----------+------------------------+------------+ +----------+------+-----------+------------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | extension | | policy | | | | extension | | policy |
+----------+------+-----------+------------------------+------------+ +----------+------+-----------+------------------------+------------+
| LOCAL_IF | TBD2 | 0 | Specifies that the | | | LOCAL_IF | 2 | 0 | Specifies that the | |
| | | | network address is | | | | | | network address is | |
| | | | associated with this | | | | | | associated with this | |
| | | | local interface of the | | | | | | local interface of the | |
| | | | sending router | | | | | | sending router | |
| | | | (THIS_IF = 0) or | | | | | | (THIS_IF = 0) or | |
| | | | another local | | | | | | another local | |
| | | | interface of the | | | | | | interface of the | |
| | | | sending router | | | | | | sending router | |
| | | | (OTHER_IF = 1) | | | | | | (OTHER_IF = 1) | |
| LOCAL_IF | TBD2 | 1-255 | Unassigned | Expert | | LOCAL_IF | 2 | 1-255 | Unassigned | Expert |
| | | | | Review | | | | | | Review |
+----------+------+-----------+------------------------+------------+ +----------+------+-----------+------------------------+------------+
Table 6: Address Block TLV Type assignment: LOCAL_IF Table 6: Address Block TLV Type Assignment: LOCAL_IF
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | extension | | policy | | | | extension | | policy |
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
| LINK_STATUS | TBD3 | 0 | Specifies the | | | LINK_STATUS | 3 | 0 | Specifies the | |
| | | | status of the link | | | | | | status of the link | |
| | | | from the indicated | | | | | | from the indicated | |
| | | | network address | | | | | | network address | |
| | | | (LOST = 0, | | | | | | (LOST = 0, | |
| | | | SYMMETRIC = 1, or | | | | | | SYMMETRIC = 1, or | |
| | | | HEARD = 2) | | | | | | HEARD = 2) | |
| LINK_STATUS | TBD3 | 1-255 | Unassigned | Expert | | LINK_STATUS | 3 | 1-255 | Unassigned | Expert |
| | | | | Review | | | | | | Review |
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
Table 7: Address Block TLV Type assignment: LINK_STATUS Table 7: Address Block TLV Type Assignment: LINK_STATUS
+--------------+------+-----------+--------------------+------------+ +--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | extension | | policy | | | | extension | | policy |
+--------------+------+-----------+--------------------+------------+ +--------------+------+-----------+--------------------+------------+
| OTHER_NEIGHB | TBD4 | 0 | Specifies that the | | | OTHER_NEIGHB | 4 | 0 | Specifies the | |
| | | | network address is | | | | | | status of the | |
| | | | (SYMMETRIC = 1) or | | | | | | relationship with | |
| | | | recently was (LOST | | | | | | the router that | |
| | | | = 0) of an | | | | | | uses the indicated | |
| | | | interface of a | | | | | | network address on | |
| | | | symmetric 1-hop | | | | | | one or more | |
| | | | neighbor of the | | | | | | interfaces (LOST = | |
| | | | router | | | | | | 0, or SYMMETRIC = | |
| | | | transmitting the | | | | | | 1) | |
| | | | message | | | OTHER_NEIGHB | 4 | 1-255 | Unassigned | Expert |
| OTHER_NEIGHB | TBD4 | 1-255 | Unassigned | Expert |
| | | | | Review | | | | | | Review |
+--------------+------+-----------+--------------------+------------+ +--------------+------+-----------+--------------------+------------+
Table 8: Address Block TLV Type assignment: OTHER_NEIGHB Table 8: Address Block TLV Type Assignment: OTHER_NEIGHB
18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values 18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values
Note: This section does not require any IANA action, as the required Note: This information is recorded here for clarity and for use
information is included in the descriptions of the Address Block TLVs elsewhere in this specification. The information required by IANA is
allocated in Section 18.4. This information is recorded here for included in the descriptions of the Address Block TLVs allocated in
clarity, and for use elsewhere in this specification. Section 18.4.
The Values which the LOCAL_IF Address Block TLV can use are the The Values that the LOCAL_IF Address Block TLV can use are the
following: following:
o THIS_IF := 0 o THIS_IF := 0
o OTHER_IF := 1 o OTHER_IF := 1
The Values which the LINK_STATUS Address Block TLV can use are the The Values that the LINK_STATUS Address Block TLV can use are the
following: following:
o LOST := 0 o LOST := 0
o SYMMETRIC := 1 o SYMMETRIC := 1
o HEARD := 2 o HEARD := 2
The Values which the OTHER_NEIGHB Address Block TLV can use are the The Values that the OTHER_NEIGHB Address Block TLV can use are the
following: following:
o LOST := 0 o LOST := 0
o SYMMETRIC := 1 o SYMMETRIC := 1
19. Contributors 19. 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 from the OLSRv2 Design Team, 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 ATC, UK, o Christopher Dearlove, BAE Systems ATC, UK,
skipping to change at page 61, line 44 skipping to change at page 62, line 10
specification and its components (listed alphabetically): Alan Cullen specification and its components (listed alphabetically): Alan Cullen
(BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe
Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA), Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA),
and the entire IETF MANET working group. and the entire IETF MANET working group.
21. References 21. References
21.1. Normative References 21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", RFC 5148, February 2008. Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, February 2008.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
February 2009. Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing multi-value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
time in MANETs", RFC 5497, March 2009. Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
March 2009.
[RFC5498] Chakeres, I., "IANA Allocations for MANET Protocols", [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
RFC 5498, March 2009. (MANET) Protocols", RFC 5498, March 2009.
21.2. Informative References 21.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Corson, M. and J. Macker, "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 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Routing Protocol", RFC 3626, October 2003. Protocol (OLSR)", RFC 3626, October 2003.
[RFC5449] Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet, [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen,
"OSPF Multipoint Relay (MPR) Extension for Ad Hoc "OSPF Multipoint Relay (MPR) Extension for Ad Hoc
Networks", RFC 5449, February 2009. Networks", RFC 5449, February 2009.
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 neighbor network addresses may be included in the Address which 1-hop neighbor network addresses may be included in the Address
Blocks, and with which associated Address Block TLVs. These Address Blocks, and with which associated Address Block TLVs. These Address
Block TLVs may have Type = LINK_STATUS or Type = OTHER_NEIGHB, or Block TLVs may have Type = LINK_STATUS or Type = OTHER_NEIGHB, or
both. Address Block TLVs with Type = LINK_STATUS may have three both. Address Block TLVs with Type = LINK_STATUS may have three
possible Values (Value = HEARD, Value = SYMMETRIC or Value = LOST), possible Values (Value = HEARD, Value = SYMMETRIC, or Value = LOST),
and Address Block TLVs of TYPE = OTHER_NEIGHB may have two possible and Address Block TLVs of TYPE = OTHER_NEIGHB may have two possible
Values (Value = SYMMETRIC or Value = LOST). When both Address Block Values (Value = SYMMETRIC or Value = LOST). When both Address Block
TLVs are associated with the same network address only certain TLVs are associated with the same network address only certain
combinations of these Address Block TLV Values are necessary, and are combinations of these Address Block TLV Values are necessary, and are
the only combinations generated by the algorithm in Section 11. the only combinations generated by the algorithm in Section 11.
These combinations are indicated in Table 9. These combinations are indicated in Table 9.
Cells labeled with "Yes" indicate the possible combinations which are Cells labeled with "Yes" indicate the possible combinations that 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 that are correctly parsed and interpreted by the algorithm in
Section 12. The cell labeled with "No*" is actually inconsistent, it Section 12. The cell labeled with "No*" is actually inconsistent, it
is handled by ignoring the Address Block TLV with Type = is handled by ignoring the Address Block TLV with Type =
OTHER_NEIGHB, but SHOULD NOT be used. OTHER_NEIGHB, but SHOULD NOT be used.
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | Type = | Type = | Type = | | | Type = | Type = | Type = |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value = | Value = LOST | | | (absent) | Value = | Value = LOST |
| | | SYMMETRIC | | | | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
skipping to change at page 63, line 26 skipping to change at page 63, line 49
| Value = HEARD | | | | | Value = HEARD | | | |
| Type = | Yes | No | No* | | Type = | Yes | No | No* |
| LINK_STATUS, | | | | | LINK_STATUS, | | | |
| Value = | | | | | Value = | | | |
| SYMMETRIC | | | | | SYMMETRIC | | | |
| Type = | Yes | Yes | No | | Type = | Yes | Yes | No |
| LINK_STATUS, | | | | | LINK_STATUS, | | | |
| Value = LOST | | | | | Value = LOST | | | |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
Table 9: LINK_STATUS and OTHER_NEIGHB TLV combinations Table 9: LINK_STATUS and OTHER_NEIGHB TLV Combinations
Appendix B. Constraints Appendix B. Constraints
Any process which updates the Local Information Base or the Neighbor Any process that updates the Local Information Base or the Neighbor
Information Base MUST ensure that all constraints specified in this Information Base MUST ensure that all constraints specified in this
appendix are maintained. appendix are maintained.
In each Local Interface Tuple: In each Local Interface Tuple:
o I_local_iface_addr_list MUST NOT be empty. o I_local_iface_addr_list MUST NOT be empty.
o I_local_iface_addr_list MUST NOT contain any duplicated network o I_local_iface_addr_list MUST NOT contain any duplicated network
addresses. addresses.
o If I_manet = true, then I_local_iface_addr_list MUST NOT contain o If I_manet = true, then I_local_iface_addr_list MUST NOT contain
any network address which overlaps any network address in the any network address that overlaps any network address in the
I_local_iface_addr_list of any other Local Interface Tuple with I_local_iface_addr_list of any other Local Interface Tuple with
I_manet = true, unless it is known that the corresponding MANET I_manet = true, unless it is known that the corresponding MANET
interfaces will always communicate with separate sets of MANET interfaces will always communicate with separate sets of MANET
interfaces on other routers. interfaces on other routers.
In each Removed Interface Address Tuple: In each Removed Interface Address Tuple:
o IR_local_iface_addr MUST NOT contain any network address which is o IR_local_iface_addr MUST NOT contain any network address that is
in the I_local_iface_addr_list of any Local Interface Tuple. in the I_local_iface_addr_list of any Local Interface Tuple.
o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
other Removed Interface Address Tuple. other Removed Interface Address Tuple.
In each Link Tuple: In each Link Tuple:
o L_neighbor_iface_addr_list MUST NOT be empty. o L_neighbor_iface_addr_list MUST NOT be empty.
o L_neighbor_iface_addr_list MUST NOT contain any network address o L_neighbor_iface_addr_list MUST NOT contain any network address
which overlaps any network address in the I_local_iface_addr_list that overlaps any network address in the I_local_iface_addr_list
of any Local Interface Tuple or the IR_local_iface_addr of any of any Local Interface Tuple or the IR_local_iface_addr of any
Removed Interface Address Tuple. Removed Interface Address Tuple.
o L_neighbor_iface_addr_list MUST NOT contain any duplicated network o L_neighbor_iface_addr_list MUST NOT contain any duplicated network
addresses. addresses.
o L_neighbor_iface_addr_list MUST NOT contain any network address o L_neighbor_iface_addr_list MUST NOT contain any network address
which is in the L_neighbor_iface_addr_list of any other Link Tuple which is in the L_neighbor_iface_addr_list of any other Link Tuple
in the same Link Set. in the same Link Set.
o If L_HEARD_time has not expired then there MUST be a Neighbor o If L_HEARD_time has not expired, then there MUST be a Neighbor
Tuple whose N_neighbor_addr_list contains Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list. L_neighbor_iface_addr_list.
o L_HEARD_time MUST NOT be greater than L_time. o L_HEARD_time MUST NOT be greater than L_time.
o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are
expired). expired).
o L_quality MUST NOT be less than 0 or greater than 1. o L_quality MUST NOT be less than 0 or greater than 1.
o If L_quality >= HYST_ACCEPT then L_pending MUST be false. o If L_quality >= HYST_ACCEPT, then L_pending MUST be false.
o If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST. o If L_quality < HYST_REJECT, then L_status MUST be PENDING or LOST.
o L_pending MUST NOT be set to true if it is currently false. o L_pending MUST NOT be set to true if it is currently false.
In each Neighbor Tuple: In each Neighbor Tuple:
o N_neighbor_addr_list MUST NOT contain any network address which o N_neighbor_addr_list MUST NOT contain any network address that
overlaps any network address in the I_local_iface_addr_list of any overlaps any network address in the I_local_iface_addr_list of any
Local Interface Tuple or the IR_local_iface_addr of any Removed Local Interface Tuple or the IR_local_iface_addr of any Removed
Interface Address Tuple. Interface Address Tuple.
o N_neighbor_addr_list MUST NOT contain any duplicated network o N_neighbor_addr_list MUST NOT contain any duplicated network
addresses. addresses.
o N_neighbor_addr_list MUST NOT contain any network address which is o N_neighbor_addr_list MUST NOT contain any network address that is
in the N_neighbor_addr_list of any other Neighbor Tuple. in the N_neighbor_addr_list of any other Neighbor Tuple.
o If N_symmetric is = true, then there MUST be one or more Link o If N_symmetric is = true, then there MUST be one or more Link
Tuples with: Tuples with:
o L_neighbor_iface_addr_list contained in N_neighbor_addr_list; o L_neighbor_iface_addr_list contained in N_neighbor_addr_list;
AND AND
o L_status = SYMMETRIC. o L_status = SYMMETRIC.
skipping to change at page 66, line 16 skipping to change at page 66, line 42
HELLO messages are instances of [RFC5444] messages, and this protocol HELLO messages are instances of [RFC5444] messages, and this protocol
supports any combination of message header options and address supports any combination of message header options and address
encodings, enabled by [RFC5444] that convey the required information. encodings, enabled by [RFC5444] that convey the required information.
As a consequence, there is no single way to represent how all HELLO As a consequence, there is no single way to represent how all HELLO
messages look. This appendix illustrates two HELLO message with messages look. This appendix illustrates two HELLO message with
similar content, the exact values included are explained in the similar content, the exact values included are explained in the
following text. following text.
The HELLO message's four bit Message Flags (MF) field has value 7 The HELLO message's four bit Message Flags (MF) field has value 7
indicating that the message header contains hop limit, hop count and indicating that the message header contains hop limit, hop count, and
message sequence number fields. Its four bit Message Address Length message sequence number fields. Its four bit Message Address Length
(MAL) field has value 3 indicating addresses in the message have (MAL) field has value 3, indicating addresses in the message have a
length four octets, here being IPv4 addresses. The message is as length of four octets, here being IPv4 addresses. The message is as
transmitted, with a hop limit of 1 and a hop count of 0. The overall transmitted, with a hop limit of 1 and a hop count of 0. The overall
message length is 45 octets. message length is 45 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 Message TLV with Flags octet (MTLVF) INTERVAL_TIME. Each uses a Message TLV with Flags octet (MTLVF)
value 16, indicating that each has a Value, and each has a Value value 16, indicating that each has a Value, and each has a Value
Length of 1 octet. The Values included are time codes (as defined in Length of 1 octet. The Values included are time codes (as defined in
[RFC5497]) representing the parameters H_HOLD_TIME and [RFC5497]) representing the parameters H_HOLD_TIME and
HELLO_INTERVAL, respectively. HELLO_INTERVAL, respectively.
skipping to change at page 66, line 41 skipping to change at page 67, line 18
The message has a single Address Block containing 5 addresses. The The message has a single Address Block containing 5 addresses. The
Address Block Flags octet (ABF) value 128 indicates an address Head Address Block Flags octet (ABF) value 128 indicates an address Head
but no address Tail, and no address prefixes. The Head Length of 3 but no address Tail, and no address prefixes. The Head Length of 3
octets indicates address Mid sections of one octet each (Mid 0 to Mid octets indicates address Mid sections of one octet each (Mid 0 to Mid
4). 4).
The following Address Block TLV Block (content length 14 octets) The following Address Block TLV Block (content length 14 octets)
includes two Address Block TLVs. The first is a LOCAL_IF Address includes two Address Block TLVs. The first is a LOCAL_IF Address
Block TLV with Flags octet (ATLVF) value 80, which indicates that a Block TLV with Flags octet (ATLVF) value 80, which indicates that a
single address, with index 0 (i.e., the address Head:Mid 0) is the single address, with index 0 (i.e., the address Head:Mid 0) is the
single local interface address of this router (the 1 octet Value single local interface address of this router (the one octet Value
THIS_IF indicates that this address is of this interface). The THIS_IF indicates that this address is of this interface). The
second is a LINK_STATUS Address Block TLV with Flags octet (ATLVF) second is a LINK_STATUS Address Block TLV with Flags octet (ATLVF)
value 52, which specifies the link status values of all reported value 52, which specifies the link status values of all reported
neighbors in a single multivalue Address Block TLV that covers the neighbors in a single multivalue Address Block TLV that covers the
addresses with indexes 1 to 4, inclusive. The Address Block TLV addresses with indexes 1 to 4, inclusive. The Address Block TLV
Value Length of 4 octets indicates one octet per Value per address. Value Length of 4 octets indicates one octet per Value per address.
The last four addresses thus are of neighbors, each an with The last four addresses thus are of neighbors, each an with
associated link status: the first and second HEARD, the third associated link status: the first and second HEARD, the third
SYMMETRIC, and the fourth LOST. SYMMETRIC, and the fourth LOST.
skipping to change at page 68, line 43 skipping to change at page 69, line 43
originating router's 1-hop neighborhood. HELLO messages MUST NOT be originating router's 1-hop neighborhood. HELLO messages MUST NOT be
forwarded. forwarded.
A router MUST report its 1-hop neighborhood in HELLO messages on each A router MUST report its 1-hop neighborhood in HELLO messages on each
of its MANET interfaces at least each REFRESH_INTERVAL. This puts a of its MANET interfaces at least each REFRESH_INTERVAL. This puts a
lower bound on the control traffic generated by each router in the lower bound on the control traffic generated by each router in the
network employing this protocol. network employing this protocol.
A router MUST ensure that two successive HELLO messages sent on the A router 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 router in the network on the control traffic generated by each router in the network
employing this protocol. employing this protocol.
Appendix E. Interval and Timer Illustrations Appendix E. Interval and Timer Illustrations
This informative appendix illustrates the relationship between This informative appendix illustrates the relationship between
message timers and intervals. (The adjustments to this timing when message timers and intervals. (The adjustments to this timing when
using timing jitter, as defined in [RFC5148], are not shown.) using timing jitter, as defined in [RFC5148], are not shown.)
skipping to change at page 69, line 52 skipping to change at page 70, line 52
| | | |
HELLO (a, b, c, d) | HELLO (a, b, c, d) |
| |
HELLO (a, b, c, d) HELLO (a, b, c, d)
L_time: |-----------------------------| L_time: |-----------------------------|
|-------------------- ... |-------------------- ...
|---------- ... |---------- ...
| ... | ...
Figure 1: HELLO message generation: regular schedule Figure 1: HELLO Message Generation: Regular Schedule
Figure 2 illustrates a message schedule similar to Figure 1, where Figure 2 illustrates a message schedule similar to Figure 1, where
the router announces its own presence more frequently by sending the router announces its own presence more frequently by sending
additional HELLO messages. HELLO messages are still sent regularly, additional HELLO messages. HELLO messages are still sent regularly,
at a reduced interval defined by a new value of HELLO_INTERVAL. at a reduced interval defined by a new value of HELLO_INTERVAL.
However REFRESH_INTERVAL has not been reduced. Each 1-hop neighbor However, REFRESH_INTERVAL has not been reduced. Each 1-hop neighbor
network address included in these HELLO messages need be advertised network address included in these HELLO messages need be advertised
only once within each REFRESH_INTERVAL. Consequently the additional only once within each REFRESH_INTERVAL. Consequently, the additional
HELLO messages due to the reduced value of HELLO_INTERVAL may HELLO messages due to the reduced value of HELLO_INTERVAL may
therefore be empty. (This is not the only allowed distribution of therefore be empty. (This is not the only allowed distribution of
1-hop neighbor network addresses, they could, for example, be sent 1-hop neighbor network addresses, they could, for example, be sent
alternately a, b and c, d.) alternately a, b and c, d.)
H_HOLD_TIME: |-----------------------------| ... H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |---------|---------|---------| ... REFRESH_INTERVAL: |---------|---------|---------| ...
HELLO_INTERVAL: |----|----|----|----|----|----| ... HELLO_INTERVAL: |----|----|----|----|----|----| ...
skipping to change at page 70, line 49 skipping to change at page 71, line 49
HELLO (a, b, c, d) HELLO (a, b, c, d)
L_time: |-----------------------------| L_time: |-----------------------------|
|------------------------- ... |------------------------- ...
|-------------------- ... |-------------------- ...
|--------------- ... |--------------- ...
|---------- ... |---------- ...
|----- ... |----- ...
| ... | ...
Figure 2: HELLO message generation: regular schedule with different Figure 2: HELLO Message Generation: Regular Schedule with Different
HELLO_INTERVAL and REFRESH_INTERVAL HELLO_INTERVAL and REFRESH_INTERVAL
HELLO messages may also be sent in response to events. The minimal HELLO messages may also be sent in response to events. The minimal
interval between two successive HELLO message transmissions by a interval between two successive HELLO message transmissions by a
router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO
message emission rate. Hence, for each HELLO message transmission, a message emission rate. Hence, for each HELLO message transmission, a
router must wait at least HELLO_MIN_INTERVAL before the next HELLO router must wait at least HELLO_MIN_INTERVAL before the next HELLO
message transmission. Similarly, the maximum interval between two message transmission. Similarly, the maximum interval between two
successive HELLO message transmissions is HELLO_INTERVAL, setting a successive HELLO message transmissions is HELLO_INTERVAL, setting a
lower bound on the message transmission rate. Hence, for each HELLO lower bound on the message transmission rate. Hence, for each HELLO
skipping to change at page 72, line 37 skipping to change at page 73, line 37
HELLO (a, b, c, d, e, f) HELLO (a, b, c, d, e, f)
L_time: |-----------------------------| L_time: |-----------------------------|
|------------------------- ... |------------------------- ...
|-------------------- ... |-------------------- ...
|--------------- ... |--------------- ...
|---------- ... |---------- ...
|----- ... |----- ...
| ... | ...
Figure 3: HELLO message generation: regular schedule with responsive Figure 3: HELLO Message Generation: Regular Schedule with Responsive
messages Messages
Figure 4 shows the same example as Figure 3, but with an increased Figure 4 shows the same example as Figure 3, but with an increased
REFRESH_INTERVAL, and showing partial HELLO messages which include REFRESH_INTERVAL, and showing partial HELLO messages that include
only the necessary network addresses. only the necessary network addresses.
H_HOLD_TIME: |-----------------------------| ... H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |-------------------|---------- ... REFRESH_INTERVAL: |-------------------|---------- ...
|-------------------|----- ... |-------------------|----- ...
|-------------------| ... |-------------------| ...
|--------------- ... |--------------- ...
|---------- ... |---------- ...
|----- ... |----- ...
skipping to change at page 73, line 45 skipping to change at page 74, line 45
HELLO (c, f) HELLO (c, f)
L_time: |-----------------------------| L_time: |-----------------------------|
|------------------------- ... |------------------------- ...
|-------------------- ... |-------------------- ...
|--------------- ... |--------------- ...
|---------- ... |---------- ...
|----- ... |----- ...
| ... | ...
Figure 4: HELLO message generation: regular schedule with responsive Figure 4: HELLO Message Generation: Regular Schedule with Responsive
messages and different HELLO_INTERVAL and REFRESH_INTERVAL Messages and Different HELLO_INTERVAL and REFRESH_INTERVAL
Figure 5 summarizes the overall relationship between the intervals Figure 5 summarizes the overall relationship between the intervals
governing HELLO message transmissions by a router. governing HELLO message transmissions by a router.
H_HOLD_TIME: |------------------------------------| H_HOLD_TIME: |------------------------------------|
REFRESH_INTERVAL: |----------------| REFRESH_INTERVAL: |----------------|
HELLO_INTERVAL: |----------| HELLO_INTERVAL: |----------|
skipping to change at page 74, line 36 skipping to change at page 75, line 36
| | neighbor information must | | neighbor information must
| | be transmitted in HELLO | | be transmitted in HELLO
| | messages (one or more) | | messages (one or more)
| | | |
| Latest time for next HELLO message | Latest time for next HELLO message
| transmission | transmission
| |
Earliest time for next HELLO message Earliest time for next HELLO message
transmission transmission
Figure 5: HELLO message generation intervals Figure 5: HELLO Message Generation Intervals
E.2. HELLO Message Processing Timing E.2. HELLO Message Processing Timing
Figure 6 illustrates the Link Set timers when receiving a HELLO Figure 6 illustrates the Link Set timers when receiving a HELLO
message not including the network address of the receiving MANET message not including the network address of the receiving MANET
interface. interface.
VALIDITY_TIME: |--------------------------| VALIDITY_TIME: |--------------------------|
L_time: |--------------------------| L_time: |--------------------------|
L_HEARD_time: |--------------------------| L_HEARD_time: |--------------------------|
L_SYM_time: *-| (i.e., expired) L_SYM_time: *-| (i.e., expired)
Time: ---*--------------------------------> Time: ---*-------------------------------->
^ ^
| |
HELLO () received HELLO () received
Figure 6: HELLO message processing: network address not present Figure 6: HELLO Message Processing: Network Address Not Present
Figure 7 illustrates the Link Set timers when, following the received Figure 7 illustrates the Link Set timers when, following the received
HELLO message illustrated in Figure 6, a router receives a HELLO HELLO message illustrated in Figure 6, a router receives a HELLO
message including the network address (a) of the receiving interface message including the network address (a) of the receiving interface
with link status = HEARD (or SYM). with link status = HEARD (or SYM).
VALIDITY_TIME: |--------------------------| VALIDITY_TIME: |--------------------------|
|--------------------------| |--------------------------|
L_time: |--------------------------| L_time: |--------------------------|
skipping to change at page 75, line 50 skipping to change at page 76, line 50
L_SYM_time: *-| (i.e., expired) L_SYM_time: *-| (i.e., expired)
L_SYM_time: |--------------------------| L_SYM_time: |--------------------------|
Time: -*-----*---------------------------------> Time: -*-----*--------------------------------->
^ ^ ^ ^
| | | |
HELLO () received | HELLO () received |
| |
HELLO (a:HEARD) received HELLO (a:HEARD) received
Figure 7: HELLO message processing: network address present Figure 7: HELLO Message Processing: Network Address Present
Figure 8 illustrates the Link Set timers when, following the received Figure 8 illustrates the Link Set timers when, following the received
HELLO messages illustrated in Figure 7, a router receives a HELLO HELLO messages illustrated in Figure 7, a router receives a HELLO
message including the network address (a) of the receiving interface message including the network address (a) of the receiving interface
with link status = LOST. with link status = LOST.
VALIDITY_TIME: |--------------------------| VALIDITY_TIME: |--------------------------|
|--------------------------| |--------------------------|
|--------------------------| |--------------------------|
skipping to change at page 76, line 33 skipping to change at page 77, line 35
Time: -*-----*-----*---------------------------------> Time: -*-----*-----*--------------------------------->
^ ^ ^ ^ ^ ^
| | | | | |
HELLO () received | | HELLO () received | |
| | | |
HELLO (a:HEARD) received | HELLO (a:HEARD) received |
| |
HELLO (a:LOST) received HELLO (a:LOST) received
Figure 8: HELLO message processing: network address lost Figure 8: HELLO Message Processing: Network Address Lost
E.3. Other HELLO Message Timing E.3. Other HELLO Message Timing
There are three other timing parameters which are used by a router to There are three other timing parameters that are used by a router to
control HELLO message generation and processing. control HELLO message generation and processing.
Figure 9 illustrates the time, with duration L_HOLD_TIME, during Figure 9 illustrates the time, with duration L_HOLD_TIME, during
which the appropriate network addresses of a formerly, but no longer, which the appropriate network addresses of a formerly, but no longer,
symmetric 1-hop neighbor, as connected by this MANET interface, are symmetric 1-hop neighbor, as connected by this MANET interface, are
advertised as LOST using a LINK_STATUS TLV in HELLO messages on this advertised as LOST using a LINK_STATUS TLV in HELLO messages on this
MANET interface, thus allowing that 1-hop neighbor to update its Link MANET interface, thus allowing that 1-hop neighbor to update its Link
Set accordingly. Set accordingly.
L_HOLD_TIME: |----------------------------| L_HOLD_TIME: |----------------------------|
skipping to change at page 77, line 20 skipping to change at page 78, line 20
Formerly symmetric 1-hop neighbor | Formerly symmetric 1-hop neighbor |
ceases to be symmetric on this | ceases to be symmetric on this |
MANET interface | MANET interface |
| |
Time up to which network addresses of Time up to which network addresses of
this neighbor connected using this MANET this neighbor connected using this MANET
interface are advertised in HELLO interface are advertised in HELLO
messages on this MANET interface messages on this MANET interface
using a LINK_STATUS TLV, Value = LOST using a LINK_STATUS TLV, Value = LOST
Figure 9: HELLO message generation: advertisement of formerly Figure 9: HELLO Message Generation: Advertisement of Formerly
symmetric 1-hop neighbor on this MANET interface as lost Symmetric 1-Hop Neighbor on This MANET Interface as Lost
Figure 10 illustrates the time, with duration N_HOLD_TIME, during Figure 10 illustrates the time, with duration N_HOLD_TIME, during
which all network addresses of a formerly, but no longer, symmetric which all network addresses of a formerly, but no longer, symmetric
1-hop neighbor, are advertised as LOST in HELLO messages on all MANET 1-hop neighbor, are advertised as LOST in HELLO messages on all MANET
interfaces using an OTHER_NEIGHB TLV (if not also reported using a interfaces using an OTHER_NEIGHB TLV (if not also reported using a
LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to
update their 2-Hop Sets accordingly. update their 2-Hop Sets accordingly.
L_HOLD_TIME: |----------------------------| L_HOLD_TIME: |----------------------------|
skipping to change at page 77, line 44 skipping to change at page 78, line 44
| | | |
Formerly symmetric 1-hop neighbor | Formerly symmetric 1-hop neighbor |
ceases to be symmetric | ceases to be symmetric |
| |
Time up to which network addresses of Time up to which network addresses of
this neighbor are advertised in HELLO this neighbor are advertised in HELLO
messages on all MANET interfaces messages on all MANET interfaces
using an OTHER_NEIGHB TLV, using an OTHER_NEIGHB TLV,
Value = LOST Value = LOST
Figure 10: HELLO message generation: advertisement of formerly Figure 10: HELLO Message Generation: Advertisement of Formerly
symmetric 1-hop neighbor on any MANET interface as lost Symmetric 1-Hop Neighbor on Any MANET Interface as Lost
Figure 11 illustrates the time, with duration I_HOLD_TIME, during Figure 11 illustrates the time, with duration I_HOLD_TIME, during
which a formerly, but no longer, used local interface network address which a formerly, but no longer, used local interface network address
is excluded from being considered as a 2-hop neighbor network address is excluded from being considered as a 2-hop neighbor network address
(in order that a router is not recorded as its own 2-hop neighbor (in order that a router is not recorded as its own 2-hop neighbor
during that period). during that period).
I_HOLD_TIME: |----------------------------| I_HOLD_TIME: |----------------------------|
Time: ---*-----------------------------------> Time: ---*----------------------------------->
^ ^ ^ ^
| | | |
Formerly used local interface | Formerly used local interface |
network address ceases to be | network address ceases to be |
assigned to a local interface | assigned to a local interface |
| |
Time up to which this network Time up to which this network
address is excluded from being address is excluded from being
included in this router's 2-Hop Set included in this router's 2-Hop Set
Figure 11: Local interface removed network address Figure 11: Local Interface Removed Network Address
Appendix F. Topology Pictures Appendix F. Topology Pictures
This appendix illustrates various examples of physical topologies, as This appendix illustrates various examples of physical topologies, as
well as how these are logically recorded by NHDP from the point of well as how these are logically recorded by NHDP from the point of
view of the router A. This representation is a composite of view of the router A. This representation is a composite of
information which would be contained within A's various Information information that would be contained within A's various Information
Bases after NHDP has been running for sufficiently long time for the Bases after NHDP has been running for sufficiently long time for the
state to converge. state to converge.
Note that the examples given in this appendix are NOT exhaustive, but Note that the examples given in this appendix are NOT exhaustive, but
are selected to be illustrative of NHDP neighborhood representations are selected to be illustrative of NHDP neighborhood representations
of physical MANET topologies. of physical MANET topologies.
The example topologies presented contain 3 physical routers A, B and The example topologies presented contain 3 physical routers A, B, and
C. Each of these routers has one or two distinct interfaces, denoted C. Each of these routers has one or two distinct interfaces,
"top" and "bottom". Each interface has one or two addresses, and denoted "top" and "bottom". Each interface has one or two addresses,
symmetric connectivity between a pair of interfaces is illustrated by and symmetric connectivity between a pair of interfaces is
these being connected by a line. illustrated by these being connected by a line.
In all examples, the topology is described as it is recorded by NHDP In all examples, the topology is described as it is recorded by NHDP
in router A. in router A.
F.1. Example 1: Standard Single Interface Topology F.1. Example 1: Standard Single Interface Topology
In Figure 12, each router has a single interface, each with a single In Figure 12, each router has a single interface, each with a single
IP address. This is the simplest possible network, and the resulting IP address. This is the simplest possible network, and the resulting
representation is given to the right in Figure 12. representation is given to the right in Figure 12.
__________ __________ __________ __________
| | | | | |
{1} {2} {3} {1} {2} {3}
| | | {1}--------{2}--------{3} | | | {1}--------{2}--------{3}
+--'--+ +--'--+ +--'--+ +--'--+ +--'--+ +--'--+
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 12: Standard single interface topology (left), and Figure 12: Standard Single Interface Topology (Left), and
corresponding NHDP representation (right) Corresponding NHDP Representation (Right)
The Local Information Set in A contains a single Local Interface The Local Information Set in A contains a single Local Interface
Tuple which has an I_local_iface_addr_list of {1}. This value is Tuple that has an I_local_iface_addr_list of {1}. This value is
denoted with a {1} on the leftmost part of the resulting denoted with a {1} on the leftmost part of the resulting
representation. representation.
The Interface Information Base has only one Link Set, which The Interface Information Base has only one Link Set, which
represents the "top" interface of A, or {1}. This Link Set's only represents the "top" interface of A, or {1}. This Link Set's only
Link Tuple has an L_neighbor_iface_addr_list containing {2}; this Link Tuple has an L_neighbor_iface_addr_list containing {2}; this
corresponds to the dashed line from {1} to {2} to the right in corresponds to the dashed line from {1} to {2} to the right in
Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with
N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}; N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3};
this corresponds to the dashed line from {2} to {3} to the right in this corresponds to the dashed line from {2} to {3} to the right in
skipping to change at page 79, line 47 skipping to change at page 80, line 47
interface. interface.
__________ __________ __________ __________
| | | | | |
{1} {2,4} {3} {1} {2,4} {3}
| | | {1}-------{2,4}-------{3} | | | {1}-------{2,4}-------{3}
+--'--+ +--'--+ +--'--+ +--'--+ +--'--+ +--'--+
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 13: Single interfaces, with 1-hop neighbor B having two Figure 13: Single Interfaces, with 1-Hop Neighbor B Having Two
addresses (left), and corresponding NHDP representation (right) Addresses (Left), and Corresponding NHDP Representation (Right)
The content of the Interface Information Base is in this case The content of the Interface Information Base is in this case
identical to Example 1, except that L_neighbor_iface_addr_list is identical to Example 1, except that L_neighbor_iface_addr_list is
{2,4} and N2_neighbor_iface_addr_list is {2,4}. {2,4} and N2_neighbor_iface_addr_list is {2,4}.
F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor
In Figure 14, the network is identical to that in Example 1, except In Figure 14, the network is identical to that in Example 1, except
that the rightmost router, C, has two IP addresses on its interface. that the rightmost router, C, has two IP addresses on its interface.
__________ __________ __________ __________
| | | | | |
{1} {2} {3,4} +----{3} {1} {2} {3,4} +----{3}
| | | {1}--------{2}---+ | | | {1}--------{2}---+
+--'--+ +--'--+ +--'--+ +----{4} +--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 14: Single interfaces, with 2-hop neighbor C having two Figure 14: Single Interfaces, with 2-Hop Neighbor C Having Two
addresses (left), and corresponding NHDP representation (right) Addresses (Left), and Corresponding NHDP Representation (Right)
The content of the Interface Information Base is in this case The content of the Interface Information Base is in this case
identical to than in Example 1, except that the 2-Hop Set contains an identical to than in Example 1, except that the 2-Hop Set contains an
extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
N2_2hop_addr being {4}. These two 2-Hop Tuples are illustrated by N2_2hop_addr being {4}. These two 2-Hop Tuples are illustrated by
the two lines from {2} to {3} and (2) to {4}, respectively. the two lines from {2} to {3} and (2) to {4}, respectively.
F.4. Example 4: Dual Addressed Interfaces F.4. Example 4: Dual Addressed Interfaces
In Figure 15, the network is identical to that in Example 1, except In Figure 15, the network is identical to that in Example 1, except
skipping to change at page 80, line 47 skipping to change at page 81, line 50
{1,5} {2,6} {3,4} +----{3} {1,5} {2,6} {3,4} +----{3}
| | | {1,5}------{2,6}--+ | | | {1,5}------{2,6}--+
+--'--+ +--'--+ +--'--+ +----{4} +--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 15: Single interfaces, all routers having two addresses Figure 15: Single interfaces, all routers having two addresses
(left), and corresponding NHDP representation (right) (left), and corresponding NHDP representation (right)
The content of the Interface Information Base is in this case a The content of the Interface Information Base is in this case a
combination of the Interface Information Bases from Example 1, combination of the Interface Information Bases from Examples 1, 2,
Example 2 and Example 3. and 3.
F.5. Example 5: Dual Interface on 2-Hop Neighbor F.5. Example 5: Dual Interface on 2-Hop Neighbor
In Figure 16, all routers have a single IP address on each interface, In Figure 16, all routers have a single IP address on each interface,
and with the 2-hop neighbor having two interfaces. and with the 2-hop neighbor having two interfaces.
__________ __________ __________ __________
| | | | | |
{1} {2} {3} +----{3} {1} {2} {3} +----{3}
| | | {1}--------{2}---+ | | | {1}--------{2}---+
+--'--+ +--'--+ +-----+ +----{4} +--'--+ +--'--+ +-----+ +----{4}
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| |
{4} {4}
Figure 16: Single addresses, with 2-hop neighbor C having two Figure 16: Single Addresses, with 2-Hop Neighbor C Having Two
interfaces (left), and corresponding NHDP representation (right) Interfaces (Left), and Corresponding NHDP Representation (Right)
The Interface Information Base is identical to that in Example 3; The Interface Information Base is identical to that in Example 3;
NHDP does not distinguish topologically between this example and NHDP does not distinguish topologically between this example and
Example 3. Example 3.
F.6. Example 6: Dual interface on 1-Hop Neighbor F.6. Example 6: Dual interface on 1-Hop Neighbor
In Figure 17, all routers have a single IP address on each interface, In Figure 17, all routers have a single IP address on each interface,
and with the 1-hop neighbor having two interfaces. and with the 1-hop neighbor having two interfaces.
skipping to change at page 81, line 43 skipping to change at page 82, line 43
| | | |
{1} {2} +-----+ {1} {2} +-----+
| | {1}-------| {2} |------{4} | | {1}-------| {2} |------{4}
+--'--+ +--'--+ +-----+ | {5} | +--'--+ +--'--+ +-----+ | {5} |
| A | | B | | C | +-----+ | A | | B | | C | +-----+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | |
{5} {4} {5} {4}
|__________| |__________|
Figure 17: Single addresses, with 1-hop neighbor B having two Figure 17: Single Addresses, with 1-Hop Neighbor B Having Two
interfaces (left), and corresponding NHDP representation (right) Interfaces (Left), and Corresponding NHDP Representation (Right)
The Local Information Base is identical to that in Example 1. The Local Information Base is identical to that in Example 1.
The Interface Information Base has only one Link Set containing one The Interface Information Base has only one Link Set containing one
Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set
contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being
{2} and N2_2hop_addr being {4}. {2} and N2_2hop_addr being {4}.
The Neighbor Information Base contains a Neighbor Set containing a The Neighbor Information Base contains a Neighbor Set containing a
single Neighbor Tuple, which represents router B, with single Neighbor Tuple, which represents router B, with
N_neighbor_addr_list being {2,5}. This entry is represented on the N_neighbor_addr_list being {2,5}. This entry is represented on the
right of Figure 17 by boxing {2} with {5}. right of Figure 17 by boxing {2} with {5}.
Note that router A does not have information indicating which of Note that router A does not have information indicating which of
router B's interfaces is connected to router C. However, router A router B's interfaces is connected to router C. However, router A
knows that the address {4} (and thus router C) is reachable by using knows that the address {4} (and thus router C) is reachable by using
{2} as next hop. {2} as next hop.
F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors
In Figure 18, all routers have a single IP address on each interface, In Figure 18, all routers have a single IP address on each interface,
and both the 1-hop and 2-hop neighbors have two interfaces. and both the 1-hop and 2-hop neighbors have two interfaces.
Furthermore, there are now two physical links between routers B and Furthermore, there are now two physical links between routers B and
C, over distinct interface pairs. C, over distinct interface pairs.
skipping to change at page 82, line 35 skipping to change at page 83, line 33
| | | | | |
{1} {2} {3} +-----+ +----{3} {1} {2} {3} +-----+ +----{3}
| | | {1}-------| {2} |---+ | | | {1}-------| {2} |---+
+--'--+ +--'--+ +-----+ | {5} | +----{4} +--'--+ +--'--+ +-----+ | {5} | +----{4}
| A | | B | | C | +-----+ | A | | B | | C | +-----+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | |
{5} {4} {5} {4}
|__________| |__________|
Figure 18: Single addresses, with 1-hop and 2-hop neighbors B and C Figure 18: Single Addresses, with 1-Hop and 2-Hop Neighbors B and C
having two interfaces (left), and corresponding NHDP representation Having Two Interfaces (Left), and Corresponding NHDP Representation
(right) (Right)
The Local Information Base is identical to that in Example 1. The Local Information Base is identical to that in Example 1.
The Link Set is identical to that in Example 6, and the 2-Hop Set The Link Set is identical to that in Example 6, and the 2-Hop Set
contains, as in Example 5 (and similarly to Examples 3 and 4), two contains, as in Example 5 (and similarly to Examples 3 and 4), two
2-Hop Tuples representing the two links between routers B and C 2-Hop Tuples representing the two links between routers B and C.
Note that router A does not have information describing which of Note that router A does not have information describing which of
router B's interfaces is connected to which interfaces of router C, router B's interfaces is connected to which interfaces of router C,
or even that the interfaces with addresses {3} and {4} are interfaces or even that the interfaces with addresses {3} and {4} are interfaces
of the same router. However, router A knows that the addresses {3} of the same router. However, router A knows that the addresses {3}
and {4} (and thus router C) are reachable using {2} as next hop. and {4} (and thus router C) are reachable using {2} as next hop.
F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor
In Figure 19, all routers have a single IP address on each interface, In Figure 19, all routers have a single IP address on each interface,
skipping to change at page 83, line 23 skipping to change at page 84, line 23
| | | +-----+ | | | +-----+
{1} {2} {3} {1}-------| {2} |--------{3} {1} {2} {3} {1}-------| {2} |--------{3}
| | | | {5} | | | | | {5} |
+--'--+ +--'--+ +-----+ +-----+ +--'--+ +--'--+ +-----+ +-----+
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | {2} | | | | {2} |
{6} {5} {6}-------| {5} |--------{3} {6} {5} {6}-------| {5} |--------{3}
|__________| +-----+ |__________| +-----+
Figure 19: Single addresses, with both A and 1-hop neighbor B having Figure 19: Single Addresses, with Both A and 1-Hop Neighbor B Having
two interfaces (left), and corresponding NHDP representation (right) Two Interfaces (Left), and Corresponding NHDP Representation (Right)
The Local Information Set contains two Local Interface Tuples, with The Local Information Set contains two Local Interface Tuples, with
I_local_iface_addr_list of {1} and {6}, respectively. I_local_iface_addr_list of {1} and {6}, respectively.
Each Interface Information Base's Link Set contains one Link Tuple, Each Interface Information Base's Link Set contains one Link Tuple,
representing the links between {1} and {2}, and between {6} and {5}, representing the links between {1} and {2}, and between {6} and {5},
respectively. The 2-Hop Set for interface {1} contains a single respectively. The 2-Hop Set for interface {1} contains a single
2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and
N2_2hop_addr being {3}. The 2-Hop Set for interface {6} contains a N2_2hop_addr being {3}. The 2-Hop Set for interface {6} contains a
single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and
skipping to change at page 84, line 16 skipping to change at page 85, line 24
| | | +-----+ +----{3} | | | +-----+ +----{3}
{1} {2} {3} {1}-------| {2} |---+ {1} {2} {3} {1}-------| {2} |---+
| | | | {5} | +----{4} | | | | {5} | +----{4}
+--'--+ +--'--+ +-----+ +-----+ +--'--+ +--'--+ +-----+ +-----+
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | {2} | +----{3} | | | | {2} | +----{3}
{6} {5} {4} {6}-------| {5} |---+ {6} {5} {4} {6}-------| {5} |---+
|__________|__________| +-----+ +----{4} |__________|__________| +-----+ +----{4}
Figure 20: Single addresses, with all routers having two interfaces Figure 20: Single Addresses, with All Routers Having Two Interfaces
(left), and corresponding NHDP representation (right) (Left), and Corresponding NHDP Representation (Right)
The Local Information Set is identical to that in Example 8. The The Local Information Set is identical to that in Example 8. The
Interface Information Base for each interface in A is also identical Interface Information Base for each interface in A is also identical
to that in Example 8, except that an additional 2-Hop Tuple is to that in Example 8, except that an additional 2-Hop Tuple is
present in each 2-Hop Set, each representing the link between router present in each 2-Hop Set, each representing the link between router
B and the interface of router C with address {4}. B and the interface of router C with address {4}.
As in Example 7, router A does not have information describing which As in Example 7, router A does not have information describing which
of router B's interfaces is connected to which interface of C, or of router B's interfaces is connected to which interface of C, or
even that the interfaces with addresses {3} and {4} are interfaces of even that the interfaces with addresses {3} and {4} are interfaces of
skipping to change at page 85, line 21 skipping to change at page 86, line 29
| A | | B | | C | +--{12} | A | | B | | C | +--{12}
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | +--{9} | | | +--{9}
| | | +-----+ +------| | | | +-----+ +------|
| | | |{5,6}| | +--{10} | | | |{5,6}| | +--{10}
{3,4} {7,8} {11,12} {3,4}--|{7,8}|---+ {3,4} {7,8} {11,12} {3,4}--|{7,8}|---+
|__________|__________| +-----+ | +--{11} |__________|__________| +-----+ | +--{11}
+------| +------|
+--{12} +--{12}
Figure 21: Dual addresses, with all routers having two interfaces Figure 21: Dual Addresses, with All Routers Having Two Interfaces
(left) and corresponding NHDP representation (right) (Left) and Corresponding NHDP Representation (Right)
This example is the combination of all the preceding examples in this This example is the combination of all the preceding examples in this
appendix. The Local Information Set in A contains Local Information appendix. The Local Information Set in A contains Local Information
Tuples for each of its interfaces, and each Interface Information Tuples for each of its interfaces, and each Interface Information
Base contains in its Link Set a representation of links {1,2}-{5,6} Base contains in its Link Set a representation of links {1,2}-{5,6}
or {3,4}-{7,8}, respectively. The Neighbor Set (in the Neighbor or {3,4}-{7,8}, respectively. The Neighbor Set (in the Neighbor
Information Base) records the existence of router B and all of its Information Base) records the existence of router B and all of its
addresses on all its interfaces, i.e., {5,6,7,8}. addresses on all its interfaces, i.e., {5,6,7,8}.
As in Example 9, each interface address of router C is represented in As in Example 9, each interface address of router C is represented in
skipping to change at page 85, line 44 skipping to change at page 87, line 9
router B to each of these addresses. Router A does not have router B to each of these addresses. Router A does not have
information describing which of router B's interfaces is connected to information describing which of router B's interfaces is connected to
which interface of C, nor that the addresses {9}, {10}, {11}, and which interface of C, nor that the addresses {9}, {10}, {11}, and
{12} are addresses of the same router (or that some of these, such as {12} are addresses of the same router (or that some of these, such as
{9} and {10}, are addresses on the same interface of the router). {9} and {10}, are addresses on the same interface of the router).
F.11. Example 11: Single Addressed Dual Interface Locally F.11. Example 11: Single Addressed Dual Interface Locally
In Figure 22, all routers have a single interface, except for router In Figure 22, all routers have a single interface, except for router
A which has two. Each of A's two interfaces has a link with the A which has two. Each of A's two interfaces has a link with the
single interface of router B. All interfaces have a single address. single interface of router B. All interfaces have a single address.
__________ __________ __________ __________
| _____| | | _____| |
{1} | {2} {3} {1}--------{2}---------{3} {1} | {2} {3} {1}--------{2}---------{3}
| | | | | | | |
+--'--+ | +--'--+ +-----+ +--'--+ | +--'--+ +-----+
| A | | | B | | C | | A | | | B | | C |
+-----+ | +-----+ +-----+ +-----+ | +-----+ +-----+
| | | |
{6} | {6}--------{2}---------{3} {6} | {6}--------{2}---------{3}
|____| |____|
Figure 22: Single addresses, with A having two interfaces, both Figure 22: Single Addresses, with A Having Two Interfaces, Both
linked to the single interface of B (left), and corresponding NHDP Linked to the Single Interface of B (Left), and Corresponding NHDP
representation (right) Representation (Right)
This is similar to Example 8, except that the single address {2} also This is similar to Example 8, except that the single address {2} also
replaces the address {5}. In particular both Link Tuples (one in replaces the address {5}. In particular, both Link Tuples (one in
each Link Set, each in its corresponding Interface Information Base) each Link Set, each in its corresponding Interface Information Base)
have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the
Neighbor Information Base) contains a single Neighbor Tuple with Neighbor Information Base) contains a single Neighbor Tuple with
N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each
2-Hop Set, each in its corresponding Interface Information Base) have 2-Hop Set, each in its corresponding Interface Information Base) have
N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}. N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
skipping to change at page 87, line 27 skipping to change at line 3964
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
MANET Working Group
 End of changes. 290 change blocks. 
602 lines changed or deleted 628 lines changed or added

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