draft-ietf-manet-nhdp-08.txt   draft-ietf-manet-nhdp-09.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: September 10, 2009 BAE Systems ATC Expires: September 27, 2009 BAE Systems ATC
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
March 9, 2009 March 26, 2009
MANET Neighborhood Discovery Protocol (NHDP) MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-08 draft-ietf-manet-nhdp-09
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on September 27, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
This document describes a 1-hop and symmetric 2-hop neighborhood This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs). discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
3.1. Usage in Other Protocols . . . . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . 11
4.2.1. Local Information Base . . . . . . . . . . . . . . . . 12 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 11
4.2.2. Interface Information Bases . . . . . . . . . . . . . 13 4.2.2. Interface Information Bases . . . . . . . . . . . . . 12
4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 14 4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 13
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 13
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 15 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 14
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 15 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 14
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 16 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 15
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 15
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 17 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 16
5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 18 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 16
5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 18 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Information Validity Times . . . . . . . . . . . . . . 19 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 16
5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 20 5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 16
5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.2. Information Validity Times . . . . . . . . . . . . . . 18
5.2. Router Parameters . . . . . . . . . . . . . . . . . . . . 21 5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Information Validity Time . . . . . . . . . . . . . . 21 5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 21 5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 19
5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.1. Information Validity Time . . . . . . . . . . . . . . 19
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 23 5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 20
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 23 5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 23 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 21
7. Interface Information Base . . . . . . . . . . . . . . . . . . 24 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 21
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 22
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Interface Information Base . . . . . . . . . . . . . . . . . . 22
8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 26 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 26 8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 24
9. Local Information Base Changes . . . . . . . . . . . . . . . . 27 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 27 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 25
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 27 9. Local Information Base Changes . . . . . . . . . . . . . . . . 25
9.3. Adding an Address to an Interface . . . . . . . . . . . . 28 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 25
9.4. Removing an Address from an Interface . . . . . . . . . . 29 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 26
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 29 9.3. Adding an Address to an Interface . . . . . . . . . . . . 27
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 30 9.4. Removing an Address from an Interface . . . . . . . . . . 27
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 31 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 28
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 32 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 29
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 32 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 29
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 34 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 30
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 34 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 31
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 35 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 33
12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 35 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 33
12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 33
12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 37 12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 34
12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 38 12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 35
12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 39 12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 36
12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 40 12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 37
13. Other Information Base Changes . . . . . . . . . . . . . . . . 41 12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 37
13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 42 12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 39
13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 43 13. Other Information Base Changes . . . . . . . . . . . . . . . . 40
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 43 13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 41
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 44 13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 41
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 44 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 42
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 45 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 46 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 43
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 46 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 43
15. Proposed Values for Parameters and Constants . . . . . . . . . 47 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 44
15.1. Message Interval Interface Parameters . . . . . . . . . . 47 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 45
15.2. Information Validity Time Interface Parameters . . . . . . 47 15. Proposed Values for Parameters and Constants . . . . . . . . . 46
15.3. Information Validity Time Router Parameters . . . . . . . 47 15.1. Message Interval Interface Parameters . . . . . . . . . . 46
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 47 15.2. Information Validity Time Interface Parameters . . . . . . 46
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 48 15.3. Information Validity Time Router Parameters . . . . . . . 46
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 48 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 46
16. Security Considerations . . . . . . . . . . . . . . . . . . . 48 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 46
16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 47
16.2. Authentication, Integrity and Confidentiality 16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 47
Suggestions . . . . . . . . . . . . . . . . . . . . . . . 50 17. Security Considerations . . . . . . . . . . . . . . . . . . . 48
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 17.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48
17.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 50 17.2. Authentication, Integrity and Confidentiality
17.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 50 Suggestions . . . . . . . . . . . . . . . . . . . . . . . 49
17.3. Message-Type-specific TLV Type Registries . . . . . . . . 51 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
17.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 51 18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 50
17.5. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 52 18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 50
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 18.3. Message-Type-specific TLV Type Registries . . . . . . . . 50
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 51
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 18.5. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 52
20.1. Normative References . . . . . . . . . . . . . . . . . . . 54 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
20.2. Informative References . . . . . . . . . . . . . . . . . . 54 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
21.1. Normative References . . . . . . . . . . . . . . . . . . . 53
21.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 54 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 54
Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 55 Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 55
Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 58 Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 58
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 60 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
This document describes a neighborhood discovery protocol (NHDP) for This document describes a neighborhood discovery protocol (NHDP) for
a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a
exchange of HELLO messages in order that each router can determine local exchange of HELLO messages in order that each router can
the presence of, and connectivity to, its 1-hop and symmetric 2-hop determine the presence of, and connectivity to, its 1-hop and
neighbors. Messages are defined as instances of the specification symmetric 2-hop neighbors. Messages are defined according to the
[RFC5444]. specification [RFC5444].
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 may be used by other protocols, form of Information Bases. These are available for use by other
such as MANET routing protocols, which require information regarding protocols, such as MANET routing protocols, which require information
the local network connectivity. This protocol is designed to regarding the local network connectivity. This protocol is designed
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 ad hoc network presence of a dynamic network topology and wireless communication
interface 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 link local broadcast or multicast. Link layer other than support of local broadcast or multicast. Link layer
information may be used if available and applicable. information may be used if available and applicable.
This protocol is based on the neighborhood discovery process This protocol is based on the neighborhood discovery process
contained in the Optimized Link State Routing Protocol (OLSR) contained in the Optimized Link State Routing Protocol (OLSR)
[RFC3626]. [RFC3626].
1.1. Motivation 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 also over
more challenging network interfaces (e.g. wireless, lossy, broadcast more challenging communication channels (e.g., wireless, lossy,
interfaces with moderate and shared bandwidth, hidden and exposed broadcast channels with moderate and shared bandwidth, hidden and
terminals and interference from other network interfaces and the exposed 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). An approach, often taken by MANET routing network membership).
protocols, is to collect local topological information up to 2 hops,
in order to, for example, optimize their flooding performance within
the MANET.
Due to the properties of wireless transmissions, communication Due to the properties of wireless transmissions, communication
between two network interfaces on neighboring routers may not be between two neighboring routers may not be bidirectional; even if
bidirectional; even if router A is able to receive a packets from router A is able to receive packets from router B, the converse is
router B, the converse is not guaranteed to be true. Furthermore, not guaranteed to be true. Furthermore, because of the localized
because of the localized nature of wireless broadcast communication, nature of wireless broadcast communication, neighboring routers
neighboring routers within the same communications channel may have within the same communications channel may have different sets of
different sets of neighbors. If router A is able to exchange packets neighbors. That is, when using the same communication channel, even
with router B and router B is able to exchange packets with router C if router A is able to exchange packets with router B and router B is
on the same interface, this does not guarantee that router A and able to exchange packets with router C, then this does not guarantee
router C can exchange packets directly. that router A and router C can exchange packets directly.
Routers in a MANET may have multiple heterogeneous interfaces Each router in a MANET may use more than one communication channel.
participating in the same MANET routing protocol, each of which with
the characteristics described above. Between the same pair of
routers, more than one distinct communications channel (link) may
therefore exist, each with different properties.
For MANET routing protocols to correctly identify candidate links for In particular, between the same pair of routers, more than one
inclusion in a routing path, the existence and, in many cases, distinct communication channel may exist, each with different
bidirectionality of such distinct links between a router and its properties.
neighbors must be established and monitored.
For use by MANET routing protocols, as well as establishing a
router's neighbors, a router may also need to determine whether each
communication channel with that neighbor is bidirectional.
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 are physical environment in which the MANET is located. There is
typically no signals from lower layers which would enable an IP typically no information from lower layers which 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 are 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, continued provides continued tracking of neighborhood changes, link
bidirectionality tracking of links between neighbors, and local bidirectionality, and local topological information up to two hops.
topological information up to two hops. Combined, this allows a Combined, this allows a MANET routing protocol access to information
MANET routing protocol access to information describing link describing link establishment/disappearance, and provides the
establishment/disappearance, and provides the necessary topological necessary topological information for reduced relay set selection and
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" and "TLV", are to be interpreted as "Address Block", "TLV Block" and "TLV", are to be interpreted as
described there. described there.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Router - A MANET router which implements this neighborhood discovery Router - A MANET router which implements this neighborhood discovery
protocol. protocol.
Interface - A network device, configured and assigned one or more IP Interface - A network device, configured and assigned one or more
addresses. addresses.
Address - An IPv4 or IPv6 address, as recorded in the Information Address - An IPv4 or IPv6 address, as assigned to an interface. It
Bases specified by this protocol, and included in messages corresponds to an address as specified in [RFC5444], and may be
generated by this protocol, may be either an address or an address either an address or an address prefix. An address without a
prefix. The exception to this is addresses described as prefix length is considered to have a prefix length equal to its
originator addresses; these must be simple addresses without a length (in bits).
prefix length. Non-originator addresses can be represented as a
single address object in a message, as defined by [RFC5444]. An Origionator address - An address identifying a router, as specified
address so represented is considered to have a prefix length equal in [RFC5444]; it is a simple address without a prefix length.
to its length (in bits) when considered as an address object, and
a similar convention is used in the Information Bases specified by
this protocol. Two addresses (address objects) are considered
equal only if their prefix lengths are also equal.
MANET interface - An interface participating in a MANET and using MANET interface - An interface participating in a MANET and using
this neighborhood discovery protocol. A router may have several this neighborhood discovery protocol. A router may have several
MANET interfaces. 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 traffic from the interface of a router Y if the latter can receive traffic from the
former. former.
Link - A pair of MANET interfaces from two different routers, where Link - A link between two MANET interfaces exists if either can be
at least one interface is heard by the other. heard by the other.
Symmetric link - A link where both MANET interfaces are heard by the Symmetric link - A symmetric link between two MANET interfaces
other. 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 - A router X is a 1-hop neighbor of a router Y if a
MANET interface of router X is heard by a MANET interface of MANET interface of router X is heard by a MANET interface of
router Y. router Y.
Symmetric 1-hop neighbor - A router X is a symmetric 1-hop neighbor Symmetric 1-hop neighbor - A router X is a symmetric 1-hop neighbor
of a router Y if a symmetric link exists between a MANET interface of a router Y if a symmetric link exists between a MANET interface
on router X and a MANET interface on router Y. 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
router X is a 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 - A router X is a symmetric 2-hop neighbor
of a router Y if router X is a symmetric 1-hop neighbor of a of a router Y if router X is a symmetric 1-hop neighbor of a
symmetric 1-hop neighbor of router Y, but is not router Y itself. 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 - The 1-hop neighborhood of a router X is the set
of the 1-hop neighbors of router X. of the 1-hop neighbors of router X.
Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a
router X is the set of the symmetric 1-hop neighbors of router X. 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
of the 2-hop 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 - The symmetric 2-hop neighborhood of a
router X is the set of the symmetric 2-hop neighbors of router X. router X is the set of the symmetric 2-hop neighbors of router X.
(This may include routers in the 1-hop neighborhood, or even in (This may include routers in the 1-hop neighborhood, or even in
the symmetric 1-hop neighborhood, of router X.) the symmetric 1-hop neighborhood, of router X.)
Constant - A constant is a numerical value which MUST be the same Constant - A numerical value which MUST be the same for all MANET
for all MANET interfaces of all routers in the MANET, at all interfaces of all routers in the MANET, at all times.
times.
Interface parameter - An interface parameter is a boolean or Interface parameter - A boolean or numerical value, specified
numerical value, specified separately for each MANET interface of separately for each MANET interface of each router. A router MAY
each router. A router MAY change interface parameter values at change interface parameter values at any time, subject to some
any time, subject to some constraints. constraints.
Router parameter - A router parameter is a boolean or numerical Router parameter - A boolean or numerical value, specified for each
value, specified for each router, and not specific to an router, and not specific to an interface. A router MAY change
interface. A router MAY change router parameter values at any router parameter values at any time, subject to some constraints.
time, subject to some constraints.
Information Base - A collection of information maintained by this
protocol, and which is to be made available to MANET routing
protocols. An 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, is an unordered list
membership operator, returning true if the unordered list X membership operator, returning true if the unordered list X
includes the element y, and returning false otherwise. includes the element y, and returning 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, is an unordered list inclusion
operator, returning true if the unordered list X contains all operator, returning true if the unordered list X contains all
elements y which are contained in Y, and returning false elements y which are contained in Y, and returning false
skipping to change at page 8, line 51 skipping to change at page 9, line 6
a := b is an assignment operator, whereby the left side (a) is a := b is an assignment operator, whereby the left side (a) is
assigned the value of the right side (b). a and b may be values, assigned the value of the right side (b). a and b may be values,
addresses, or unordered lists (they must be of the same 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 is a comparison operator, returning true if the value of the
left side (c) is equal to the value of the right side (d). c and d left side (c) is equal to the value of the right side (d). c and d
may be values, addresses, or unordered lists (they must be of the may be values, addresses, or unordered lists (they must be of the
same type). If c and d are unordered lists, then they are same type). If c and d are unordered lists, then they are
considered to be equal if they contain the same set of elements, considered to be equal if they contain the same set of elements,
regardless of the order in which they are recorded in either list regardless of the order in which they are recorded in either list
(in which case c is contains d, and d contains c). (in which case c is contains d, and d contains c). If c and d are
addresses, they are considered equal only if their prefix lengths
are also equal.
e != f is a comparison operator, returning true where (e = f) would e != f is a comparison operator, returning true where (e = f) would
have returned false, and returning false where (e = f) would have have returned false, and returning false where (e = f) would have
returned true. returned true.
3. Applicability Statement 3. Applicability Statement
This protocol: This protocol:
o Provides each router with local topology information up to two
hops away.
o Makes this local topology information a available to MANET routing
protocols in Information Bases, which are defined in this
specification.
o May interact with other protocols, such as MANET routing
protocols, see Section 3.1.
o Is applicable to networks, especially wireless networks, in which o Is applicable to networks, especially wireless networks, in which
unknown neighbors (i.e. other routers with which direct link layer unknown neighbors can be reached by local broadcast or multicast
communication can be established) can be reached by local packets.
broadcast or multicast 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
which messages may be lost, such as due to collisions in wireless which messages may be lost, such as due to collisions in wireless
networks. networks.
o Supports routers that each have one or more participating MANET o Supports routers that each have one or more participating MANET
interfaces. The set of a router's interfaces may change over interfaces. The set of a router's interfaces may change over
time. Each interface may have one or more interface addresses, time. Each interface may have one or more interface addresses,
and these may also be dynamically changing. and these may also be dynamically changing.
o Can use the link local multicast address "LL-MANET-Routers", and o Provides each router with current local topology information up to
either the "manet" UDP port or the "manet" IP protocol number, all two hops away, and makes this local topology information available
as specified in [manet-iana]. to MANET routing protocols in Information Bases.
o Uses the packet and message formats specified in [RFC5444]. Such o Uses the packet and message formats specified in [RFC5444]. This
packets may contain messages specified by this protocol as well as includes the definition of a HELLO Message Type, used for
other protocols. signalling local topology information.
o Specifies signaling using HELLO messages. The necessary contents o May interact with, and be extended by, other protocols, such as
of these messages are defined in this specification, and may be MANET routing protocols, see Section 16.
extended using the TLV mechanisms described in [RFC5444].
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.
3.1. Usage in Other Protocols
Other protocols which use neighborhood discovery MAY need to interact
with this protocol. This protocol is designed to permit such
interactions, in particular:
o Through accessing, and possibly extending, the information in the
Local Information Base (Section 6), the Interface Information Base
(Section 7) and the Neighbor Information Base (Section 8). These
Information Bases record the interface configuration of the
router, as well as the local connectivity, up to two hops away.
All updates to the elements specified in this document are subject
to the constraints specified in Appendix B.
o Through accessing an outgoing HELLO message prior to it being
transmitted over any MANET interface, and to add information (e.g.
TLVs) as specified in [RFC5444]. This may, for example, be to
allow a security protocol, as suggested in Section 16, to add a
TLV containing a cryptographic signature to the message, or be to
allow inserting relay selection information into a HELLO message
by way of adding a TLV to an outgoing HELLO message prior to it
being transmitted.
o Through accessing an incoming HELLO message, and potentially
discard it prior to processing by this protocol. This may, for
example, allow a security protocol, as suggested in Section 16, to
perform verification of HELLO message signatures and prevent
processing of unverifiable HELLO messages by this protocol.
o Through accessing an incoming HELLO message after it has been
completely processed by this protocol. This may, in particular,
allow a protocol which has added information, such as relay
selection information by way of inclusion of appropriate TLVs,
access to such information after appropriate updates has been
recorded in the Information Bases in this protocol.
o Through requesting that a HELLO message be generated at a specific
time. In that case, HELLO message generation MUST still respect
the constraints in Appendix B.
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 other routers which can be heard, and those with which o To identify 1-hop neighbors and symmetric 1-hop neighbors of this
bidirectional links can be established (symmetric 1-hop router.
neighbors).
o To agree on the status of such links with the corresponding
symmetric 1-hop neighbor.
o To find the interface addresses of the router's symmetric 2-hop o To find the interface addresses of the router's symmetric 2-hop
neighbors. neighbors.
o To record this information in Information Bases that can be used o To record this information in Information Bases that can be used
by other protocols, of which this neighborhood discovery protocol by other protocols, of which this neighborhood discovery protocol
may be a part. may be a part.
These objectives are achieved using local (one hop) signaling that: These objectives are achieved using local (1-hop) signaling that:
o Advertises the presence of a router and its interfaces. o Advertises the presence of a router and its interface addresses.
o Discovers links from neighboring routers. o Discovers links from neighboring routers.
o Performs bidirectionality checks on the discovered links. o Performs bidirectionality checks on the discovered links.
o Advertises discovered links, and whether each is symmetric, to its o Advertises discovered links, and whether each is symmetric, to its
1-hop neighbors, and hence discovers symmetric 2-hop neighbors. 1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
This specification defines, in turn: This specification defines, in turn:
o Parameters and constants used by the protocol. Parameters used by o Parameters and constants used by the protocol. Parameters used by
this protocol may be, where appropriate, specific to a specific this protocol may be, where appropriate, specific to a given MANET
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
the Information Bases. the Information Bases.
o The updating of the Information Bases according to received HELLO o The updating of the Information Bases according to received HELLO
messages and other events. messages and other events.
o The response to other events, such as the expiration of
information in the Information Bases.
4.1. Routers and Interfaces 4.1. Routers and Interfaces
In order for a router to participate in a MANET, it MUST have at In order for a router to participate in a MANET, it MUST have at
least one, and possibly more, MANET interfaces. Each MANET least one, and possibly more, MANET interfaces. Each MANET
interface: interface:
o Is characterized by a set of interface parameters, defining the o Is configured with one or more addresses. These addresses MUST be
behavior of this MANET interface. Each MANET interface MAY be unique within the router's 2-hop neighborhood.
individually parameterized.
o Has a set of interface parameters, defining the behavior of this
MANET interface. Each MANET interface MAY be individually
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 which
can be reached through such links. can be reached through such links.
o Generates and processes HELLO messages, according to the interface o Generates and processes HELLO messages.
parameters for that MANET interface.
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 addresses of the o A Local Information Base, containing the 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.
o A Neighbor Information Base, recording information regarding o A Neighbor Information Base, recording information regarding
current and recently lost 1-hop neighbors of this router. current and recently lost 1-hop neighbors of this router.
skipping to change at page 12, line 43 skipping to change at page 11, line 51
Each router maintains the Information Bases described in the Each router maintains the Information Bases described in the
following sections. These are used for describing the protocol in following sections. These are used for describing the protocol in
this document. An implementation of this protocol MAY maintain this this document. An implementation of this protocol MAY maintain this
information in the indicated form, or in any other organization which information in the indicated form, or in any other organization which
offers access to this information. In particular note that it is not offers access to this information. In particular note that it is not
necessary to remove Tuples from Sets at the exact time indicated, necessary to remove Tuples from Sets at the exact time indicated,
only to behave as if the Tuples were removed at that time. only to behave as if the Tuples were removed at that time.
4.2.1. Local Information Base 4.2.1. Local Information Base
Each router maintains a Local Information Base, which contains: Each router maintains a Local Information Base, which contains the
router's local configuration information, specifically:
o The Local Interface Set, which consists of Local Interface Tuples, o The Local Interface Set, which consists of Local Interface Tuples,
each of which records the addresses of an interface (MANET or non- each of which represents an interface (MANET or non-MANET) of the
MANET) of the router. router.
o The Removed Interface Address Set, which consists of Removed o The Removed Interface Address Set, which consists of Removed
Interface Address Tuples, each of which records a recently used Interface Address Tuples, each of which records a recently used
address of an interface (MANET or non-MANET) of the router. address of an interface (MANET or non-MANET) of the router.
The Local Interface Set is used for generating HELLO messages, The Local Interface Set is used for generating HELLO messages,
specifically for determining which interface addresses are to be specifically for determining which interface addresses are to be
included and identified through inclusion of an appropriate TLV as included and identified as local interfaces. The Removed Interface
being a "local interface" of the router at which the HELLO message is Address Set is used to avoid incorrectly recording a formerly used
generated. The Removed Interface Address Set is used to allow a address as a symmetric 2-hop neighbor's address.
router to detect if a neighbor is advertising a formerly used
address, and to exclude this from inclusion in the Interface
Information Bases described below.
The Local Information Base is used for generating signaling, but is The Local Information Base is used for generating signaling, but is
not itself updated by signaling specified in this document. Updates not itself updated by signaling specified in this document. Updates
to the Local Information Base are due to changes of the router to the Local Information Base are due to changes of the router
configuration, and may be allowed to trigger signaling. configuration, and may be allowed to trigger signaling.
4.2.2. Interface Information Bases 4.2.2. Interface Information Bases
Each router maintains, for each of its MANET interfaces, an Interface Each router maintains, for each of its MANET interfaces, an Interface
Information Base, which contains: Information Base, which contains 1-hop neighborhood and symmetric
2-hop neighborhood information collected from this MANET interface,
specifically:
o A Link Set, which records information about current and recently o A Link Set, which records information about current and recently
lost links between this interface and MANET interfaces of 1-hop lost links between this MANET interface and MANET interfaces of
neighbors. The Link Set consists of Link Tuples, each of which 1-hop neighbors. The Link Set consists of Link Tuples, each of
contains information about a single link. Recently lost links are which contains information about a single link. Link quality
recorded so that they can be advertised in HELLO messages, information (see Section 14), when used, is recorded in Link
accelerating their removal from relevant 1-hop neighbors' Link Tuples.
Sets. Link quality information (see Section 14), if used and
available, is recorded in Link Tuples and may indicate that links
are treated as lost.
o A 2-Hop Set, which records the existence of bidirectional 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 an interface address of a of 2-Hop Tuples, each of which records an address of a symmetric
symmetric 2-hop neighbor, and all interface addresses of the 2-hop neighbor, and all addresses of the corresponding symmetric
corresponding symmetric 1-hop neighbor. The 2-Hop Set is updated 1-hop neighbor.
by the signaling of this protocol, but is not itself reported in
that signaling.
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 detect bidirectionality (if router A allow other routers to identify symmetric links and to populate the
advertises router B as heard in a HELLO message and router B receives 2-Hop Set. Recently lost links are recorded in the Link Set for a
that HELLO message, then router B knows that bidirectional MANET interface so that they can be advertised in HELLO messages,
communication is possible between routers A and B), and to populate accelerating their removal from relevant 1-hop neighbors' Link Sets.
the 2-Hop Set (if router C receives a HELLO message from router B
advertising a bidirectional link to address A, then router C knows
that address A is reachable in two hops via router B).
The Link Set for a MANET interface is itself updated upon receipt of
a HELLO message, including to record link bidirectionality as
indicated above.
The 2-Hop Set for a MANET interface is updated as indicated above, The Link Set for a MANET interface is itself updated on receiving a
and is not itself used in generating HELLO messages. HELLO message, including recording symmetric links 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.
4.2.3. Neighbor Information Base 4.2.3. Neighbor Information Base
Each router maintains a Neighbor Information Base, which contains: Each router maintains a Neighbor Information Base, which contains
collected information about current and recently lost 1-hop
neighbors, specifically:
o The Neighbor Set, which records 1-hop neighbors, each of which o The Neighbor Set consists of Neighbor Tuples, each of which
must be currently heard, although this may be over a link with records all addresses of a single 1-hop neighbor. Neighbor Tuples
insufficient link quality. The Neighbor Set consists of Neighbor are maintained as long as there are corresponding Link Tuples.
Tuples, each of which records all interface addresses of a single
1-hop neighbor. Neighbor Tuples are maintained as long as there
are corresponding current Link Tuples.
o The Lost Neighbor Set, which records recently lost symmetric 1-hop o The Lost Neighbor Set consists of Lost Neighbor Tuples, each of
neighbors. The Lost Neighbor Set consists of Lost Neighbor which records an address of a recently lost symmetric 1-hop
Tuples, each of which records an interface address of such a neighbor.
neighbor. These are recorded so that they can be advertised in
HELLO messages, accelerating their removal from other routers'
2-Hop Sets.
The Neighbor Set is used for recording which interface addresses of The Neighbor Set associates all addresses of each 1-hop neighbor.
neighbor routers are associated to the same router, and for including These addresses may be included when generating a HELLO message, so
this when generating HELLO messages such that 2-Hop sets in other that other symmetric 1-hop neighbors can record this information in a
neighboring routers may record this information. The Neighbor Set 2-Hop Set. The Neighbor Set can be updated on receiving a HELLO
can itself be updated on receipt of a HELLO message. message.
The Lost Neighbor Set is used for generating HELLO messages. The Lost Neighbor Set is used to determine which addresses are to be
Specifically, the Lost Neighbor Set is used for determining which included in a HELLO message as being lost (of a recently symmetric
addresses are to be included in a HELLO and identified through 1-hop neighbor). The Lost Neighbor Set can itself be updated on
inclusion of an appropriate TLV as being "lost", i.e. formerly, but receiving a HELLO message.
no longer, recorded as a symmetric neighbor. The Lost Neighbor Set
can itself be updated on receipt of 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
Interface Information Bases and the Neighbor Information Base. If Interface Information Bases and the Neighbor Information Base. If
information from the link layer, or any other source, is available information from the link layer, or any other source, is available
and appropriate, it may also be used to update these Information and appropriate, it may also be used to update these Information
Bases. Such updates are subject to the constraints specified in Bases. Such updates are subject to the constraints specified in
Appendix B. Appendix B.
Signaling consists of a single type of message, known as a HELLO Signaling consists of a single type of message, known as a HELLO
message. Each router generates HELLO messages on each of its MANET message. Each router generates HELLO messages on each of its MANET
interfaces. HELLO messages are generated independently on each MANET interfaces. HELLO messages are generated independently on each MANET
interface of a MANET router; the content of a given HELLO message interface of a MANET router; the content of a given HELLO message
depends on the interface for which it has been generated. depends on the MANET interface for which it has been generated.
Each HELLO message identifies the MANET interface for which it is Each HELLO message identifies the MANET interface for which it is
generated and over which it is transmitted. This allows its generated and transmitted; this allows recipients to identify that
recipients to identify from which MANET interface this HELLO message MANET interface. Each HELLO message also reports the other
has been received. Each HELLO message also reports the other interfaces (MANET and non-MANET) of the router; this allows
interfaces (MANET and non-MANET) of the router, which allows recipients to associate a set of addresses with a single 1-hop
recipients to associate a set of interface addresses with a single neighbor. Each HELLO message also includes 1-hop neighbor
neighbor. Finally, each HELLO message also includes information from information from the Information Bases; this allows detection of
the Link Set of the Interface Information Base of the MANET local symmetric links, and symmetric 2-hop neighbors.
interface, and from the Neighbor Information Base. This serves to
allow detection of bidirectional communication between two MANET
routers and over a pair of MANET interfaces, as well as to determine
symmetric 2-hop neighborhood information.
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, broken, 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, as described Jittering of HELLO message generation and transmission, as described
in Section 11.2, SHOULD be used if appropriate. in Section 11.2, SHOULD be used if appropriate.
HELLO messages MAY be scheduled independently for each MANET HELLO messages MAY be scheduled independently for each MANET
interface, or, interface parameters permitting, using the same interface, or, interface parameters permitting, using the same
schedule for all MANET interfaces of a router. schedule for all MANET interfaces of a router.
4.3.2. HELLO Message Content 4.3.2. HELLO Message Content
Each HELLO message sent on a MANET interface need not contain all of The content of a HELLO message MUST satisfy the following:
the information appropriate to that MANET interface, however:
o A HELLO message MUST contain all of the addresses in the Local o A HELLO message MUST contain all of the addresses in the Local
Interface Set of the router to which the MANET interface belongs. Interface Set of the router to which the MANET interface belongs.
o For each MANET interface, within every time interval of length o For each MANET interface, within every time interval equal to the
equal to the corresponding parameter REFRESH_INTERVAL, the HELLO corresponding REFRESH_INTERVAL, the HELLO messages sent MUST
messages sent MUST collectively include: collectively include all of the relevant information in the
corresponding Link Set and the Neighbor Information Base. Note
* All of the relevant information in the Link Set of the that when determining whether to include information in a HELLO
Interface Information Base of that MANET interface. message, the sender MUST consider all times up to the latest time
when it may send its next HELLO message on this MANET interface.
* All of the relevant information in the Neighbor Information
Base of that router.
This applies to otherwise purely responsive routers as well as to
proactive routers. In either case it means that all information
appropriate to that MANET interface will have always been
transmitted, in one or more HELLO messages, since the time
REFRESH_INTERVAL ago. Note that this rule applies at all times,
not just to times at which HELLO messages are sent. In
considering whether to include information in a HELLO message, the
sender MUST consider all times up to when it may send its next
HELLO message on that MANET interface.
o A HELLO message MUST include a VALIDITY_TIME Message TLV, as o A HELLO message MUST include exactly one VALIDITY_TIME Message
specified in [timetlv], that indicates the length of time for TLV, as specified in [RFC5497], that indicates the length of time
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 an o A periodically generated HELLO message SHOULD include exactly one
INTERVAL_TIME Message TLV, as specified in [timetlv], that INTERVAL_TIME Message TLV, as specified in [RFC5497], that
indicates the current value of HELLO_INTERVAL for that MANET indicates the current value of HELLO_INTERVAL for that MANET
interface, i.e. the period within which a further HELLO message is interface, i.e. the period within which a further HELLO message is
guaranteed to be sent on that MANET interface. guaranteed to be sent on that MANET interface.
o Additional information may be added by a protocol using this
protocol using the TLV mechanisms described in [RFC5444]. For
example, if multipoint relays (MPRs) are to be calculated
similarly to as in [RFC3626] and signaled to neighbors, then this
information may be added to HELLO messages using an Address Block
TLV.
4.3.3. HELLO Message Processing 4.3.3. HELLO Message Processing
All HELLO messages received by a router are used to update: HELLO messages received by a router are used to update the Interface
Information Base for the MANET interface on which that HELLO message
o The Interface Information Base for the MANET interface on which is received and the Neighbor Information Base. Specifically:
that HELLO message is received.
o The Neighbor Information Base.
Specifically:
o The router ensures that there is a single Neighbor Tuple o The router ensures that there is a single Neighbor Tuple
corresponding to the originator of that HELLO message. corresponding to the originator of that HELLO message.
o If a Link Tuple corresponding to the link on which that HELLO o The router ensures that there is a Link Tuple, with appropriate
message was received exists, then the duration for which that Link status (heard or symmetric) and advertised duration, corresponding
Tuple is kept is extended, otherwise such a Link Tuple is created. to the link between the MANET interfaces on which that HELLO
If the HELLO message indicates that the receiving MANET interface message was sent and received. One or more Lost Neighbor Tuples
has been heard, then the link is considered symmetric, or the may be created if the HELLO message reports that the link was
duration for which that Link Tuple is kept as symmetric is lost.
extended. If the HELLO message indicates that the receiving MANET
interface is lost, then the link is no longer considered
symmetric. In this case one or more Lost Neighbor Tuples may be
created.
o If the link on which the HELLO message is received is symmetric, o If the link between the MANET interfaces on which the HELLO
then any symmetrically advertised neighbor addresses in the HELLO message was sent and received is symmetric, then the router
message are added to the 2-Hop Set for the receiving interface, or ensures that there are the appropriate 2-Hop Tuples, with
if already present, the duration for which the corresponding 2-Hop advertised duration.
Tuples are kept are extended.
In all cases the processing takes into account unexpected and The processing defined in this specification handles any unexpected
erroneous information in the HELLO message, maintaining the and erroneous information in a HELLO message, maintaining the
constraints 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 with each link in the Link Set. A MANET quality value is recorded in each Link Tuple. A MANET router
router considers links for which an insufficient link quality is considers links for which an insufficient link quality is recorded as
recorded to be lost. Modifying the recorded link quality of a link lost. Modifying the recorded link quality in a Link Tuple is
in the Link Set is OPTIONAL. If link quality is not to be modified OPTIONAL. If link quality is not to be modified it MUST be set to
it MUST be set to indicate an always usable quality link. Link indicate an always usable quality link.
quality information is only used locally, it is not used in
signaling, and routers may interoperate whether they are using the Link quality information is only used locally and is not used in
same, different, or no, link quality information. Link quality signaling. Routers may interoperate whether they are using the same,
information is thus not equivalent to a link metric. different, or no, link quality information. Link quality information
is thus not equivalent to a link metric.
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. Interface Parameters 5.1. Protocol and Port Numbers
This protocol specifies HELLO messages, which are included in packets
as defined by [RFC5444]. These packets may be sent either using the
"manet" protocol number or the "manet" well-known UDP port number, as
specified in [RFC5498].
5.2. Multicast Address
This protocol specifies HELLO messages, which are included in packets
as defined by [RFC5444]. These packets may be locally transmitted
using the link local multicast address "LL-MANET-Routers", as
specified in [RFC5498].
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
skipping to change at page 18, line 27 skipping to change at page 16, line 46
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.1.1. Message Intervals 5.3.1. Message Intervals
The following interface parameters regulate HELLO message
transmissions over a given MANET interface.
HELLO messages serve two principal functions: HELLO messages serve two principal functions:
o To advertise this router's interface addresses to its 1-hop o To advertise this router's interface addresses to its 1-hop
neighbors. The frequency of these advertisements is regulated by neighbors. The frequency of these advertisements is regulated by
the interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL. the interface parameters HELLO_INTERVAL and 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.
skipping to change at page 19, line 13 skipping to change at page 17, line 25
specified in [RFC5148]. specified in [RFC5148].
HELLO_MIN_INTERVAL - is the minimum interval between transmission of HELLO_MIN_INTERVAL - is the minimum interval between transmission of
two successive HELLO messages, on this MANET interface. (This two successive HELLO messages, on this MANET interface. (This
minimum interval MAY be modified by jitter, as defined in minimum interval MAY be modified by jitter, as defined in
[RFC5148].) [RFC5148].)
REFRESH_INTERVAL - is the maximum interval between advertisements in REFRESH_INTERVAL - is the maximum interval between advertisements in
a HELLO message of each 1-hop neighbor address and its status. In a HELLO message of each 1-hop neighbor address and its status. In
all intervals of length REFRESH_INTERVAL, a router MUST include all intervals of length REFRESH_INTERVAL, a router MUST include
all 1-hop neighbor information that it is specified as sending in each 1-hop neighbor address and its status in at least one HELLO
at least one HELLO message on this MANET interface. message on this MANET interface. (This may be in the same or in
different HELLO messages.)
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o HELLO_INTERVAL > 0 o HELLO_INTERVAL > 0
o HELLO_MIN_INTERVAL >= 0 o HELLO_MIN_INTERVAL >= 0
o HELLO_INTERVAL >= HELLO_MIN_INTERVAL o HELLO_INTERVAL >= HELLO_MIN_INTERVAL
o REFRESH_INTERVAL >= HELLO_INTERVAL o REFRESH_INTERVAL >= HELLO_INTERVAL
o If INTERVAL_TIME Message TLVs as defined in [timetlv] are included o If an INTERVAL_TIME Message TLV as defined in [RFC5497] is
in HELLO messages, then HELLO_INTERVAL MUST be representable as included in a HELLO messages, then HELLO_INTERVAL MUST be
described in [timetlv]. 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.
For a router to employ this protocol in a purely responsive manner on For a router to employ this protocol in a purely responsive manner on
a MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be a MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be
set to a value such that a responsive HELLO message is always set to a value such that a responsive HELLO message is always
expected in a shorter period than this value. expected in a shorter 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 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 interfaces on which responsive HELLO HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO
messages may be sent. messages may be sent.
5.1.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 - is the period of advertisement, on this MANET
interface, of former 1-hop neighbor addresses as lost in HELLO interface, of former 1-hop neighbor addresses as lost in HELLO
messages, allowing recipients of these HELLO messages to messages, allowing recipients of these HELLO messages to
accelerate removal of this information from their Link Sets. accelerate removal of this information from their Link Sets.
L_HOLD_TIME MAY be set to zero, if accelerated information removal L_HOLD_TIME MAY be set to zero, if accelerated information removal
is not required. is not required.
skipping to change at page 20, line 24 skipping to change at page 18, line 33
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 [timetlv]. o H_HOLD_TIME MUST be representable as described in [RFC5497].
5.1.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 - is the link quality threshold at or above which a link
becomes usable, if it was not already so. becomes usable, if it was not already so.
HYST_REJECT - is the link quality threshold below which a link HYST_REJECT - is the link quality threshold below which a link
becomes unusable, if it was not already so. becomes unusable, if it was not already so.
skipping to change at page 21, line 9 skipping to change at page 19, line 18
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.1.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 are
as follows: as follows:
HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for periodically generated HELLO messages on this MANET interface. for periodically generated HELLO messages on this MANET interface.
HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for externally triggered HELLO messages on this MANET interface. 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.2. 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.2.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 - is used as the period during which former 1-hop
neighbor addresses are advertised as lost in HELLO messages, neighbor addresses are advertised as lost in HELLO messages,
allowing recipients of these HELLO messages to accelerate removal allowing recipients of these HELLO messages to accelerate removal
of this information from their 2-Hop Sets. N_HOLD_TIME MAY be set of this information from their 2-Hop Sets. N_HOLD_TIME MAY be set
to zero, if accelerated information removal is not required. to zero, if accelerated information removal is not required.
I_HOLD_TIME - is the period for which a recently used local I_HOLD_TIME - is the period for which a recently used local
interface address is recorded. interface address is recorded.
The following constraints applies to these router parameters: The following constraints applies 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.3. Parameter Change Constraints 5.5. Parameter Change Constraints
This section presents guidelines, applicable if protocol parameters If protocol parameters are changed dynamically, the constraints in
are changed dynamically. this section apply.
HELLO_INTERVAL HELLO_INTERVAL
* If the HELLO_INTERVAL for a MANET interface increases, then the * If the HELLO_INTERVAL for a MANET interface increases, then the
next HELLO message on this MANET interface MUST be generated next HELLO message on this MANET interface MUST be generated
according to the previous, shorter, HELLO_INTERVAL. Additional according to the previous, shorter, HELLO_INTERVAL. A number
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). according to current parameters).
* If the HELLO_INTERVAL for a MANET interface decreases, then the * If the HELLO_INTERVAL for a MANET interface decreases, then the
following HELLO messages on this MANET interface MUST be following HELLO messages on this MANET interface MUST be
generated according to this current, shorter, HELLO_INTERVAL. generated according to this current, shorter, HELLO_INTERVAL.
REFRESH_INTERVAL REFRESH_INTERVAL
* If the REFRESH_INTERVAL for a MANET interface increases, then * If the REFRESH_INTERVAL for a MANET interface increases, then
skipping to change at page 22, line 34 skipping to change at page 20, line 43
REFRESH_INTERVAL. REFRESH_INTERVAL.
* If the REFRESH_INTERVAL for a MANET interface decreases, then * 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 that 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
* If HYST_ACCEPT or HYST_REJECT changes, then the appropriate * 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
* If L_HOLD_TIME changes, then L_time for all relevant Link * If L_HOLD_TIME changes, then L_time for all relevant Link
Tuples MUST be changed. Tuples MUST be changed.
N_HOLD_TIME N_HOLD_TIME
* If N_HOLD_TIME changes, then NL_time for all relevant Lost * If N_HOLD_TIME changes, then NL_time for all relevant Lost
skipping to change at page 23, line 10 skipping to change at page 21, line 20
HP_MAXJITTER HP_MAXJITTER
* If HP_MAXJITTER changes, then the periodic HELLO message * If HP_MAXJITTER changes, then the periodic HELLO message
schedule on this MANET interface MAY be changed. schedule on this MANET interface MAY be changed.
HT_MAXJITTER HT_MAXJITTER
* If HT_MAXJITTER changes, then externally triggered HELLO * If HT_MAXJITTER changes, then externally triggered HELLO
messages on this MANET interface MAY be rescheduled. messages on this MANET interface MAY be rescheduled.
5.4. Constants 5.6. Constants
The constant C (time granularity) is used as specified in [timetlv]. The constant C (time granularity) is used as specified in [RFC5497].
6. Local Information Base 6. Local Information Base
A router maintains a Local Information Base that records information A router maintains a Local Information Base that records information
about its interfaces (MANET and non-MANET). Each interface MUST have about its interfaces (MANET and non-MANET). Each interface MUST have
at least one address, and MAY have more than one address. at least one address, and MAY have more than one address.
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
skipping to change at page 23, line 51 skipping to change at page 22, line 15
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 addresses which were A router's Removed Interface Address Set records addresses which were
recently local interface addresses. If a router's interface recently used as local interface addresses. If a router's interface
addresses are immutable then this set is always empty and MAY be addresses are immutable then the Removed Interface Address Set is
omitted. It consists of Removed Interface Address Tuples, one per always empty and MAY be omitted. It consists of Removed Interface
address: Address Tuples, one per address:
(IR_local_iface_addr, IR_time) (IR_local_iface_addr, IR_time)
where: where:
IR_local_iface_addr is a recently used address of an interface of IR_local_iface_addr is a recently used address of an interface of
this router. 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 Base 7. Interface Information Base
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 which can be reached in two
hops using those links as the first hop. The Interface Information hops using those links as the first hop. The Interface Information
Base includes the Link Set and the 2-Hop Set. Base includes the Link Set and the 2-Hop Set.
A MANET interface address can be present as of both a 1-hop neighbor An address of a symmetric 2-hop neighbor can also be present as the
and a symmetric 2-hop neighbor. This allows the router with this address of a 1-hop neighbor. This allows the router using this
MANET interface address to be immediately considered as a symmetric address to be immediately considered as a symmetric 2-hop neighbor if
2-hop neighbor if it fails to be a symmetric 1-hop neighbor. it fails to be a symmetric 1-hop neighbor.
An element which specifies a time is considered expired if the An element which specifies a time is considered expired if the
current time is greater than or equal to that time. One such element current time is greater than or equal to that time. One such
in most Tuples when expired indicates that the Tuple itself is element, present in most Tuples, indicates when expired that the
considered expired and MUST be removed when that element so Tuple itself is considered expired and MUST be removed. Tuples which
indicates. Tuples which do not have such a time element are removed do not have such a time element are removed at other times as
at other times as specified, for example a Neighbor Tuple is removed specified, for example a Neighbor Tuple is removed when all
when all corresponding Link Tuples have been removed. corresponding Link Tuples have been removed.
7.1. Link Set 7.1. Link Set
A router's Link Set records links from other routers which are, or A router's Link Set records links from other routers which are, or
recently were, 1-hop neighbors. It consists of Link Tuples, each recently were, 1-hop neighbors. It consists of Link Tuples, each
representing a single link: representing a single link:
(L_neighbor_iface_addr_list, L_HEARD_time, L_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)
skipping to change at page 25, line 19 skipping to change at page 23, line 34
would be considered symmetric if not considering link quality; would be considered symmetric if not considering link quality;
L_quality is a dimensionless number between 0 (inclusive) and 1 L_quality is a dimensionless number between 0 (inclusive) and 1
(inclusive) describing the quality of a link; a greater value of (inclusive) describing the quality of a link; a greater value of
L_quality indicating a higher quality link; L_quality indicating a higher quality link;
L_pending is a boolean flag, describing if a link is considered L_pending is a boolean flag, describing if a link is considered
pending (i.e. a candidate, but not yet established, link); pending (i.e. a candidate, but not yet established, link);
L_lost is a boolean flag, describing if a link is considered lost L_lost is a boolean flag, describing if a link is considered lost
due to link quality; due to 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 also taking link quality into account, is denoted L_status. and using link quality, is denoted L_status. L_status can take the
L_status can take the values PENDING, HEARD, SYMMETRIC and LOST. The values PENDING, HEARD, SYMMETRIC and LOST. The values LOST,
values LOST, SYMMETRIC and HEARD are defined in Section 17.5. The SYMMETRIC and HEARD are defined in Section 18.5. The value PENDING
value PENDING is never used in a HELLO message, it is only used is never used in a HELLO message, it is only used locally by a
locally by a router, and any value distinct from LOST, SYMMETRIC and router, and any value distinct from LOST, SYMMETRIC and HEARD may be
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 25, line 47 skipping to change at page 24, line 14
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
A router's 2-Hop Set records symmetric 2-hop neighbor interface A router's 2-Hop Set records addresses of symmetric 2-hop neighbors,
addresses, and the symmetric links to symmetric 1-hop neighbors and the symmetric links to symmetric 1-hop neighbors through which
through which the symmetric 2-hop neighbors can be reached. It these symmetric 2-hop neighbors can be reached. It consists of 2-Hop
consists of 2-Hop Tuples, each representing a single interface Tuples, each representing a single address of a symmetric 2-hop
address of a symmetric 2-hop neighbor, and a single MANET interface neighbor, and a single MANET interface of a symmetric 1-hop neighbor.
of a symmetric 1-hop neighbor.
(N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time) (N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time)
where: where:
N2_neighbor_iface_addr_list is an unordered list of the addresses of N2_neighbor_iface_addr_list is an unordered list of the addresses of
the MANET interface of the symmetric 1-hop neighbor from which the MANET interface of the symmetric 1-hop neighbor from which
this information was received; this information was received;
N2_2hop_iface_addr is an address of an interface of a symmetric N2_2hop_iface_addr is an address of a symmetric 2-hop neighbor which
2-hop neighbor which has a symmetric link (using any MANET has a symmetric link (using any MANET interface) to the indicated
interface) to the indicated symmetric 1-hop neighbor; 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 addresses of current and recently symmetric 1-hop information about addresses of current and recently symmetric 1-hop
neighbors. neighbors.
8.1. Neighbor Set 8.1. Neighbor Set
A router's Neighbor Set records all interface addresses of each 1-hop A router's Neighbor Set records all addresses of each 1-hop neighbor.
neighbor. It consists of Neighbor Tuples, each representing a single It consists of Neighbor Tuples, each representing a single 1-hop
1-hop neighbor: neighbor:
(N_neighbor_iface_addr_list, N_symmetric) (N_neighbor_iface_addr_list, N_symmetric)
where: where:
N_neighbor_iface_addr_list is an unordered list of the interface N_neighbor_iface_addr_list is an unordered list of the addresses of
addresses of a 1-hop neighbor; 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 addresses of all interfaces of A router's Lost Neighbor Set records addresses of routers which
routers which recently were symmetric 1-hop neighbors, but are now recently were symmetric 1-hop neighbors, but are now advertised as
advertised as lost. It consists of Lost Neighbor Tuples, each lost. It consists of Lost Neighbor Tuples, each representing a
representing a single such address: single such address:
(NL_neighbor_iface_addr, NL_time) (NL_neighbor_iface_addr, NL_time)
where: where:
NL_neighbor_iface_addr is an address of an interface of a router NL_neighbor_iface_addr is an address of a router which recently was
which recently was a symmetric 1-hop neighbor of this router; 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 change to respond to changes in the The Local Information Base MUST change to respond to changes in the
router's local interface configuration. The router MUST update its router's local interface configuration. The router MUST update its
Interface Information Base and Neighbor Information Base in response Interface Information Base and Neighbor Information Base in response
to such changes. If any changes in the Interface Information Base or to such changes. If any changes in the Interface Information Base or
the Neighbor Information Base satisfy any of the conditions described the Neighbor Information Base satisfy any of the conditions described
skipping to change at page 27, line 36 skipping to change at page 26, line 4
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 address interface. The actions in Section 9.3 MUST be taken for each address
of this added interface. A HELLO message MAY be sent on all MANET 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 schedule MUST interface. If using scheduled messages, then a message schedule MUST
be established on a new MANET interface. be established on the new MANET interface.
9.2. Removing an Interface 9.2. Removing an Interface
If an interface is removed from the router, then this MUST result in If an interface is removed from the router, then this MUST result in
changes to the Local Information Base and to the Neighbor Information changes to the Local Information Base and to the Neighbor Information
Base as follows: Base as follows:
1. Identify the Local Interface Tuple that corresponds to the 1. Identify the Local Interface Tuple that corresponds to the
interface to be removed. interface to be removed.
skipping to change at page 28, line 20 skipping to change at page 26, line 37
1. Remove the Interface Information Base for that MANET 1. Remove the Interface Information Base for that MANET
interface; interface;
2. All Neighbor Tuples for which none of the addresses in its 2. All Neighbor Tuples for which none of the addresses in its
N_neighbor_iface_addr_list are contained in any N_neighbor_iface_addr_list are contained in any
L_neighbor_iface_addr_list in any remaining Link Set, are L_neighbor_iface_addr_list in any remaining Link Set, are
removed. removed.
If a router removes the Local Interface Tuple that contains the If a router removes the Local Interface Tuple that contains the
interface address which is used to define the router's originator address which is used to define the router's originator address, as
address, as defined in [RFC5444], then the router MAY change defined in [RFC5444], then the router MAY change originator address.
originator address. If this interface address may now be used by If this address may now be used by another router (e.g., if the
another router (e.g. if the address was taken from a prefix no longer address was taken from a prefix no longer delegated to this router,
delegated to this router, or if the address was assigned with an or if the address was assigned with an expiration timer, and not
expiration timer, and not renewed before expiration) then this router renewed before expiration) then this router MUST change its
MUST change originator address. originator address.
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 longer participate in this protocol. router will 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 an Address to an Interface 9.3. Adding an Address to an Interface
skipping to change at page 29, line 15 skipping to change at page 27, line 33
3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr = the added 3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr = the added
address, are removed. address, are removed.
4. Any 2-Hop Tuples whose N2_2hop_iface_addr = the added address, 4. Any 2-Hop Tuples whose N2_2hop_iface_addr = the added address,
are removed. are removed.
After adding the address and making these changes, a HELLO message After adding the address and making these changes, a HELLO message
MAY be sent on all MANET interfaces. MAY be sent on all MANET interfaces.
These changes, other than to the appropriate I_local_iface_addr_list,
are made in order to maintain consistency of the Information Bases.
Specifically, these changes remove any record of any use of this
address by routers in the 1-hop neighborhood or in the symmetric
2-hop neighborhood of this router.
9.4. Removing an Address from an Interface 9.4. Removing an Address from an Interface
If an address (henceforth removed address) is removed from an If an address (henceforth removed address) is removed from an
interface then: interface then:
1. Identify the Local Interface Tuple that corresponds to the 1. Identify the Local Interface Tuple that corresponds to the
interface to be removed. address to be removed.
2. If this is the only address of that interface (the only address 2. If this is the only address of that interface (the only address
in the corresponding I_local_iface_addr_list) then remove that in the corresponding I_local_iface_addr_list) then remove that
interface as specified in Section 9.2. 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. Create a Removed Interface Address Tuple with: 2. Create a Removed Interface Address Tuple with:
+ IR_local_iface_addr := removed address; + IR_local_iface_addr := removed address;
+ IR_time := current time + I_HOLD_TIME. + IR_time := current time + I_HOLD_TIME.
If a router removes the interface address that is used to define the If a router removes the address that is used to define the router's
router's originator address, as defined in [RFC5444], then the router originator address, as defined in [RFC5444], then the router MAY
MAY change originator address. If this interface address may now be change originator address. If this address may now be used by
used by another router then this router MUST change originator another router (e.g., if the address was taken from a prefix no
address. longer delegated to this router, or if the address was assigned with
an expiration timer, and not renewed before expiration) then this
router MUST change its originator address.
After removing the address and making these changes, a HELLO message After removing the address and making these changes, a HELLO message
MAY be sent on all MANET interfaces. MAY be sent on all MANET interfaces.
10. Packets and Messages 10. Packets and Messages
The packet and message format used by this protocol is defined in The packet and message format used by this protocol is defined in
[RFC5444], which is used with the following considerations: [RFC5444], which is used with the following considerations:
o This protocol specifies one Message Type, the HELLO message. o This protocol specifies one Message Type, the HELLO message.
skipping to change at page 30, line 20 skipping to change at page 28, line 44
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 which is not in conformance with
[RFC5444] MUST be discarded. A HELLO message may also be [RFC5444] MUST be discarded. A HELLO message may also be
discarded for other reasons, see Section 12.1. discarded for other 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 [timetlv]. 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 protocol to, for example, this protocol. All references in this specification to, for
an Address Block TLV with Type = LINK_STATUS, are to be considered example, an Address Block TLV with Type = LINK_STATUS, are to be
as referring to an Address Block TLV with Type = LINK_STATUS and considered as referring to an Address Block TLV with Type =
Type Extension = 0. LINK_STATUS and Type Extension = 0.
10.1. HELLO Messages 10.1. HELLO Messages
A HELLO message MUST contain: A HELLO message MUST contain:
o A VALIDITY_TIME Message TLV as specified in [timetlv], o Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497],
representing H_HOLD_TIME for the transmitting MANET interface. representing H_HOLD_TIME for the transmitting MANET interface.
The options included in [timetlv] for representing zero and The options included in [RFC5497] for representing zero and
infinite times MUST NOT be used. infinite times MUST NOT be used.
A HELLO message which is transmitted periodically SHOULD contain, and A HELLO message which is transmitted periodically SHOULD contain, and
otherwise MAY contain: otherwise MAY contain:
o An INTERVAL_TIME Message TLV as specified in [timetlv], o Exactly one INTERVAL_TIME Message TLV as specified in [RFC5497],
representing HELLO_INTERVAL for the transmitting MANET interface. representing HELLO_INTERVAL for the transmitting MANET interface.
The options included in [timetlv] for representing zero and The options included in [RFC5497] for representing zero and
infinite times MUST NOT be used. infinite times MUST NOT be used.
A HELLO message MAY contain: A HELLO message MAY contain:
o Other Message TLVs. o Other Message TLVs.
o One or more Address Blocks, each with an associated Address Block o One or more Address Blocks, each with an associated Address Block
TLV Block, which MAY contain other Address Block TLVs. TLV Block, which MAY contain other Address Block TLVs.
10.1.1. Address Blocks 10.1.1. Address Blocks
All addresses in a router's Local Interface Set (i.e. in any All addresses in a router's Local Interface Set (i.e. in any
I_local_iface_addr_list) MUST be included in the Address Blocks in I_local_iface_addr_list) MUST be included in the Address Blocks in
all generated HELLO messages with the following exception. If the all generated HELLO messages with the following exception. If the
MANET interface on which the HELLO message is to be sent has a single MANET interface on which the HELLO message is to be sent has a single
interface address with maximum prefix length, then that address MAY address with maximum prefix length, then that address MAY be omitted
be omitted from being included in an Address Block, provided that from being included in any Address Block, provided that this address
this address is included as the sending address of the IP datagram in is included as the sending address of the IP datagram in which the
which the HELLO message is included. All addresses of the router's HELLO message is included. All addresses of the router's interfaces
interfaces included in an Address Block MUST be associated with an included in an Address Block MUST be associated with an Address Block
Address Block TLV with Type = LOCAL_IF, as defined in Table 1. TLV with Type = LOCAL_IF, as defined in Table 1.
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
| LOCAL_IF | 1 octet | Specifies that the address is an address | | LOCAL_IF | 1 octet | Specifies that the address is an address |
| | | associated with the interface on which the | | | | associated with the MANET interface on which |
| | | 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'
interface addresses, each of which is associated with Address Block addresses, each of which is associated with one or both Address Block
TLVs as described in Table 2. TLVs as described in Table 2.
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
| LINK_STATUS | 1 octet | Specifies the status of the link from | | LINK_STATUS | 1 octet | Specifies the status of the link from |
| | | the indicated address (LOST, SYMMETRIC | | | | the indicated address (LOST, SYMMETRIC |
| | | or HEARD). | | | | or HEARD). |
| OTHER_NEIGHB | 1 octet | Specifies that the address is | | OTHER_NEIGHB | 1 octet | Specifies that the address is |
skipping to change at page 32, line 4 skipping to change at page 30, line 27
| | | 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. The latter SHOULD NOT also Type = OTHER_NEIGHB and the same value. The latter SHOULD NOT also
be included. If an Address Block TLV with Type = LINK_STATUS and be included associated with the same address. If an Address Block
Value = SYMMETRIC is combined with an Address Block TLV with Type = TLV with Type = LINK_STATUS and Value = SYMMETRIC is combined with an
OTHER_NEIGHB and Value = LOST then the latter MUST be ignored, and Address Block TLV with Type = OTHER_NEIGHB and Value = LOST
SHOULD NOT be included. See Appendix A. associated with the same address, then the latter MUST be ignored,
and SHOULD NOT be included. See Appendix A.
Other addresses MAY be included in Address Blocks, but MUST NOT be Other addresses MAY be included in Address Blocks, but MUST NOT be
associated with any of the Address Block TLVs specified in this associated with any of the Address Block TLVs specified in this
specification. 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
HELLO 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 addresses in any I_local_iface_addr_list MUST be included, except All addresses in any I_local_iface_addr_list MUST be included, 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 interface address with maximum prefix length then that single address with maximum prefix length then that address MAY be
interface address MAY be omitted, provided that this address is omitted, provided that this address is included as the sending
included as the sending address of the IP datagram in which the address of the IP datagram in which the HELLO message is included.
HELLO message is included.
All such included addresses MUST be associated with an Address Block All such included addresses MUST be associated with an Address Block
TLV included with Type := LOCAL_IF and Value according to the TLV with Type := LOCAL_IF and Value according to the following:
following:
o If the address is an address of the sending interface, then Value o If the address is an address of the sending MANET interface, then
:= THIS_IF. Value := THIS_IF.
o Otherwise, Value := OTHER_IF. o Otherwise, Value := OTHER_IF.
The following addresses of current or former 1-hop neighbors MAY be The following addresses of current or former 1-hop neighbors MAY be
included in any HELLO message: included in any HELLO message, respecting the parameter
REFRESH_INTERVAL for each association for that MANET interface:
o Addresses of MANET interfaces of 1-hop neighbors from the Link Set o Addresses of MANET interfaces of 1-hop neighbors from the Link Set
of the Interface Information Base for this MANET interface, other of the Interface Information Base for this MANET interface (i.e.
than those from Link Tuples with L_status = PENDING. from an L_neighbor_iface_addr_list), other than those from Link
Tuples with L_status = PENDING.
o Other addresses of symmetric 1-hop neighbors from the Neighbor Set o Other addresses of symmetric 1-hop neighbors from the Neighbor Set
of this router's Neighbor Information Base. of this router's Neighbor Information Base (i.e. from an
N_neighbor_iface_addr_list).
o Addresses of MANET interfaces of previously symmetric or heard o Addresses of MANET interfaces of previously symmetric or heard
1-hop neighbors connected on this MANET interface from the Link 1-hop neighbors connected on this MANET interface from the Link
Set of the Interface Information Base for this MANET interface. Set of the Interface Information Base for this MANET interface
(These are advertised for a period equal to this interface's (i.e. from an L_neighbor_iface_addr_list with L_status = LOST).
L_HOLD_TIME after loss.)
o Other addresses of previously symmetric 1-hop neighbors from the o Other addresses of previously symmetric 1-hop neighbors from the
Lost Neighbor Set of this router's Neighbor Information Base. Lost Neighbor Set of this router's Neighbor Information Base (i.e.
(These are advertised for a period equal to N_HOLD_TIME after from an NL_neighbor_iface_addr).
loss.)
Each such address MUST be associated with one or more appropriate Each such address MUST be associated with one or more appropriate
Address Block TLVs, respecting the parameter REFRESH_INTERVAL for Address Block TLVs. Specifically:
each association for each MANET interface. Specifically:
1. For each address (henceforth linked address) which is contained 1. For each address (henceforth linked address) which is contained
in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set
for this MANET interface, for which L_status != PENDING, include for this MANET interface, for which L_status != PENDING, include
the linked address with an associated Address Block TLV with: the linked address with an associated Address Block TLV with:
* Type := LINK_STATUS; AND * Type := LINK_STATUS; AND
* Value := L_status. * Value := L_status.
skipping to change at page 34, line 9 skipping to change at page 32, line 33
* Value := SYMMETRIC. * Value := SYMMETRIC.
3. For each Lost Neighbor Tuple whose NL_neighbor_iface_addr 3. For each Lost Neighbor Tuple whose NL_neighbor_iface_addr
(henceforth lost address) has not already been included, include (henceforth lost address) has not already been included, include
the lost address with an associated Address Block TLV with: the lost address with an associated Address Block TLV with:
* Type := OTHER_NEIGHB; AND * Type := OTHER_NEIGHB; AND
* Value := LOST. * Value := LOST.
If any such addresses have been added since the last HELLO message If any such addresses have been added to these Information Bases
was sent on this MANET interface, or if their status (as indicated by since the last HELLO message was sent on this MANET interface, or if
these TLVs and the values they associate with that address) have their status (as indicated by these TLVs and the values they
changed since that address was last reported on this MANET interface, associate with that address) have changed since that address was last
then that address, and the indicated TLVs, MUST be included in the reported on this MANET interface, then that address, and the
HELLO message. indicated TLVs, MUST be included in the HELLO message.
If a 1-hop neighbor address is specified with more than one If an address of a 1-hop neighbor is specified with more than one
associated Address Block TLV, then these Address Block TLVs MAY be associated Address Block TLV, then these Address Block TLVs MAY be
independently included or excluded from each HELLO message. Each independently included or excluded from each HELLO message. Each
such Address Block TLV MUST be included associated with that address such Address Block TLV MUST be included associated with that address
in a HELLO message sent on that MANET interface in every interval of in a HELLO message sent on that MANET interface in every interval of
length equal to that MANET interface's parameter REFRESH_INTERVAL. length equal to that MANET interface's parameter REFRESH_INTERVAL.
Address Block TLVs associated with the same address included in the Address Block TLVs associated with the same address included in the
same HELLO message MAY be applied to the same or different copies of same HELLO message MAY be applied to the same or different copies of
that address. that address.
11.2. HELLO Message Transmission 11.2. HELLO Message Transmission
HELLO messages are transmitted in the packet/message format specified HELLO messages are transmitted in the format specified by [RFC5444].
by [RFC5444] using the "LL-MANET-Routers" multicast address specified
by [manet-iana] as destination IP address, using either the "manet"
UDP port, or the "manet" IP protocol number specified in
[manet-iana].
11.2.1. HELLO Message Jitter 11.2.1. HELLO Message Jitter
HELLO messages MAY be sent using periodic message generation or HELLO messages MAY be sent using periodic message generation or
externally triggered message generation. If using data link and externally triggered message generation. If using data link and
physical layers which are subject to packet loss due to collisions, physical layers which are subject to packet loss due to collisions,
HELLO messages SHOULD be jittered as described in [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
skipping to change at page 35, line 25 skipping to change at page 33, line 47
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. Otherwise the receiving router MUST update its Section 12.1. Otherwise the receiving router MUST update its
appropriate Interface Information Base and its Neighbor Information appropriate Interface Information Base and its Neighbor Information
Base as specified in Section 12.3 to Section 12.6. These updates Base as specified in Section 12.3 to Section 12.6. These updates
MUST be performed in the order in which they are presented in this MUST be performed in the order in which they are presented in this
specification. If any changes satisfy any of the conditions specification. If any changes satisfy any of the conditions
described in Section 13 then the indicated consequences MUST be described in Section 13 then the indicated consequences in that
applied immediately, unless noted otherwise. section MUST be applied 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
any of the following conditions are true. any of the following conditions are true:
o The message has a <msg-hop-limit> field in its <msg-header> with a o The address length as specified in the the Message Header is not
value other than one. (Note that the message need not have a equal to the length of the addresses used by this router.
o The message has a <msg-hop-limit> field in its Message Header with
a value other than one. (Note that the message need not have a
<msg-hop-limit> field.) <msg-hop-limit> field.)
o The message has a <msg-hop-count> field in its <msg-header> with a o The message has a <msg-hop-count> field in its Message Header with
value other than zero. (Note that the message need not have a a value other than zero. (Note that the message need not have a
<msg-hop-count> field.) <msg-hop-count> field.)
o The message does not have a Message TLV with Type = VALIDITY_TIME o The message does not have a Message TLV with Type = VALIDITY_TIME
in its Message TLV Block. in its Message TLV Block.
o The message has more than one Message TLV with Type = o The message has more than one Message TLV with Type =
VALIDITY_TIME in its Message TLV Block, and these Message TLVs VALIDITY_TIME in its Message TLV Block.
indicate different validity times, as specified by [timetlv].
o The message has more than one Message TLV with Type =
INTERVAL_TIME in its Message TLV Block.
o The message has any Address Block TLV(s) with Type = LOCAL_IF and o The message has any Address Block TLV(s) with Type = LOCAL_IF and
any single value v such that v != THIS_IF and v!= OTHER_IF. any single value v such that v != THIS_IF and v!= OTHER_IF.
o Any address (including different copies of an address, in the same o Any address (including different copies of an address, in the same
or different Address Blocks) is associated with more than one or different Address Blocks) is associated with more than one
value by one or more Address Block TLV(s) with Type = LOCAL_IF. value by one or more Address Block TLV(s) with Type = LOCAL_IF.
o Any address (the local address) associated with an Address Block o Any address (henceforth the local address) associated with an
TLV with Type = LOCAL_IF is one of the receiving router's current Address Block TLV with Type = LOCAL_IF is one of the receiving
or recently used interface addresses (i.e. the local address is router's current or recently used addresses (i.e. the local
contained in any I_local_iface_addr_list in the Local Interface address is contained in any I_local_iface_addr_list in the Local
Set or the local address = any IR_local_iface_addr in the Removed Interface Set or the local address = any IR_local_iface_addr in
Interface Address Set). the Removed Interface Address Set).
o The message has any Address Block TLV(s) with Type = LINK_STATUS o The message has any Address Block TLV(s) with Type = LINK_STATUS
with any single value v such that v != LOST, v != SYMMETRIC, and with any single value v such that v != LOST, v != SYMMETRIC, and v
v!= HEARD. != HEARD.
o Any address (including different copies of an address, in the same o Any address (including different copies of an address, in the same
or different Address Blocks) is associated with more than one or different Address Blocks) is associated with more than one
value by one or more Address Block TLVs with Type = LINK_STATUS. value by one or more Address Block TLVs with Type = LINK_STATUS.
o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB
with any single value v such that v!= LOST and v!= SYMMETRIC. with any single value v such that v!= LOST and v!= SYMMETRIC.
o Any address (including different copies of an address, in the same o Any address (including different copies of an address, in the same
or different Address Blocks) is associated with more than one or different Address Blocks) is associated with more than one
skipping to change at page 36, line 44 skipping to change at page 35, line 23
An invalid message MUST be silently discarded, without updating the An invalid message MUST be silently discarded, without updating the
router's Information Bases. A router MAY recognize additional router's Information Bases. A router MAY recognize additional
reasons for identifying that a message is badly formed, and discard reasons for identifying that a message is badly formed, and discard
such messages. such messages.
12.2. Definitions 12.2. Definitions
For the purpose of this section, note the following definitions: For the purpose of this section, note the following definitions:
o "validity time" is calculated from the Message TLV with Type = o "validity time" is calculated from the Message TLV with Type =
VALIDITY_TIME of the HELLO message as specified in [timetlv]. VALIDITY_TIME of the HELLO message as specified in [RFC5497].
(Note that, as specified by Section 12.1, there must be such a (Note that, as specified by Section 12.1, there must be exactly
Message TLV, and if there is more than one, they must indicate the one such Message TLV in the HELLO message.) All information in
same validity time.) All information in the HELLO message has the the HELLO message used by this specification has the same validity
same validity time. time.
o "Receiving Address List" is the I_local_iface_addr_list o "Receiving Address List" is the I_local_iface_addr_list
corresponding to the MANET interface on which the HELLO message corresponding to the MANET interface on which the HELLO message
was received was received
o "Sending Address List" is the list of the addresses contained in o "Sending Address List" is the list of the addresses contained in
the HELLO message with an associated Address Block TLV with Type = the HELLO message with an associated Address Block TLV with Type =
LOCAL_IF and Value = THIS_IF. If the Sending Address List is LOCAL_IF and Value = THIS_IF. If the Sending Address List is
otherwise empty, then the Sending Address List contains a single otherwise empty, then the Sending Address List contains a single
address (with maximum prefix length) equal to the sending address address (with maximum prefix length) equal to the sending address
of the IP datagram in which the HELLO message was included. of the IP datagram in which the HELLO message was included.
o "Neighbor Address List" is the Sending Address List, plus the o "Neighbor Address List" is the Sending Address List, plus the
addresses contained in the HELLO message with an associated addresses contained in the HELLO message with an associated
Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF. Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF.
skipping to change at page 37, line 16 skipping to change at page 35, line 45
LOCAL_IF and Value = THIS_IF. If the Sending Address List is LOCAL_IF and Value = THIS_IF. If the Sending Address List is
otherwise empty, then the Sending Address List contains a single otherwise empty, then the Sending Address List contains a single
address (with maximum prefix length) equal to the sending address address (with maximum prefix length) equal to the sending address
of the IP datagram in which the HELLO message was included. of the IP datagram in which the HELLO message was included.
o "Neighbor Address List" is the Sending Address List, plus the o "Neighbor Address List" is the Sending Address List, plus the
addresses contained in the HELLO message with an associated addresses contained in the HELLO message with an associated
Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF. Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF.
o EXPIRED indicates that a timer is set to a value clearly preceding o EXPIRED indicates that a timer is set to a value clearly preceding
the current time (e.g. current time - 1). the current time (e.g., current time - 1).
o "Removed Address List" is a list of addresses created by this o "Removed Address List" is a list of addresses created by this
HELLO message processing which were formerly reported as local by HELLO message processing which were formerly reported as local by
the router originating the HELLO message, but which are not the router originating the HELLO message, but which are not
included in the Neighbor Address List. This list is initialized included in the Neighbor Address List. This list is 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 addresses which were formerly considered as symmetric. containing addresses which were formerly considered as symmetric.
This list is initialized as empty. 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 (hereafter matching Neighbor Tuples) 1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples)
where: where:
* N_neighbor_iface_addr_list contains at least one address in * N_neighbor_iface_addr_list contains at least one address in
the Neighbor Address List. 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:
+ N_neighbor_iface_addr_list := Neighbor Address List; + N_neighbor_iface_addr_list := Neighbor Address List;
skipping to change at page 39, line 16 skipping to change at page 37, line 42
On receiving a HELLO message, a router MUST update its Link Set for On receiving a HELLO message, a router MUST update its Link Set for
the MANET interface on which the HELLO message is received: the MANET interface on which the HELLO message is received:
1. Remove all addresses in the Removed Address List from the 1. Remove all 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.
3. Find all Link Tuples (hereafter matching Link Tuples) where: 3. Find all Link Tuples (henceforth matching Link Tuples) where:
* L_neighbor_iface_addr_list contains one or more addresses in * L_neighbor_iface_addr_list contains one or more addresses in
the Sending Address List. the Sending Address List.
4. If there is more than one matching Link Tuple, then remove them 4. 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.
5. If no matching Link Tuples remain, then create a new matching 5. If no matching Link Tuples remain, then create a new matching
Link Tuple with: Link Tuple with:
skipping to change at page 41, line 37 skipping to change at page 40, line 18
- N2_neighbor_iface_addr_list := Sending Address List; - N2_neighbor_iface_addr_list := Sending Address List;
- N2_time := current time + validity time. - N2_time := current time + validity time.
5. Otherwise if the 2-hop address has an Address Block TLV 5. Otherwise if the 2-hop address has an Address Block TLV
with: with:
- Type = LINK_STATUS and Value = LOST or Value = HEARD; - Type = LINK_STATUS and Value = LOST or Value = HEARD;
OR OR
- Type = OTHER_NEIGHB and Value =o LOST; - Type = OTHER_NEIGHB and Value = LOST;
then remove all 2-Hop Tuples with: then remove all 2-Hop Tuples with:
- N2_neighbor_iface_addr_list contains one or more - N2_neighbor_iface_addr_list contains one or more
addresses in the Sending Address List; AND addresses in the Sending Address List; AND
- N2_2hop_iface_addr = 2-hop address. - N2_2hop_iface_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
some 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 which cause changes in the Information Bases are:
o A Link Tuple's L_status changes to symmetric. o A Link Tuple's L_status changes to SYMMETRIC. In this case, the
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. is removed. In this case, the actions specified in Section 13.2
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.
o Local interface address changes, as specified in Section 9. o Local interface address changes. In this case, the actions
specified in Section 9 are performed.
o Link quality changes, as specified in Section 14. o Link quality changes. In this case, the actions specified in
Section 14 are performed.
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 Section 13.2 MUST be performed before L_HEARD_time expires, then the actions specified in Section 13.2 MUST
Section 13.3 for that Link Tuple. be performed before the actions specified in section Section 13.3 are
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 which 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
skipping to change at page 42, line 42 skipping to change at page 41, line 28
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 which does not have L_status = SYMMETRIC:
o L_status := SYMMETRIC; o L_status changes to SYMMETRIC;
(this includes a newly created Link Tuple which is immediately (this includes a newly created Link Tuple which is immediately
updated to have L_status := SYMMETRIC) then: updated such that L_status = SYMMETRIC) then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains
L_neighbor_iface_addr_list, set: L_neighbor_iface_addr_list, set:
* N_symmetric := true. * N_symmetric := true.
2. Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is 2. Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is
contained in that N_neighbor_iface_addr_list. contained in that N_neighbor_iface_addr_list.
13.2. Link Tuple Not Symmetric 13.2. Link Tuple Not Symmetric
skipping to change at page 44, line 28 skipping to change at page 43, line 14
* L_HEARD_time is not expired; * L_HEARD_time is not expired;
then remove the Neighbor Tuple. then remove the Neighbor Tuple.
14. Link Quality 14. Link Quality
Link quality is a mechanism whereby a router MAY take considerations Link quality is a mechanism whereby a router MAY take considerations
other than message exchange into account for determining when a link other than message exchange into account for determining when a link
is and is not a candidate for being considered as HEARD or SYMMETRIC. is and is not a candidate for being considered as HEARD or SYMMETRIC.
Link quality information for a link is generated (e.g. through access Link quality information for a link is generated (e.g., through
to signal to noise ratio, packet loss rate, or other information from access to signal to noise ratio, packet loss rate, or other
the link layer) and used only locally, i.e. is not included in information from the link layer) and used only locally, i.e. is not
signaling, and routers may interoperate whether they are using the included in signaling, and routers may interoperate whether they are
same, different, or no, link quality information. using the same, different, or no, link quality information.
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. Section 14.3 and Section 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
skipping to change at page 45, line 25 skipping to change at page 44, line 8
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 over-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:
* If INITIAL_PENDING = true, then this is such that L_quality >= * If INITIAL_PENDING = true, then the link is advertised when
HYST_ACCEPT. link L_quality >= HYST_ACCEPT.
* Otherwise this is such that L_quality >= HYST_REJECT. To * Otherwise the link is advertised when L_quality >= HYST_REJECT.
ensure this, a router MUST NOT define INITIAL_PENDING = false
and INITIAL_QUALITY < HYST_REJECT. (A router also MUST NOT
define INITIAL_PENDING = true and INITIAL_QUALITY >=
HYST_ACCEPT.)
A link which is not yet advertised has L_pending = true. A link which 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 which 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
define:
o INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR
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:
+ L_time := max(L_time, L_HEARD_time + L_HOLD_TIME) + 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:
+ L_lost := true + L_lost := true;
+ L_time := min(L_time, current time + L_HOLD_TIME) + L_time := min(L_time, current time + L_HOLD_TIME).
Any appropriate action indicted in Section 13 MUST also be taken. Any appropriate action indicted in Section 13 MUST also be taken.
If L_quality for a link is updated based on HELLO message reception, If L_quality for a link is updated based on HELLO message reception,
or on reception of a packet including a HELLO message, then L_quality or on reception of a packet including a HELLO message, then L_quality
MUST be updated prior to the HELLO message processing described in MUST be updated prior to the HELLO message processing described in
Section 12. (If the receipt of the HELLO message, or the packet Section 12. (If the receipt of the HELLO message, or the packet
containing it, creates the Link Tuple, then 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.)
skipping to change at page 47, line 10 skipping to change at page 45, line 43
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 [timetlv]) 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 which may
be used when a single value of each is used. be used when a single value of each is used.
skipping to change at page 48, line 18 skipping to change at page 47, line 9
15.5. Jitter Interface Parameters 15.5. Jitter Interface Parameters
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. Security Considerations 16. Usage with Other Protocols
Other protocols, such as MANET routing protocols, which use
neighborhood discovery may need to interact with this protocol. This
protocol is designed to permit such interactions, in particular:
o Through accessing, and possibly extending, the information in the
Local Information Base (Section 6), the Interface Information Base
(Section 7) and the Neighbor Information Base (Section 8). These
Information Bases record the interface configuration of the
router, as well as the local connectivity, up to two hops away.
All updates to the elements specified in this document are subject
to the constraints specified in Appendix B.
o Through accessing an outgoing HELLO message prior to it being
transmitted over any MANET interface, and to add information
(e.g., TLVs) as specified in [RFC5444]. This may, for example, be
to allow a security protocol, as suggested in Section 17, to add a
TLV containing a cryptographic signature to the message, or be to
allow inserting relay selection information into a HELLO message
by way of adding a TLV to an outgoing HELLO message prior to it
being transmitted.
o Through accessing an incoming HELLO message, and potentially
discard it prior to processing by this protocol. This may, for
example, allow a security protocol as suggested in Section 17 to
perform verification of HELLO message signatures and prevent
processing of unverifiable HELLO messages by this protocol.
o Through accessing an incoming HELLO message after it has been
completely processed by this protocol. This may, in particular,
allow a protocol which has added information, such as relay
selection information by way of inclusion of appropriate TLVs,
access to such information after appropriate updates have been
recorded in the Information Bases in this protocol.
o Through requesting that a HELLO message be generated at a specific
time. In that case, HELLO message generation MUST still respect
the constraints in Appendix B.
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 and symmetric 2-hop to acquire information describing its 1-hop neighborhood and
neighborhoods. This is acquired through message exchange between symmetric 2-hop neighborhood. This is acquired through message
neighboring routers. The information is made available through the exchange between neighboring routers. The information is made
Interface Information Bases and Neighbor Information Base, describing available through the Interface Information Bases and Neighbor
the router's 1-hop neighborhood and symmetric 2-hop neighborhood. Information Base, describing the router's 1-hop neighborhood and
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 which have not (yet) been tracked by
the HELLO message exchanges. the HELLO message exchanges.
If a router for some reason, whether malice or malfunction, injects 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. The protocol specification does, other routers' Information Bases. The protocol specification does,
however, prevent inconsistent information from being injected in the however, prevent inconsistent information from being included in the
protocol sets through the constraints in Appendix B. The exact protocol sets through the defined processing that maintains the
consequence of information inexactness depends on the use of these constraints in Appendix B. The exact consequence of information
Information Bases, and should be reflected in the specification of inexactness depends on the use of these Information Bases, and should
protocols which use information provided by NHDP. be reflected in the specification of protocols which use information
provided by NHDP.
This section, therefore, only outlines the ways in which correctly This section, therefore, only 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 16.1. In addition, in Section 16.2, the security suggestions Section 17.1. In addition, in Section 17.2, the security suggestions
in [RFC5444] are considered for applicability. in [RFC5444] are considered for applicability.
16.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 in an the following forms. Note that a present or absent address in an
Address Block, does not in and by itself cause a problem. It is the Address Block, does not in and 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:
* The HELLO message may contain addresses with an associated * The HELLO message may contain addresses with an associated
skipping to change at page 50, line 6 skipping to change at page 49, line 42
neighborhood; neighborhood;
* The value of a LINK_STATUS Address Block TLV may incorrectly * 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.
* The value of an OTHER_NEIGHB Address Block TLV may incorrectly * 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.
16.2. Authentication, Integrity and Confidentiality Suggestions 17.2. Authentication, Integrity and Confidentiality Suggestions
The security mechanisms suggested in [RFC5444] with respect to
authentication and integrity can be applied to this neighborhood
discovery protocol, with the following additional considerations:
o As HELLO messages MUST NOT be forwarded, the fields <msg-hop- The security suggestions in [RFC5444] regarding inclusion of a
count> and <msg-hop-limit> are either omitted, or will always have cryptographic signature in a Message TLV or a Packet TLV can be
the values of 0 and 1, respectively. applied to this protocol. Failure to verify either form of
cryptographic signature causes a HELLO message to be rejected without
being processed.
o Consequently, a cryptographic signature can be calculated based on The following simplification of the suggestions for end-to-end
the entire HELLO message, including its Message Header, and authentication and integrity in [RFC5444] may be applied to HELLO
included in a Message TLV of an appropriate type. messages:
o As HELLO messages MUST NOT be forwarded, and in case hop-by-hop o As the Message Header fields <msg-hop-count> and <msg-hop-limit>
packet level authentication and integrity is ensured by including are either omitted or will always have the values 0 and 1,
an appropriate Packet TLV containing a cryptographic signature respectively, an end to end cryptographic signature can be
across the entire packet, inclusion of an additional Message TLV calculated based on the entire HELLO message, including its
containing a cryptographic signature for the HELLO Message may not unmodified Message Header.
be necessary.
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 neighborhood confidentiality can be directly applied to this protocol.
discovery protocol.
17. IANA Considerations 18. IANA Considerations
This specification defines one Message Type, which must be allocated This specification defines one Message Type, which must be allocated
from the "Message Types" repository of [RFC5444], and three Address from the "Message Types" repository of [RFC5444], and three Address
Block TLV Types, which must be allocated from the "Message TLV Types" Block TLV Types, which must be allocated from the "Address Block TLV
repository of [RFC5444]. Types" repository of [RFC5444].
17.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].
17.2. Message Types 18.2. Message Types
This specification defines one Message Type, to be allocated from the This specification defines one Message Type, to be allocated from the
0-223 range of the "Message Types" namespace defined in [RFC5444], as 0-223 range of the "Message Types" namespace defined in [RFC5444], as
specified in Table 3. specified in Table 3.
+-------+------+-----------------+ +-------+------+-----------------+
| Name | Type | Description | | Name | Type | Description |
+-------+------+-----------------+ +-------+------+-----------------+
| HELLO | TBD1 | Local signaling | | HELLO | TBD1 | Local signaling |
+-------+------+-----------------+ +-------+------+-----------------+
Table 3: Message Type assignment Table 3: Message Type assignment
17.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 is requested to create a registry for Message-Type-specific
Message TLVs for HELLO messages, in accordance with Section 6.4 of Message TLVs for HELLO messages, in accordance with Section 6.2.1 of
[RFC5444], and with initial assignments and allocation policies as [RFC5444], and with initial assignments and allocation policies as
specified in Table 4. specified in 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 is requested to create a registry for Message-Type-specific
Address Block TLVs for HELLO messages, in accordance with Section 6.5 Address Block TLVs for HELLO messages, in accordance with Section
of [RFC5444], and with initial assignments and allocation policies as 6.2.1 of [RFC5444], and with initial assignments and allocation
specified in Table 5. policies as 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
17.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 must
be allocated from the "Address Block TLV Types" namespace defined in be allocated from the "Address Block TLV Types" namespace defined in
[RFC5444]. IANA are requested to make allocations in the 0-127 range [RFC5444]. IANA are requested to make allocations in the 0-127 range
for these types. This will create three new type extension for these types. This will create three new type extension
registries with assignments as specified in Table 6, Table 7 and registries with assignments as specified in Table 6, Table 7 and
Table 8. Specifications of these Address Block TLVs are in Table 8. Specifications of these Address Block TLVs are in
Section 10.1.1, with value constants defined in Section 17.5. Section 10.1.1, with Value Constants defined in Section 18.5.
+----------+------+-----------+-------------------------------------+ +------------+------+-----------+-----------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+----------+------+-----------+-------------------------------------+ +------------+------+-----------+-----------------------------------+
| LOCAL_IF | TBD2 | 0 | Specifies that the address is | | LOCAL_IF | TBD2 | 0 | Specifies that the address is |
| | | | associated with a local interface | | | | | associated with a local interface |
| | | | of the sending router | | | | | of the sending router |
| | | 1-255 | Expert Review | | Unassigned | TBD2 | 1-255 | Expert Review |
+----------+------+-----------+-------------------------------------+ +------------+------+-----------+-----------------------------------+
Table 6: Address Block TLV Type assignment: LOCAL_IF Table 6: Address Block TLV Type assignment: LOCAL_IF
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
| LINK_STATUS | TBD3 | 0 | Specifies the status of the link | | LINK_STATUS | TBD3 | 0 | Specifies the status of the link |
| | | | from the indicated address | | | | | from the indicated address |
| | | | (LOST, SYMMETRIC or HEARD) | | | | | (LOST, SYMMETRIC or HEARD) |
| | | 1-255 | Expert Review | | Unassigned | TBD3 | 1-255 | Expert Review |
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
Table 7: Address Block TLV Type assignment: LINK_STATUS Table 7: Address Block TLV Type assignment: LINK_STATUS
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
| OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is | | OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is |
| | | | (SYMMETRIC) or recently was | | | | | (SYMMETRIC) or recently was |
| | | | (LOST) of an interface of a | | | | | (LOST) of an interface of a |
| | | | symmetric 1-hop neighbor of the | | | | | symmetric 1-hop neighbor of the |
| | | | router transmitting the message | | | | | router transmitting the message |
| | | 1-255 | Expert Review | | Unassigned | TBD4 | 1-255 | Expert Review |
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
Table 8: Address Block TLV Type assignment: OTHER_NEIGHB Table 8: Address Block TLV Type assignment: OTHER_NEIGHB
17.5. LINK_STATUS and OTHER_NEIGHB Values 18.5. LINK_STATUS and OTHER_NEIGHB Values
The values which the LOCAL_IF Address Block TLV can use are the The values which 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 which the LINK_STATUS Address Block TLV can use are the
following: following:
skipping to change at page 53, line 19 skipping to change at page 53, line 9
o HEARD := 2 o HEARD := 2
The values which the OTHER_NEIGHB Address Block TLV can use are the The values which the OTHER_NEIGHB Address Block TLV can use are the
following: following:
o LOST := 0 o LOST := 0
o SYMMETRIC := 1 o SYMMETRIC := 1
18. 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, 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,
<chris.dearlove@baesystems.com> <chris.dearlove@baesystems.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
19. Acknowledgements 20. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, The authors would like to acknowledge the team behind OLSRv1,
specified in RFC3626 for their contributions. specified in RFC3626 for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components (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.
20. References 21. References
20.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", RFC 2119, BCP 14, 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 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 MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[timetlv] Clausen, T. and C. Dearlove, "Representing multi-value [RFC5497] Clausen, T. and C. Dearlove, "Representing multi-value
time in MANETs", Work In time in MANETs", RFC 5497, March 2009.
Progress draft-ietf-manet-timetlv-08.txt,
September 2008.
[manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols", [RFC5498] Chakeres, I., "IANA Allocations for MANET Protocols",
Work In Progress draft-ietf-manet-iana-07.txt, RFC 5498, March 2009.
November 2007.
20.2. Informative References 21.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC5449] Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet, [RFC5449] Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet,
"OSPF Multipoint Relay (MPR) Extension for Ad Hoc "OSPF Multipoint Relay (MPR) Extension for Ad Hoc
 End of changes. 193 change blocks. 
640 lines changed or deleted 608 lines changed or added

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