draft-ietf-manet-nhdp-10.txt   draft-ietf-manet-nhdp-11.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: January 14, 2010 BAE Systems ATC Expires: April 29, 2010 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
July 13, 2009 October 26, 2009
MANET Neighborhood Discovery Protocol (NHDP) Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-10 draft-ietf-manet-nhdp-11
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 January 14, 2010. This Internet-Draft will expire on April 29, 2010.
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 26 skipping to change at page 2, line 26
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
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11 4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11
4.2. Information Base Overview . . . . . . . . . . . . . . . . 11 4.2. Information Base Overview . . . . . . . . . . . . . . . . 12
4.2.1. Local Information Base . . . . . . . . . . . . . . . . 12 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 12
4.2.2. Interface Information Bases . . . . . . . . . . . . . 12 4.2.2. Interface Information Bases . . . . . . . . . . . . . 13
4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 13 4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 13
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 14 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 15
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 15 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 15
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 15 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 16
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 16 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 17
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 16 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 17
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 16 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 17
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 16 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 17
5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 17 5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 18
5.3.2. Information Validity Times . . . . . . . . . . . . . . 18 5.3.2. Information Validity Times . . . . . . . . . . . . . . 19
5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 19 5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 20
5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 20 5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 21
5.4.1. Information Validity Time . . . . . . . . . . . . . . 20 5.4.1. Information Validity Time . . . . . . . . . . . . . . 21
5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 20 5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 21
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 21 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 23
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 22 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 23
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 22 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 24
7. Interface Information Base . . . . . . . . . . . . . . . . . . 23 7. Interface Information Base . . . . . . . . . . . . . . . . . . 24
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 25 8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 26
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 25 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 27
9. Local Information Base Changes . . . . . . . . . . . . . . . . 26 9. Local Information Base Changes . . . . . . . . . . . . . . . . 27
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 26 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 27
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 26 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 28
9.3. Adding an Address to an Interface . . . . . . . . . . . . 27 9.3. Adding a Network Address to an Interface . . . . . . . . . 28
9.4. Removing an Address from an Interface . . . . . . . . . . 28 9.4. Removing a Network Address from an Interface . . . . . . . 29
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 28 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 30
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 29 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 30
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 29 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 31
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 31 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 32
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 31 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 33
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 33 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 35
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 33 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 35
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 34 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 35
12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 34 12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 36
12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 35 12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37
12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 36 12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 38
12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 37 12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 40
12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 37 12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 40
12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 39 12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 42
13. Other Information Base Changes . . . . . . . . . . . . . . . . 40 13. Other Information Base Changes . . . . . . . . . . . . . . . . 43
13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 41 13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 44
13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 42 13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 44
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 43 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 45
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 43 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 45
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 43 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 46
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 44 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 46
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 45 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 47
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 45 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 48
15. Proposed Values for Parameters and Constants . . . . . . . . . 46 15. Proposed Values for Parameters and Constants . . . . . . . . . 48
15.1. Message Interval Interface Parameters . . . . . . . . . . 46 15.1. Message Interval Interface Parameters . . . . . . . . . . 48
15.2. Information Validity Time Interface Parameters . . . . . . 46 15.2. Information Validity Time Interface Parameters . . . . . . 49
15.3. Information Validity Time Router Parameters . . . . . . . 46 15.3. Information Validity Time Router Parameters . . . . . . . 49
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 46 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 49
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 47 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 49
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 47 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 49
16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 47 16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 49
17. Security Considerations . . . . . . . . . . . . . . . . . . . 48 17. Security Considerations . . . . . . . . . . . . . . . . . . . 51
17.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 49 17.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 53
17.2. Authentication, Integrity and Confidentiality 17.2. Authentication, Integrity and Confidentiality
Suggestions . . . . . . . . . . . . . . . . . . . . . . . 50 Suggestions . . . . . . . . . . . . . . . . . . . . . . . 54
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 51 18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 55
18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 51 18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 55
18.3. Message-Type-specific TLV Type Registries . . . . . . . . 51 18.3. Message-Type-specific TLV Type Registries . . . . . . . . 55
18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 52 18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 56
18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 53 18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 57
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 57
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
21.1. Normative References . . . . . . . . . . . . . . . . . . . 54 21.1. Normative References . . . . . . . . . . . . . . . . . . . 58
21.2. Informative References . . . . . . . . . . . . . . . . . . 54 21.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 55 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 59
Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 56 Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 60
Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 58 Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 63
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 61 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 65
Appendix E. Interval and Timer Illustrations . . . . . . . . . . 62 Appendix E. Interval and Timer Illustrations . . . . . . . . . . 66
E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 62 E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 66
E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 68 E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 72
E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 69 E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 73
Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 71 Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 75
F.1. Example 1: Standard Single Interface Topology . . . . . . 71 F.1. Example 1: Standard Single Interface Topology . . . . . . 75
F.2. Example 2: Dual Addressed Interface on One Hop Neighbor . 72 F.2. Example 2: Dual Addressed Interface on One Hop Neighbor . 76
F.3. Example 3: Dual Addressed Interface on Two Hop Neighbor . 73 F.3. Example 3: Dual Addressed Interface on Two Hop Neighbor . 77
F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 73 F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 77
F.5. Example 5: Dual Interface on Two Hop Neighbor . . . . . . 74 F.5. Example 5: Dual Interface on Two Hop Neighbor . . . . . . 78
F.6. Example 6: Dual interface on One Hop Neighbor . . . . . . 74 F.6. Example 6: Dual interface on One Hop Neighbor . . . . . . 78
F.7. Example 7: Dual Interface on One and Two Hop Neighbors . . 75 F.7. Example 7: Dual Interface on One and Two Hop Neighbors . . 79
F.8. Example 8: Dual Interface Locally and on One Hop F.8. Example 8: Dual Interface Locally and on One Hop
Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . 76 Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . 80
F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 76 F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 80
F.10. Example 10: Dual Addressed Dual Interfaces on All F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers . . . . . . . . . . . . . . . . . . . . . . . . . 77 Routers . . . . . . . . . . . . . . . . . . . . . . . . . 81
F.11. Example 11: Single Addressed Dual Interface Locally . . . 78 F.11. Example 11: Single Addressed Dual Interface Locally . . . 82
1. Introduction 1. Introduction
This document describes a neighborhood discovery protocol (NHDP) for This document describes a neighborhood discovery protocol (NHDP) for
a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a
local exchange of HELLO messages in order that each router can local exchange of HELLO messages in order that each router can
determine the presence of, and connectivity to, its 1-hop and determine the presence of, and connectivity to, its 1-hop and
symmetric 2-hop neighbors. Messages are defined and sent in packets symmetric 2-hop neighbors. Messages are defined and sent in packets
according to the specification [RFC5444]. according to the specification [RFC5444].
skipping to change at page 5, line 33 skipping to change at page 5, line 33
other than support of local broadcast or multicast for communication other than support of local broadcast or multicast for communication
to 1-hop neighbor routers. Link layer information may be used if to 1-hop neighbor routers. Link layer information may be used if
available and applicable. available and applicable.
This protocol is based on the neighborhood discovery process This protocol is based on the neighborhood discovery process
contained in the Optimized Link State Routing Protocol (OLSR) contained in the Optimized Link State Routing 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 communication channels (e.g., wireless, lossy, more challenging communication channels (e.g., wireless, lossy,
broadcast channels with moderate and shared bandwidth, hidden and broadcast channels with moderate and shared bandwidth, hidden and
exposed terminals and interference from other network devices 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). network membership).
Due to the properties of wireless transmissions, communication Due to the properties of wireless transmissions, communication
between two neighboring routers may not be bidirectional; even if between two neighboring routers may not be bi-directional; even if
router A is able to receive packets from router B, the converse is router A is able to receive packets from router B, the converse is
not guaranteed to be true. Furthermore, because of the localized not guaranteed to be true. Furthermore, because of the localized
nature of wireless broadcast communication, neighboring routers nature of wireless broadcast communication, neighboring routers
within the same communications channel may have different sets of within the same communications channel may have different sets of
neighbors. That is, when using the same communication channel, even neighbors. That is, when using the same communication channel, even
if router A is able to exchange packets with router B and router B is if router A is able to exchange packets with router B and router B is
able to exchange packets with router C, then this does not guarantee able to exchange packets with router C, then this does not guarantee
that router A and router C can exchange packets directly. that router A and router C can exchange packets directly.
Each router in a MANET may use more than one communication channel. Each router in a MANET may use more than one communication channel.
In particular, between the same pair of routers, more than one In particular, between the same pair of routers, more than one
distinct communication channel may exist, each with different distinct communication channel may exist, each with different
properties. properties. This may, for example, be the case where MANET routers
are equipped with multiple distinct wireless interfaces, operating at
different frequencies.
For use by MANET routing protocols, as well as for establishing a For use by MANET routing protocols, as well as for establishing a
router's neighbors, a router may also need to determine whether each router's neighbors, a router may also need to determine whether each
communication channel with that neighbor is bidirectional. communication channel with that neighbor is bi-directional.
The set of neighbor routers of a given MANET router may be The set of neighbor routers of a given MANET router may be
continuously changing, often due to router mobility or a changing continuously changing, often due to router mobility or a changing
physical environment in which the MANET is located. There is physical environment in which the MANET is located. There is
typically no information from lower layers which would enable an IP typically no information from lower layers 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 can often take place on a short timescale, changes. Such changes can often take place on a short timescale,
such as of the order of seconds, requiring MANET routing protocols to such as of the order of seconds, requiring MANET routing protocols to
act rapidly to ensure suitable convergence properties. act rapidly to ensure suitable convergence properties.
MANET routing protocols, for example [RFC3626] and [RFC5449], often MANET routing protocols, for example [RFC3626] and [RFC5449], often
employ relay set reductions in order to conserve network capacity employ relay set reductions in order to conserve network capacity
when maintaining network-wide topological information, with when maintaining network-wide topological information, with
calculation of these reduced relay sets employing up to two hop calculation of these reduced relay sets employing up to two hop
information. information.
The neighborhood discovery protocol specified in this document The neighborhood discovery protocol specified in this document
provides continued tracking of neighborhood changes, link provides continued tracking of neighborhood changes, link bi-
bidirectionality, and local topological information up to two hops. directionality, and local topological information up to two hops.
Combined, this allows a MANET routing protocol access to information Combined, this allows a MANET routing protocol access to information
describing link establishment/disappearance, and provides the describing link establishment/disappearance, and provides the
necessary topological information for reduced relay set selection and necessary topological information for reduced relay set selection and
other purposes. other purposes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
All terms introduced in [RFC5444], including "packet", "message", All terms introduced in [RFC5444], including "packet", "message",
"Address Block", "TLV Block" and "TLV", are to be interpreted as "Address Block", "TLV Block", "TLV", "address", "address prefix", and
described there. "address object" are to be interpreted as described therein.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Network Address An address plus an associated prefix length. This
may be an address with an associated maximum prefix length, or an
address prefix including a prefix length.
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 Interface - A network device, configured and assigned one or more
addresses. addresses.
Address - An IPv4 or IPv6 address, as assigned to an interface. It
corresponds to an address as specified in [RFC5444], and may be
either an address or an address prefix. An address without a
prefix length is considered to have a prefix length equal to its
length (in bits).
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 link between two MANET interfaces exists if either can be Link - A link between two MANET interfaces exists if either can be
heard by the other. heard by the other.
skipping to change at page 8, line 45 skipping to change at page 8, line 42
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
otherwise. otherwise.
A overlaps B if A and B are network addresses, and the range of
network addresses represented by A, and the range of network
addresses represented by B both contain at least one common
network address. (This is only possible if one range is a sub-
range of the other.)
a := b is an assignment operator, whereby the left side (a) is a := b 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). network 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, network addresses, or unordered lists (they must be
same type). If c and d are unordered lists, then they are of the 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). If c and d are (in which case c contains d, and d contains c). If c and d are
addresses, they are considered equal only if their prefix lengths network addresses, they are considered equal only if both
are also equal. addresses and prefix lengths are 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 Is applicable to networks, especially wireless networks, in which o Is applicable to networks, especially wireless networks, in which
unknown neighbors can be reached by local broadcast or multicast unknown neighbors can be reached by local broadcast or multicast
packets. packets.
o Is designed to work in networks with a dynamic topology, and in o Is designed to work in networks with a dynamic topology, and in
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 associated network
and these may also be dynamically changing. addresses, and these may also be dynamically changing.
o Provides each router with current local topology information up to o Provides each router with current local topology information up to
two hops away, and makes this local topology information available two hops away, and makes this local topology information available
to MANET routing protocols in Information Bases. to MANET routing protocols in Information Bases.
o Uses the packet and message formats specified in [RFC5444]. This o Uses the packet and message formats specified in [RFC5444]. This
includes the definition of a HELLO Message Type, used for includes the definition of a HELLO Message Type, used for
signaling local topology information. signaling local topology information.
o Allows "external" and "internal" extensibility as enabled by o Allows "external" and "internal" extensibility as enabled by
skipping to change at page 10, line 12 skipping to change at page 10, line 15
o Is designed to work in a completely distributed manner, and does o Is designed to work in a completely distributed manner, and does
not depend on any central entity. not depend on any central entity.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The objective of this protocol is, for each router: The objective of this protocol is, for each router:
o To identify 1-hop neighbors and symmetric 1-hop neighbors of this o To identify 1-hop neighbors and symmetric 1-hop neighbors of this
router. router.
o To find the interface addresses of the router's symmetric 2-hop o To find the interface network addresses of the router's symmetric
neighbors. 2-hop neighbors.
o To record this information in Information Bases that can be used o To record this information in Information Bases and thus make this
by other protocols, which extend this neighborhood discovery information available to other protocols that use this
protocol. neighborhood discovery protocol.
o To be available for use by other protocols, which MAY extend the
information in these Information Bases, including adding new Sets
to Information Bases, new elements to protocol Tuples and new TLVs
to be included in outgoing HELLO messages and processed when in
incoming HELLO messages.
These objectives are achieved using local (1-hop) signaling that: These objectives are achieved using local (1-hop) signaling that:
o Advertises the presence of a router and its interface addresses. o Advertises the presence of a router and its interface network
addresses.
o Discovers links from neighboring routers. o Discovers links from neighboring routers.
o Performs bidirectionality checks on the discovered links. o Performs bi-directionality checks on the discovered links.
o Advertises discovered links, and whether each is symmetric, to its o Advertises discovered links, and whether each is symmetric, to its
1-hop neighbors, and hence discovers symmetric 2-hop neighbors. 1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
This specification defines, in turn: This specification defines, in turn:
o Parameters and constants used by the protocol. Parameters used by o Parameters and constants used by the protocol. Parameters used by
this protocol may, where appropriate, be specific to a given MANET this protocol may, where appropriate, be specific to a given MANET
interface, or to a MANET router. This protocol allows all interface, or to a MANET router. This protocol allows all
parameters to be changed dynamically, and to be set independently parameters to be changed dynamically, and to be set independently
skipping to change at page 11, line 8 skipping to change at page 11, line 19
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 o The response to other events, such as the expiration of
information in the Information Bases. 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.
interface:
o Is configured with one or more addresses. These addresses MUST be Each MANET interface:
unique at least within the router's 2-hop neighborhood.
o Is configured with one or more network addresses. All addresses
represented by these network addresses MUST be unique to this
router at least within its 2-hop neighborhood. All such addresses
MUST be unique to this MANET interface, except that an address can
be used by more than one MANET interface on the same router if
those MANET interfaces are "isolated" from each other (no MANET
interface on another router can hear or be heard by two MANET
interfaces using overlapping network addresses).
o Has a set of interface parameters, defining the behavior of this o Has a set of interface parameters, defining the behavior of this
MANET interface. Each MANET interface MAY be individually MANET interface. Each MANET interface MAY be individually
parameterized. parameterized.
o Has an Interface Information Base, recording information regarding o Has an Interface Information Base, recording information regarding
links to this MANET interface and symmetric 2-hop neighbors which links to this MANET interface and symmetric 2-hop neighbors which
can be reached through such links. can be reached through such links.
o Generates and processes HELLO messages. o Generates and processes HELLO messages.
In addition to a set of MANET interfaces as described above, each In addition to a set of MANET interfaces as described above, each
router has: router has:
o A Local Information Base, containing the addresses of the o A Local Information Base, containing the network addresses of the
interfaces (MANET and non-MANET) of this router. The contents of interfaces (MANET and non-MANET) of this router. The contents of
this Information Base are not changed by signaling. this Information Base are not changed by signaling.
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.
A router may have both MANET interfaces and non-MANET interfaces. A router may have both MANET interfaces and non-MANET interfaces.
Interfaces of both of these types are recorded in a router's Local Interfaces of both of these types are recorded in a router's Local
Information Base, which is used, but not updated, by the signaling of Information Base, which is used, but not updated, by the signaling of
this protocol. this protocol.
4.2. Information Base Overview 4.2. Information Base Overview
Each 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
skipping to change at page 12, line 5 skipping to change at page 12, line 24
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 offers access to this information. In particular, note that it is
not necessary to remove Tuples from Sets at the exact time indicated, not 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.
Information in the Local Information Base is defined locally, and Information in the Local Information Base is defined locally, and
included in HELLO messages. Information in the Interface Information included in HELLO messages. Information in the Interface Information
Base and the Neighbor Information Base is determined from received Base and the Neighbor Information Base is determined from received
HELLO messages; some of this information may also be included in HELLO messages; some of this information may also be included in
transmitted HELLO messages. Such information has a limited duration transmitted HELLO messages. Such information has a limited duration
in which it is considered valid, this is determined from the in which it is considered valid. This duration is determined from
VALIDITY_TIME TLV in the HELLO message in which the information is the VALIDITY_TIME TLV in the HELLO message in which the information
received, which in turn is set by the router which originated the is received, which in turn is set by the router that originated the
HELLO message, using its corresponding interface parameter HELLO message, using its corresponding interface parameter
H_HOLD_TIME. H_HOLD_TIME.
Appendix E illustrates the relationship between message reception, Appendix E illustrates the relationship between message reception,
included VALIDITY_TIME TLVs, and the duration for which information included VALIDITY_TIME TLVs, and the duration for which information
received in a HELLO message is considered valid. Appendix F received in a HELLO message is considered valid. Appendix F
illustrates some example two hop topologies and how they correspond illustrates some example two hop topologies and how they correspond
to information in the Information Bases. to information in the Information Bases.
4.2.1. Local Information Base 4.2.1. Local Information Base
Each router maintains a Local Information Base, which contains the Each router maintains a Local Information Base, which contains the
router's local configuration information, specifically: 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 represents an interface (MANET or non-MANET) of the each of which represents an interface (MANET or non-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. network 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 network addresses are to
included and identified as local interfaces. The Removed Interface be included and identified as local interfaces. The Removed
Address Set is used to avoid incorrectly recording a formerly used Interface Address Set is used to avoid incorrectly recording a
address as a symmetric 2-hop neighbor's address. formerly used network address as a symmetric 2-hop neighbor's network
address.
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 1-hop neighborhood and symmetric Information Base, which contains 1-hop neighborhood and symmetric
skipping to change at page 13, line 10 skipping to change at page 13, line 30
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 MANET interface and MANET interfaces of lost links between this MANET interface and MANET interfaces of
1-hop neighbors. The Link Set consists of Link Tuples, each of 1-hop neighbors. The Link Set consists of Link Tuples, each of
which contains information about a single link. Link quality which contains information about a single link. Link quality
information (see Section 14), when used, is recorded in Link information (see Section 14), when used, is recorded in Link
Tuples. Tuples.
o A 2-Hop Set, which records the existence of symmetric links o A 2-Hop Set, which records the existence of symmetric links
between symmetric 1-hop neighbors of this MANET interface and between symmetric 1-hop neighbors of this MANET interface and
other routers (symmetric 2-hop neighbors). The 2-Hop Set consists other routers (symmetric 2-hop neighbors). The 2-Hop Set consists
of 2-Hop Tuples, each of which records an address of a symmetric of 2-Hop Tuples, each of which records a network address of a
2-hop neighbor, and all addresses of the corresponding symmetric symmetric 2-hop neighbor, and all network addresses of the
1-hop neighbor. corresponding symmetric 1-hop neighbor.
The Link Set for a MANET interface is used for generating HELLO The Link Set for a MANET interface is used for generating HELLO
messages. Specifically, the Link Set information is included to both messages. Specifically, the Link Set information is included to both
allow other routers to identify symmetric links and to populate the allow other routers to identify symmetric links and to populate the
2-Hop Set. Recently lost links are recorded in the Link Set for a 2-Hop Set. Recently lost links are recorded in the Link Set for a
MANET interface so that they can be advertised in HELLO messages, MANET interface so that they can be advertised in HELLO messages,
accelerating their removal from relevant 1-hop neighbors' Link Sets. accelerating their removal from relevant 1-hop neighbors' Link Sets.
The Link Set for a MANET interface is itself updated on receiving a The Link Set for a MANET interface is itself updated on receiving a
HELLO message, including recording symmetric links as indicated HELLO message, including recording symmetric links as indicated
above. The 2-Hop Set for a MANET interface is updated as indicated above. The 2-Hop Set for a MANET interface is updated as indicated
above, and is not itself used in generating HELLO messages. above, and is not itself used in generating HELLO messages.
4.2.3. Neighbor Information Base 4.2.3. Neighbor Information Base
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 collected information about current and recently lost 1-hop
neighbors, specifically: neighbors, specifically:
o The Neighbor Set consists of Neighbor Tuples, each of which o The Neighbor Set consists of Neighbor Tuples, each of which
records all addresses of a single 1-hop neighbor. Neighbor Tuples records all network addresses of a single 1-hop neighbor.
are maintained as long as there are corresponding Link Tuples. Neighbor Tuples are maintained as long as there are corresponding
Link Tuples.
o The Lost Neighbor Set consists of Lost Neighbor Tuples, each of o The Lost Neighbor Set consists of Lost Neighbor Tuples, each of
which records an address of a recently lost symmetric 1-hop which records a network address of a recently lost symmetric 1-hop
neighbor. neighbor.
The Neighbor Set associates all addresses of each 1-hop neighbor. The Neighbor Set associates all network addresses of each 1-hop
These addresses may be included when generating a HELLO message, so neighbor. These network addresses may be included when generating a
that other symmetric 1-hop neighbors can record this information in a HELLO message, so that other symmetric 1-hop neighbors can record
2-Hop Set. The Neighbor Set can be updated on receiving a HELLO this information in a 2-Hop Set. The Neighbor Set can be updated on
message.
The Lost Neighbor Set is used to determine which addresses are to be
included in a HELLO message as being lost (of a recently symmetric
1-hop neighbor). The Lost Neighbor Set can itself be updated on
receiving a HELLO message. receiving a HELLO message.
The Lost Neighbor Set is used to determine which network addresses
are to be included in a HELLO message as being lost (of a recently
symmetric 1-hop neighbor). The Lost Neighbor Set can itself be
updated on receiving a HELLO message.
4.3. Signaling Overview 4.3. Signaling Overview
This protocol contains a signaling mechanism for maintaining the This protocol contains a signaling mechanism for maintaining the
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 MANET 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:
generated and transmitted; this allows recipients to identify that
MANET interface. Each HELLO message also reports the other o Identifies, as far as is required, the MANET interface for which
interfaces (MANET and non-MANET) of the router; this allows it is generated and transmitted; this allows recipients of that
recipients to associate a set of addresses with a single 1-hop HELLO message to identify that MANET interface from among those it
neighbor. Each HELLO message also includes 1-hop neighbor may hear.
information from the Information Bases; this allows detection of
local symmetric links, and symmetric 2-hop neighbors. o Reports the network addresses of other interfaces (MANET and non-
MANET) of the router; this allows recipients of that HELLO message
to associate a set of network addresses with a single 1-hop
neighbor.
o Includes 1-hop neighbor information from the Information Bases;
this allows detection of local symmetric links, and symmetric
2-hop neighbors.
HELLO message generation, and the validity of the information HELLO message generation, and the validity of the information
recorded as a consequence of processing a HELLO message, is affected recorded as a consequence of processing a HELLO message, is affected
by timers and validity information included in HELLO messages through by timers and validity information included in HELLO messages through
TLVs. The relationship between message timers and intervals is TLVs. The relationship between message timers and intervals is
illustrated in Appendix E. illustrated in Appendix E.
4.3.1. HELLO Message Generation 4.3.1. HELLO Message Generation
HELLO messages are generated by a router for each of its MANET HELLO messages are generated by a router for each of its MANET
skipping to change at page 15, line 13 skipping to change at page 15, line 42
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
The content of a HELLO message MUST satisfy the following: The content of a HELLO message MUST satisfy the following:
o A HELLO message MUST contain all of the addresses in the Local o A HELLO message MUST contain all of the network addresses in the
Interface Set of the router to which the MANET interface belongs. Local Interface Set of the router on which the HELLO message is
being generated. This includes:
* At least one network address of each MANET interface of the
router.
* Network addresses that include all source addresses of any IP
datagrams sent by the router on any MANET interface.
* All other network addresses of the router which are to be made
known to any other router for any reason.
o For each MANET interface, within every time interval equal to the o For each MANET interface, within every time interval equal to the
corresponding REFRESH_INTERVAL, the HELLO messages sent MUST corresponding REFRESH_INTERVAL, sent HELLO messages MUST
collectively include all of the relevant information in the collectively include all of the relevant information in the
corresponding Link Set and the Neighbor Information Base. Note corresponding Link Set and the Neighbor Information Base. Note
that when determining whether to include information in a HELLO that when determining whether to include information in a HELLO
message, the sender MUST consider all times up to the latest time message, the sender MUST consider all times up to the latest time
when it may send its next HELLO message on this MANET interface. when it may send its next HELLO message on this MANET interface.
o A HELLO message MUST include exactly one VALIDITY_TIME Message o A HELLO message MUST include exactly one VALIDITY_TIME Message
TLV, as specified in [RFC5497], that indicates the length of time TLV, as specified in [RFC5497], that indicates the length of time
for which the message content is to be considered valid, and is for which the message content is to be considered valid, and is
therefore to be included in the receiving router's Interface therefore to be included in the receiving router's Interface
skipping to change at page 15, line 39 skipping to change at page 16, line 31
o A periodically generated HELLO message SHOULD include exactly one o A periodically generated HELLO message SHOULD include exactly one
INTERVAL_TIME Message TLV, as specified in [RFC5497], that INTERVAL_TIME Message TLV, as specified in [RFC5497], that
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.
4.3.3. HELLO Message Processing 4.3.3. HELLO Message Processing
HELLO messages received by a router are used to update the Interface HELLO messages received by a router are used to update the Interface
Information Base for the MANET interface on which that HELLO message Information Base for the MANET interface over which that HELLO
is received and the Neighbor Information Base. Specifically: message was received, as well as the Neighbor Information Base of the
router. 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 The router ensures that there is a Link Tuple, with appropriate o The router ensures that there is a Link Tuple, with appropriate
status (heard or symmetric) and advertised duration, corresponding status (heard or symmetric) and advertised duration, corresponding
to the link between the MANET interfaces on which that HELLO to the link between the MANET interfaces on which that HELLO
message was sent and received. One or more Lost Neighbor Tuples message was sent and received. One or more Lost Neighbor Tuples
may be created if the HELLO message reports that the link was may be created if the HELLO message reports that the link was
lost. lost.
skipping to change at page 16, line 24 skipping to change at page 17, line 15
4.4. Link Quality 4.4. Link Quality
Some links in a MANET may be marginal, e.g., due to adverse wireless Some links in a MANET may be marginal, e.g., due to adverse wireless
propagation. In order to avoid using such marginal links, a link propagation. In order to avoid using such marginal links, a link
quality value is recorded in each Link Tuple. A MANET router quality value is recorded in each Link Tuple. A MANET router
considers links for which an insufficient link quality is recorded as considers links for which an insufficient link quality is recorded as
lost. Modifying the recorded link quality in a Link Tuple is lost. Modifying the recorded link quality in a Link Tuple is
OPTIONAL. If link quality is not to be modified it MUST be set to OPTIONAL. If link quality is not to be modified it MUST be set to
indicate an always usable quality link. indicate an always usable quality link.
Note that Link Quality is a "link admittance" mechanism, allowing a
router to determine that a given link is too unstable to even
consider for use. It is specifically not a link metric nor a
substitute for one.
Link quality information is only used locally and is not used in Link quality information is only used locally and is not used in
signaling. Routers may interoperate whether they are using the same, signaling. Routers may interoperate whether they are using the same,
different, or no, link quality information. Link quality information different, or no, link quality information. Link quality information
is thus not equivalent to a link metric. is thus not equivalent to a link metric.
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.
skipping to change at page 17, line 26 skipping to change at page 18, line 21
employ different interface parameter values, and MAY change their employ different interface parameter values, and MAY change their
interface parameter values dynamically, subject to the constraints interface parameter values dynamically, subject to the constraints
given in this section. A particular case is where all MANET given in this section. A particular case is where all MANET
interfaces on all MANET routers within a given MANET employ the same interfaces on all MANET routers within a given MANET employ the same
set of interface parameter values. set of interface parameter values.
5.3.1. Message Intervals 5.3.1. Message Intervals
HELLO messages serve two principal functions: HELLO messages serve two principal functions:
o To advertise this router's interface addresses to its 1-hop o To advertise network addresses of this router's interface to its
neighbors. The frequency of these advertisements is regulated by 1-hop neighbors. The frequency of these advertisements is
the interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL. regulated by 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.
Specifically, these parameters are as follows: Specifically, these parameters are as follows:
HELLO_INTERVAL - is the maximum time between the transmission of two HELLO_INTERVAL - is the maximum time between the transmission of two
successive HELLO messages on this MANET interface. If using successive HELLO messages on this MANET interface. If using
periodic transmission of HELLO messages, these SHOULD be at a periodic transmission of HELLO messages, these SHOULD be at a
separation of HELLO_INTERVAL, possibly modified by jitter as separation of HELLO_INTERVAL, possibly modified by jitter as
specified in [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,
a HELLO message of each 1-hop neighbor address and its status. In in a HELLO message on this MANET interface, of each 1-hop neighbor
all intervals of length REFRESH_INTERVAL, a router MUST include network address and its status. In all intervals of length
each 1-hop neighbor address and its status in at least one HELLO REFRESH_INTERVAL, a router MUST include each 1-hop neighbor
message on this MANET interface. (This may be in the same or in network address and its status in at least one HELLO message on
different HELLO messages.) 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
skipping to change at page 18, line 40 skipping to change at page 19, line 38
interface, the router SHOULD configure the same value of interface, the router SHOULD configure the same value of
HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO
messages may be sent. messages may be sent.
5.3.2. Information Validity Times 5.3.2. Information Validity Times
The following interface parameters manage the validity time of link The following interface parameters manage the validity time of link
information: information:
L_HOLD_TIME - is the period of advertisement, on this MANET L_HOLD_TIME - 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 network addresses as lost in
messages, allowing recipients of these HELLO messages to HELLO 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.
H_HOLD_TIME - is used as the Value in the VALIDITY_TIME Message TLV H_HOLD_TIME - is used as the Value in the VALIDITY_TIME Message TLV
included in all HELLO messages on this MANET interface. It is included in all HELLO messages on this MANET interface. It is
then used by each router receiving such a HELLO message to then used by each router receiving such a HELLO message to
indicate the validity of the information taken from that HELLO indicate the validity of the information taken from that HELLO
message and recorded in the receiving router's Information Bases. message and recorded in the receiving router's Information Bases.
skipping to change at page 20, line 21 skipping to change at page 21, line 21
The two router parameters defined by this specification are in the The two router parameters defined by this specification are in the
category of information validity time. category of information validity time.
5.4.1. Information Validity Time 5.4.1. Information Validity Time
The following router parameter manages the validity time of lost The following router parameter manages the validity time of lost
symmetric 1-hop neighbor information: symmetric 1-hop neighbor information:
N_HOLD_TIME - is used as the period during which former 1-hop N_HOLD_TIME - is used as the period during which former 1-hop
neighbor addresses are advertised as lost in HELLO messages, neighbor network addresses are advertised as lost in HELLO
allowing recipients of these HELLO messages to accelerate removal messages, allowing recipients of these HELLO messages to
of this information from their 2-Hop Sets. N_HOLD_TIME MAY be set accelerate removal of this information from their 2-Hop Sets.
to zero, if accelerated information removal is not required. N_HOLD_TIME MAY be set 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 network 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.5. Parameter Change Constraints 5.5. Parameter Change Constraints
If protocol parameters are changed dynamically, the constraints in If protocol parameters are changed dynamically, the constraints in
this section apply. this section apply.
HELLO_INTERVAL HELLO_INTERVAL
* 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. A number according to the previous, shorter, HELLO_INTERVAL. A number
of subsequent HELLO messages MAY be generated according to the of subsequent HELLO messages MAY be generated according to the
previous, shorter, HELLO_INTERVAL (but MUST include times previous, shorter, HELLO_INTERVAL (but MUST include times
according to current parameters). according to current parameters). This ensures that "promises"
as to timely transmission of a future HELLO message is kept
until these previous promises have expired.
* If the HELLO_INTERVAL for a MANET interface decreases, then the * If the HELLO_INTERVAL for a MANET interface decreases, then the
following HELLO messages on this MANET interface MUST be following HELLO messages on this MANET interface MUST be
generated according to this current, shorter, HELLO_INTERVAL. generated according to this current, shorter, HELLO_INTERVAL.
REFRESH_INTERVAL REFRESH_INTERVAL
* If the REFRESH_INTERVAL for a MANET interface increases, then * If the REFRESH_INTERVAL for a MANET interface increases, then
the content of subsequent HELLO messages must be organized such the content of subsequent HELLO messages must be organized such
that the specification of the old value of REFRESH_INTERVAL is that the specification of the old value of REFRESH_INTERVAL is
skipping to change at page 21, line 51 skipping to change at page 23, line 8
* 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.6. Constants 5.6. Constants
The constant C (time granularity) is used as specified in [RFC5497]. 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 of a
at least one address, and MAY have more than one address. router MUST be identified by at least one network address. Such
network addresses MAY be specific to that interface, or MAY in some
circumstances be used by more than one interface as specified below.
The Local Information Base is not modified by signaling. If a The Local Information Base is not modified by signaling. If a
router's interface configuration changes, then the Local Information router's interface configuration changes, then the Local Information
Base MUST reflect these changes. This MAY also result in signaling Base MUST reflect these changes. This MAY also result in signaling
to advertise these changes. to advertise these changes.
Interfaces and addresses MAY be excluded from the Local Information It is not necessary to include all addresses of an interface in the
Base, and hence from HELLO messages, if they are not to be used for Local Information Base, and hence in HELLO messages. However any
routing. address that may be the source address of an IP datagram sent from
that interface MUST be included (and at least one address MUST be
included). A protocol using this specification MAY add additional
requirements to these, e.g. that any address that may be the
destination address of an IP datagram is also included.
The addresses assigned to an interface are "owned" by the router, and
MUST NOT be used by any other router as an interface address. If an
address has a prefix length and represents a range of addresses, this
applies to all addresses in that range (i.e. such ranges MUST NOT
overlap).
The addresses assigned to different interfaces on the same router
MUST be distinct (hence network address ranges MUST NOT overlap)
except that:
o The same address MAY be assigned to any number of non-MANET
interfaces as well as to one (or more if the following condition
also applies) MANET interface.
o The same address MAY be assigned to two (or more if each pair
satisfies this condition) MANET interfaces if those two MANET
interfaces cannot communicate to, from, or one to and one from,
any other MANET interface of another router.
6.1. Local Interface Set 6.1. Local Interface Set
A router's Local Interface Set records its local interfaces. It A router's Local Interface Set records its local interfaces. It
consists of Local Interface Tuples, one per interface: consists of Local Interface Tuples, one per interface:
(I_local_iface_addr_list, I_manet) (I_local_iface_addr_list, I_manet)
where: where:
I_local_iface_addr_list is an unordered list of the addresses of I_local_iface_addr_list is an unordered list of the network
this interface. addresses of this interface.
I_manet is a boolean flag, describing if this interface is a MANET I_manet is a boolean flag, describing if this interface is a MANET
interface. interface.
Local Interface Tuples are removed from the Local Interface Set only Local Interface Tuples are removed from the Local Interface Set only
when the routers' interface configuration changes, subject to when the routers' interface configuration changes, subject to
Section 9, i.e. they are not subject to timer-based expiration. Section 9, i.e. they are not subject to timer-based expiration.
6.2. Removed Interface Address Set 6.2. Removed Interface Address Set
A router's Removed Interface Address Set records addresses which were A router's Removed Interface Address Set records network addresses
recently used as local interface addresses. If a router's interface which were recently used as local interface network addresses. If a
addresses are immutable then the Removed Interface Address Set is router's interface network addresses are immutable then the Removed
always empty and MAY be omitted. It consists of Removed Interface Interface Address Set is always empty and MAY be omitted. It
Address Tuples, one per address: consists of Removed Interface Address Tuples, one per network
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 network address of an
this router. interface of this router.
IR_time specifies when this Tuple expires and MUST be removed. IR_time specifies when this Tuple expires and MUST be removed.
7. Interface Information 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.
An address of a symmetric 2-hop neighbor can also be present as the A network address of a symmetric 2-hop neighbor can also be present
address of a 1-hop neighbor. This allows the router using this as the network address of a 1-hop neighbor. This allows the router
address to be immediately considered as a symmetric 2-hop neighbor if using this network address to be immediately considered as a
it fails to be a symmetric 1-hop neighbor. symmetric 2-hop neighbor if 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 current time is greater than or equal to that time. One such
element, present in most Tuples, indicates when expired that the element, present in most Tuples, indicates when expired that the
Tuple itself is considered expired and MUST be removed. Tuples which Tuple itself is considered expired and MUST be removed. Tuples which
do not have such a time element are removed at other times as do not have such a time element are removed at other times as
specified, for example a Neighbor Tuple is removed when all specified, for example a Neighbor Tuple is removed 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)
where: where:
L_neighbor_iface_addr_list is an unordered list of the addresses of L_neighbor_iface_addr_list is an unordered list of the network
the MANET interface of the 1-hop neighbor; addresses of the MANET interface of the 1-hop neighbor;
L_HEARD_time is the time until which the MANET interface of the L_HEARD_time is the time until which the MANET interface of the
1-hop neighbor would be considered heard if not considering link 1-hop neighbor would be considered heard if not considering link
quality; quality;
L_SYM_time is the time until which the link to the 1-hop neighbor L_SYM_time is the time until which the link to the 1-hop neighbor
would be considered symmetric if not considering link quality; would be considered symmetric if not considering link quality;
L_quality is a dimensionless number between 0 (inclusive) and 1 L_quality is a dimensionless number between 0 (inclusive) and 1
(inclusive) describing the quality of a link; a greater value of (inclusive) describing the quality of a link; a greater value of
skipping to change at page 24, line 15 skipping to change at page 25, line 41
L_pending is a boolean flag, describing if a link is considered L_pending is a boolean flag, describing if a link is considered
pending (i.e. a candidate, but not yet established, link); pending (i.e. a candidate, but not yet established, link);
L_lost is a boolean flag, describing if a link is considered lost L_lost is a boolean flag, describing if a link is considered lost
due to low link quality; due to low link quality;
L_time specifies when this Tuple expires and MUST be removed. L_time specifies when this Tuple expires and MUST be removed.
The status of the link, as obtained through HELLO message exchange The status of the link, as obtained through HELLO message exchange
and using link quality, is denoted L_status. L_status can take the and using link quality, is denoted L_status. L_status can take the
values PENDING, HEARD, SYMMETRIC and LOST. The values LOST, Values PENDING, HEARD, SYMMETRIC and LOST. The values LOST,
SYMMETRIC and HEARD are defined in Section 18.5. The value PENDING SYMMETRIC and HEARD are defined in Section 18.5. The Value PENDING
is never used in a HELLO message, it is only used locally by a is never used in a HELLO message, it is only used locally by a
router, and any value distinct from LOST, SYMMETRIC and HEARD may be router, and any Value distinct from LOST, SYMMETRIC and HEARD may be
used. used.
L_status is defined by: L_status is defined by:
1. If L_pending = true, then L_status := PENDING; 1. If L_pending = true, then L_status := PENDING;
2. otherwise, if L_lost = true, then L_status := LOST; 2. otherwise, if L_lost = true, then L_status := LOST;
3. otherwise, if L_SYM_time is not expired, then L_status := 3. otherwise, if L_SYM_time is not expired, then L_status :=
SYMMETRIC; SYMMETRIC;
4. otherwise, if L_HEARD_time is not expired, then L_status := 4. otherwise, if L_HEARD_time is not expired, then L_status :=
HEARD; HEARD;
5. otherwise, L_status := LOST. 5. otherwise, L_status := LOST.
skipping to change at page 24, line 37 skipping to change at page 26, line 16
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 addresses of symmetric 2-hop neighbors, A router's 2-Hop Set records network addresses of symmetric 2-hop
and the symmetric links to symmetric 1-hop neighbors through which neighbors, and the symmetric links to symmetric 1-hop neighbors
these symmetric 2-hop neighbors can be reached. It consists of 2-Hop through which these symmetric 2-hop neighbors can be reached. It
Tuples, each representing a single address of a symmetric 2-hop consists of 2-Hop Tuples, each representing a single network address
neighbor, and a single MANET interface of a symmetric 1-hop neighbor. of a symmetric 2-hop neighbor, and a single MANET interface of a
symmetric 1-hop neighbor.
(N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time) (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)
where: where:
N2_neighbor_iface_addr_list is an unordered list of the addresses of N2_neighbor_iface_addr_list is an unordered list of the network
the MANET interface of the symmetric 1-hop neighbor from which addresses of the MANET interface of the symmetric 1-hop neighbor
this information was received; from which this information was received;
N2_2hop_addr is an address of a symmetric 2-hop neighbor which has a N2_2hop_addr is a network address of a symmetric 2-hop neighbor
symmetric link (using any MANET interface) to the indicated which has a symmetric link (using any MANET interface) to the
symmetric 1-hop neighbor; indicated symmetric 1-hop neighbor;
N2_time specifies when this Tuple expires and MUST be removed. N2_time specifies when this Tuple expires and MUST be removed.
8. Neighbor Information Base 8. Neighbor Information Base
Each router maintains a Neighbor Information Base that records Each router maintains a Neighbor Information Base that records
information about addresses of current and recently symmetric 1-hop information about network addresses of current and recently symmetric
neighbors. 1-hop neighbors.
8.1. Neighbor Set 8.1. Neighbor Set
A router's Neighbor Set records all addresses of each 1-hop neighbor. A router's Neighbor Set records all network addresses of each 1-hop
It consists of Neighbor Tuples, each representing a single 1-hop neighbor. It consists of Neighbor Tuples, each representing a single
neighbor: 1-hop neighbor:
(N_neighbor_addr_list, N_symmetric) (N_neighbor_addr_list, N_symmetric)
where: where:
N_neighbor_addr_list is an unordered list of the addresses of a N_neighbor_addr_list is an unordered list of the network addresses
1-hop neighbor; of a 1-hop neighbor;
N_symmetric is a boolean flag, describing if this is a symmetric N_symmetric is a boolean flag, describing if this is a symmetric
1-hop neighbor. 1-hop neighbor.
Neighbor Tuples are removed from the Neighbor Set only when Neighbor Tuples are removed from the Neighbor Set only when
corresponding Link Tuples expire from the routers' Link Set, i.e. corresponding Link Tuples expire from the routers' Link Set, i.e.
Neighbor Tuples are not directly subject to timer-based expiration. Neighbor Tuples are not directly subject to timer-based expiration.
8.2. Lost Neighbor Set 8.2. Lost Neighbor Set
A router's Lost Neighbor Set records addresses of routers which A router's Lost Neighbor Set records network addresses of routers
recently were symmetric 1-hop neighbors, but are now advertised as which recently were symmetric 1-hop neighbors, but which are now
lost. It consists of Lost Neighbor Tuples, each representing a advertised as lost. It consists of Lost Neighbor Tuples, each
single such address: representing a single such network address:
(NL_neighbor_addr, NL_time) (NL_neighbor_addr, NL_time)
where: where:
NL_neighbor_addr is an address of a router which recently was a NL_neighbor_addr is a network address of a router which recently was
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 be updated in response to changes in
router's local interface configuration. The router MUST update its the router's local interface configuration. These may also change
Interface Information Base and Neighbor Information Base in response the the Interface Information Base and the Neighbor Information Base.
to such changes. If any changes in the Interface Information Base or If any changes to the latter Information Bases satisfy any of the
the Neighbor Information Base satisfy any of the conditions described conditions described in Section 13, then those changes must be
in Section 13, then those changes must be applied immediately, unless applied immediately, unless noted otherwise below.
noted otherwise.
A router MAY transmit HELLO messages in response to these changes. A router MAY transmit HELLO messages in response to these changes.
9.1. Adding an Interface 9.1. Adding an Interface
If an interface is added to the router then this is indicated by the If an interface is added to the router, then this is indicated by the
addition of a Local Interface Tuple to the Local Interface Set. If addition of a Local Interface Tuple to the Local Interface Set. If
the new interface is a MANET interface then an initially empty the new interface is a MANET interface, then an initially empty
Interface Information Base MUST be created for this new MANET Interface Information Base MUST be created for this new MANET
interface. The actions in Section 9.3 MUST be taken for each address interface. The actions in Section 9.3 MUST be taken for each network
of this added interface. A HELLO message MAY be sent on all MANET address of this added interface. A HELLO message MAY be sent on all
interfaces, it SHOULD be sent on the new interface if it is a MANET MANET interfaces, it SHOULD be sent on the new interface if it is a
interface. If using scheduled messages, then a message schedule MUST MANET interface. If using scheduled messages, then a message
be established on the new MANET interface. schedule MUST be established on the new MANET interface.
9.2. Removing an Interface 9.2. Removing an Interface
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.
2. For each address (henceforth removed address) in the 2. For each network address (henceforth removed address) in the
I_local_iface_addr_list of that Local Interface Tuple, create a I_local_iface_addr_list of that Local Interface Tuple, if that
Removed Interface Address Tuple with: network address is not in the I_local_iface_addr_list of any
other Local Interface Tuple, then 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.
3. Remove that Local Interface Tuple from the Local Interface Set. 3. Remove that Local Interface Tuple from the Local Interface Set.
4. If the interface to be removed is a MANET interface (i.e. with 4. If the interface to be removed is a MANET interface (i.e. with
I_manet = true) then: I_manet = true) then:
1. Remove the Interface Information Base for that MANET 1. Remove the Interface Information Base for that MANET
interface; interface;
2. All Neighbor Tuples for which none of the addresses in its 2. All Neighbor Tuples for which none of the network addresses
N_neighbor_addr_list are contained in any in its N_neighbor_addr_list are contained in any
L_neighbor_iface_addr_list in any remaining Link Set, are L_neighbor_iface_addr_list in any remaining Link Tuple, are
removed. removed.
If the removed interface is the last MANET interface of the router, If the removed interface is the last MANET interface of the router,
then there will be no remaining Interface Information Bases, and the then there will be no remaining Interface Information Bases, and the
router will 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 a Network Address to an Interface
If an address is added to an interface then this is indicated by the If a network address is added to an interface then this is indicated
addition of an address to the appropriate I_local_iface_addr_list. by the addition of a network address to the appropriate
The following changes MUST be made to the Information Bases: I_local_iface_addr_list. The following changes MUST be made to the
Information Bases:
1. The Neighbor Tuples, if any, whose N_neighbor_addr_list contains 1. Any Removed Interface Address Tuple whose IR_local_iface_addr is
the added address, are removed. the added network address is removed.
2. Any Link Tuples, in any Link Set, whose 2. Any Neighbor Tuples whose N_neighbor_addr_list contains the added
network address, are removed.
3. Any Link Tuples, in any Link Set, whose
L_neighbor_iface_addr_list contains: L_neighbor_iface_addr_list contains:
* the added address; OR * the added network address; OR
* any address in the N_neighbor_addr_list of any removed * any network address in the N_neighbor_addr_list of any removed
Neighbor Tuple Neighbor Tuple
are removed; apply Section 13.2, but not Section 13.3. are removed; apply Section 13.2, but not Section 13.3.
3. Any Lost Neighbor Tuples whose NL_neighbor_addr = the added 4. Any Lost Neighbor Tuples whose NL_neighbor_addr = the added
address, are removed. network address, are removed.
4. Any 2-Hop Tuples whose N2_2hop_addr = the added address, are 5. Any 2-Hop Tuples whose N2_2hop_addr = the added network address,
removed. are removed.
After adding the address and making these changes, a HELLO message After adding the network address and making these changes, a HELLO
MAY be sent on all MANET interfaces. message MAY be sent on all MANET interfaces.
These changes, other than to the appropriate I_local_iface_addr_list, These changes, other than to the appropriate I_local_iface_addr_list,
are made in order to maintain consistency of the Information Bases. are made in order to maintain consistency of the Information Bases.
Specifically, these changes remove any record of any use of this Specifically, these changes remove any record of any use of this
address by routers in the 1-hop neighborhood or in the symmetric network address by routers in the 1-hop neighborhood or in the
2-hop neighborhood of this router. symmetric 2-hop neighborhood of this router.
9.4. Removing an Address from an Interface 9.4. Removing a Network Address from an Interface
If an address (henceforth removed address) is removed from an If a network address (henceforth removed address) is removed from an
interface then: interface then:
1. Identify the Local Interface Tuple that corresponds to the 1. Identify the Local Interface Tuple that corresponds to the
address to be removed. removed address.
2. If this is the only address of that interface (the only address 2. If this is the only network address of that interface (the only
in the corresponding I_local_iface_addr_list) then remove that network address in the corresponding I_local_iface_addr_list)
interface as specified in Section 9.2. then remove that interface as specified in Section 9.2.
3. Otherwise: 3. Otherwise:
1. Remove the removed address from this I_local_iface_addr_list. 1. Remove the removed address from this I_local_iface_addr_list.
2. Create a Removed Interface Address Tuple with: 2. If the removed address is not in the I_local_iface_addr_list
of any other Local Interface Tuple, then 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.
After removing the address and making these changes, a HELLO message After removing the network address and making these changes, a HELLO
MAY be sent on all MANET interfaces. message MAY be sent on all MANET interfaces.
10. Packets and Messages 10. Packets and Messages
The packet and message format used by this protocol is defined in The packet and message format used by this protocol is defined in
[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.
o A HELLO message MAY use any combination of Message Header options o A HELLO message MAY use any combination of Message Header options
specified in [RFC5444]. specified in [RFC5444].
o HELLO messages MUST NOT be forwarded. o HELLO messages MUST NOT be forwarded, i.e. a <msg-hop-limit>, if
present, MUST have the value 1.
o HELLO messages MAY be included in multi-message packets as o HELLO messages MAY be included in multi-message packets as
specified in [RFC5444]. specified in [RFC5444].
o Received HELLO messages MUST be parsed in accordance with o Received HELLO messages MUST be parsed in accordance with
[RFC5444]. A HELLO message which is not in conformance with [RFC5444]. A HELLO message which is not in conformance with
[RFC5444] MUST be discarded. A HELLO message may also be [RFC5444] MUST be discarded without being processed. A HELLO
discarded for other reasons, see Section 12.1. message can also be discarded without being processed 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 [RFC5497]. These five TLV Types are two Message TLVs defined in [RFC5497]. These five TLV Types are
all defined only with Type Extension = 0. TLVs of other types, all defined only with Type Extension = 0. TLVs of other types,
and of these types but without Type Extension = 0, are ignored by and of these types but without Type Extension = 0, are ignored by
this protocol. All references in this specification to, for this protocol. All references in this specification to, for
example, an Address Block TLV with Type = LINK_STATUS, are to be example, an Address Block TLV with Type = LINK_STATUS, are to be
considered as referring to an Address Block TLV with Type = considered as referring to an Address Block TLV with Type =
LINK_STATUS and Type Extension = 0. LINK_STATUS and Type Extension = 0.
skipping to change at page 29, line 36 skipping to change at page 31, line 20
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 network 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 represented as address objects (see
all generated HELLO messages with the following exception. If the [RFC5444]), and included in the Address Blocks in all generated HELLO
MANET interface on which the HELLO message is to be sent has a single messages, with the following permitted exception:
address with maximum prefix length (i.e. /32 for IPv4, /128 for
IPv6), then that address MAY be omitted from being included in any o If the MANET interface on which the HELLO message is to be sent
Address Block, provided that this address is included as the sending has a single address with maximum prefix length (i.e. /32 for
address of the IP datagram in which the HELLO message is included. IPv4, /128 for IPv6), then that address MAY be omitted from being
All addresses of the router's interfaces included in an Address Block included in any Address Block, provided that this address is
MUST be associated with an Address Block TLV with Type = LOCAL_IF, as included as the sending address of the IP datagram in which the
defined in Table 1. HELLO message is included.
All network addresses of the router's interfaces included in any
Address Block(s) MUST be associated with an Address Block 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 network address is |
| | | associated with the MANET interface on which | | | | associated with the MANET interface on which |
| | | the message was sent (THIS_IF) or another | | | | the message was sent (THIS_IF) or another |
| | | interface of the sending router (OTHER_IF). | | | | interface of the sending router (OTHER_IF). |
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
Table 1: LOCAL_IF TLV definition Table 1: LOCAL_IF TLV definition
Address Blocks MAY contain current or recently lost 1-hop neighbors' Address Blocks MAY contain current or recently lost 1-hop neighbors'
addresses, each of which is associated with one or both Address Block network addresses, represented as address objects (see [RFC5444]),
TLVs as described in Table 2. each of which is associated with one or both Address Block 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 network address and to the |
| | | MANET interface over which the HELLO |
| | | message is transmitted (LOST, SYMMETRIC |
| | | or HEARD). | | | | or HEARD). |
| OTHER_NEIGHB | 1 octet | Specifies that the address is | | OTHER_NEIGHB | 1 octet | Specifies that the network address is |
| | | (SYMMETRIC) or was (LOST) of an | | | | (SYMMETRIC) or was (LOST) of a MANET |
| | | interface of a symmetric 1-hop neighbor | | | | interface of a symmetric 1-hop neighbor |
| | | of the router transmitting the HELLO | | | | of the router transmitting the HELLO |
| | | message. | | | | message. |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition
An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or
Value = LOST also performs the function of an Address Block TLV with Value = LOST also performs the function of an Address Block TLV with
Type = OTHER_NEIGHB and the same Value. The latter SHOULD NOT also Type = OTHER_NEIGHB and the same Value. Including the latter
be included associated with the same address. If an Address Block associated with the same address object is discouraged for efficiency
TLV with Type = LINK_STATUS and Value = SYMMETRIC is combined with an reasons. If an Address Block TLV with Type = LINK_STATUS and Value =
Address Block TLV with Type = OTHER_NEIGHB and Value = LOST SYMMETRIC is combined with an Address Block TLV with Type =
associated with the same address, then the latter MUST be ignored, OTHER_NEIGHB and Value = LOST associated with the same address
and SHOULD NOT be included. See Appendix A. object, 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 network addresses MAY be represented as address objects (see
associated with any of the Address Block TLVs specified in this [RFC5444] and included in Address Blocks, but MUST NOT be associated
specification. with any of the Address Block TLVs specified in this specification.
11. HELLO Message Generation 11. HELLO Message Generation
Each MANET interface MUST generate HELLO messages according to the Each MANET interface MUST generate HELLO messages according to the
specification in this section. HELLO messages are generated for each specification in this section. HELLO messages are generated for each
MANET interface independently. HELLO message generation and MANET interface independently. HELLO message generation and
scheduling MUST be according to the interface parameters for that scheduling MUST be according to the interface parameters for that
MANET interface, and MAY be independent for each MANET interface or, MANET interface, and MAY be independent for each MANET interface or,
interface parameters permitting, MANET interfaces MAY use the same interface parameters permitting, MANET interfaces MAY use the same
schedule. schedule.
skipping to change at page 31, line 26 skipping to change at page 33, line 9
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 network addresses in any I_local_iface_addr_list MUST be
included, represented as address objects (see [RFC5444]), except
that: that:
o If the interface on which the HELLO message is to be sent has a o If the interface on which the HELLO message is to be sent has a
single address with maximum prefix length (i.e. /32 for IPv4, /128 single address with maximum prefix length (i.e. /32 for IPv4, /128
for IPv6) then that address MAY be omitted, provided that this for IPv6) then that address MAY be omitted, provided that this
address is included as the sending address of the IP datagram in address is included as the sending address of the IP datagram in
which the HELLO message is included. which the HELLO message is included.
All such included addresses MUST be associated with an Address Block All such included address objects MUST be associated with an Address
TLV with Type := LOCAL_IF and Value according to the following: Block TLV with Type := LOCAL_IF and Value according to the following:
o If the address is an address of the sending MANET interface, then o If the address object represents a network address of the sending
Value := THIS_IF. MANET interface, then 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 If such a network address is included in more than one
included in any HELLO message, respecting the parameter I_local_iface_addr_list, then, for efficiency reasons, it is
REFRESH_INTERVAL for each association for that MANET interface: encouraged that the corresponding address object is associated with
only one Value using an Address Block TLV with Type := LOCAL_IF, this
MUST be Value := THIS_IF if the address object represents a network
address of the sending MANET interface.
o Addresses of MANET interfaces of 1-hop neighbors from the Link Set The following network addresses of current or former 1-hop neighbors
of the Interface Information Base for this MANET interface (i.e. MAY be represented as address objects (see [RFC5444]) and included in
from an L_neighbor_iface_addr_list), other than those from Link any HELLO message, respecting the parameter REFRESH_INTERVAL for each
Tuples with L_status = PENDING. association for that MANET interface, and according to the following:
o Other addresses of symmetric 1-hop neighbors from the Neighbor Set o Network addresses of MANET interfaces of 1-hop neighbors from the
of this router's Neighbor Information Base (i.e. from an Link Set of the Interface Information Base for this MANET
N_neighbor_addr_list). interface (i.e. from an L_neighbor_iface_addr_list), other than
those from Link Tuples with L_status = PENDING.
o Addresses of MANET interfaces of previously symmetric or heard o Other network addresses of symmetric 1-hop neighbors from the
1-hop neighbors connected on this MANET interface from the Link Neighbor Set of this router's Neighbor Information Base (i.e. from
Set of the Interface Information Base for this MANET interface an N_neighbor_addr_list).
(i.e. from an L_neighbor_iface_addr_list with L_status = LOST).
o Other addresses of previously symmetric 1-hop neighbors from the o Network addresses of MANET interfaces of previously symmetric or
Lost Neighbor Set of this router's Neighbor Information Base (i.e. heard 1-hop neighbors connected on this MANET interface from the
from an NL_neighbor_addr). Link Set of the Interface Information Base for this MANET
interface (i.e. from an L_neighbor_iface_addr_list with L_status =
LOST).
Each such address MUST be associated with one or more appropriate o Other network addresses of previously symmetric 1-hop neighbors
Address Block TLVs. Specifically: from the Lost Neighbor Set of this router's Neighbor Information
Base (i.e. from an NL_neighbor_addr).
1. For each address (henceforth linked address) which is contained Each such address object (see [RFC5444]) MUST be associated with one
in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set or more appropriate Address Block TLVs. Specifically:
for this MANET interface, for which L_status != PENDING, include
the linked address with an associated Address Block TLV with: 1. For each address object (henceforth linked address) which
represents a network address contained 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 the
linked address with an associated Address Block TLV with:
* Type := LINK_STATUS; AND * Type := LINK_STATUS; AND
* Value := L_status. * Value := L_status.
2. For each address (henceforth neighbor address) which is contained 2. For each address object (henceforth neighbor address) which
in an N_neighbor_addr_list in a Neighbor Tuple with N_symmetric = represents a network address contained in an N_neighbor_addr_list
true, and which has not already been included with an associated in a Neighbor Tuple with N_symmetric = true, and which has not
Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, already been included with an associated Address Block TLV with
include the neighbor address with an associated Address Block TLV Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor
with: network address with an associated Address Block TLV with:
* Type := OTHER_NEIGHB; AND * Type := OTHER_NEIGHB; AND
* Value := SYMMETRIC. * Value := SYMMETRIC.
3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth 3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth
lost address) has not already been included, include the lost lost address) has not already been represented as an address
address with an associated Address Block TLV with: object and included, include 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 to these Information Bases If any such network addresses have been added to these Information
since the last HELLO message was sent on this MANET interface, or if Bases since the last HELLO message was sent on this MANET interface,
their status (as indicated by these TLVs and the Values they or if their status (as indicated by these TLVs and the Values they
associate with that address) have changed since that address was last associate with that network address) have changed since that network
reported on this MANET interface, then that address, and the address was last reported on this MANET interface, then that network
indicated TLVs, MUST be included in the HELLO message. address, and the indicated TLVs, MUST be included in the HELLO
message.
If an address of a 1-hop neighbor is specified with more than one If the address object (see [RFC5444]) representing a network address
associated Address Block TLV, then these Address Block TLVs MAY be of a 1-hop neighbor is specified with more than one associated
independently included or excluded from each HELLO message. Each Address Block TLV, then these Address Block TLVs MAY be independently
such Address Block TLV MUST be included associated with that address included or excluded from each HELLO message. Each such Address
in a HELLO message sent on that MANET interface in every interval of Block TLV MUST be included associated with the address object
length equal to that MANET interface's parameter REFRESH_INTERVAL. representation of that network address in a HELLO message sent on
Address Block TLVs associated with the same address included in the that MANET interface in every interval of length equal to that MANET
same HELLO message MAY be applied to the same or different copies of interface's parameter REFRESH_INTERVAL. Address Block TLVs
that address. associated with the same address object included in the same HELLO
message MAY be applied to the same or different copies of that
address object.
11.2. HELLO Message Transmission 11.2. HELLO Message Transmission
HELLO messages are transmitted in the format specified by [RFC5444]. HELLO messages are transmitted in the format specified by [RFC5444].
11.2.1. HELLO Message Jitter 11.2.1. HELLO Message Jitter
HELLO messages MAY be sent using periodic message generation or HELLO messages MAY be sent using periodic message generation or
externally triggered message generation. If using data link and externally triggered message generation. If using data link and
physical layers which are subject to packet loss due to collisions, physical layers which are subject to packet loss due to collisions,
skipping to change at page 34, line 9 skipping to change at page 35, line 50
message is not sent within HELLO_MIN_INTERVAL of the previous HELLO message is not sent within HELLO_MIN_INTERVAL of the previous HELLO
message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
be reduced by jitter, with maximum reduction HP_MAXJITTER, as be reduced by jitter, with maximum reduction HP_MAXJITTER, as
described in [RFC5148]. In this case HP_MAXJITTER MUST NOT be described in [RFC5148]. In this case HP_MAXJITTER MUST NOT be
greater than HELLO_MIN_INTERVAL. greater than HELLO_MIN_INTERVAL.
12. HELLO Message Processing 12. HELLO Message Processing
On receiving a HELLO message, a router MUST first check if the On receiving a HELLO message, a router MUST first check if the
message is invalid for processing by this router, as defined in message is invalid for processing by this router, as defined in
Section 12.1. Otherwise the receiving router MUST update its Section 12.1 and, if so, discard the message without further
appropriate Interface Information Base and its Neighbor Information processing. Otherwise, for each received and valid HELLO message the
Base as specified in Section 12.3 to Section 12.6. These updates receiving router MUST update its appropriate Interface Information
MUST be performed in the order in which they are presented in this Base and its Neighbor Information Base as specified in Section 12.3
specification. If any changes satisfy any of the conditions to Section 12.6. These updates MUST be performed in the order in
described in Section 13 then the indicated consequences in that which they are presented in this specification. If any changes
section MUST be applied immediately, unless noted otherwise. satisfy any of the conditions described in Section 13 then the
indicated consequences in that 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
skipping to change at page 34, line 51 skipping to change at page 36, line 46
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. VALIDITY_TIME 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 =
INTERVAL_TIME in its Message TLV Block. 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 object (including different address objects
or different Address Blocks) is associated with more than one representing the same network address, in the same or different
Value by one or more Address Block TLV(s) with Type = LOCAL_IF. Address Blocks) is associated with more than one Value by one or
more Address Block TLV(s) with Type = LOCAL_IF.
o Any address (henceforth the local address) associated with an o Any address object (henceforth local address) associated with an
Address Block TLV with Type = LOCAL_IF is one of the receiving Address Block TLV with Type = LOCAL_IF represents one of the
router's current or recently used addresses (i.e. the local receiving router's current or recently used network addresses
address is contained in any I_local_iface_addr_list in the Local (i.e. local address overlaps any network address in any
Interface Set or the local address = any IR_local_iface_addr in I_local_iface_addr_list in the Local Interface Set or any
the Removed Interface Address Set). IR_local_iface_addr in 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 v with any single Value v such that v != LOST, v != SYMMETRIC, and v
!= HEARD. != HEARD.
o Any address (including different copies of an address, in the same
or different Address Blocks) is associated with more than one
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 object (including different copies of an address
or different Address Blocks) is associated with more than one object, in the same or different Address Blocks) is associated
Value by one or more Address Block TLVs with Type = OTHER_NEIGHB. with an Address Block TLV with Type = LOCAL_IF and with an Address
Block TLV with Type = LINK_STATUS.
o Any address object (including different copies of an address
object, in the same or different Address Blocks) is associated
with an Address Block TLV with Type = LOCAL_IF and with an Address
Block TLV with Type = OTHER_NEIGHB.
o Any address object (including different copies of an address
object, in the same or different Address Blocks) is associated
with more than one Value by one or more Address Block TLVs with
Type = LINK_STATUS.
o Any address object (including different copies of an address
object, in the same or different Address Blocks) is associated
with more than one Value by one or more Address Block TLVs with
Type = OTHER_NEIGHB.
A router MAY recognize additional reasons for identifying that a A router MAY recognize additional reasons for identifying that a
message is badly formed and therefore invalid for processing. message is badly formed and therefore invalid for processing, e.g. to
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.
An invalid message MUST be silently discarded, without updating the An invalid message MUST be silently discarded, without updating the
router's Information Bases. router's Information Bases.
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 [RFC5497]. VALIDITY_TIME of the HELLO message as specified in [RFC5497].
(Note that, as specified by Section 12.1, there must be exactly (Note that, as specified by Section 12.1, there must be exactly
one such Message TLV in the HELLO message.) All information in one such Message TLV in the HELLO message.) All information in
the HELLO message used by this specification has the same validity the HELLO message used by this specification has the 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 an unordered list of network addresses
the HELLO message with an associated Address Block TLV with Type = of the MANET interface over which the HELLO message was sent, i.e.
LOCAL_IF and Value = THIS_IF. If the Sending Address List is is an unordered list of the network addresses represented by
otherwise empty, then the Sending Address List contains a single address objects contained in the HELLO message with an associated
address (with maximum prefix length, i.e. /32 for IPv64, /128 for Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If
IPv6) equal to the sending address of the IP datagram in which the the Sending Address List is otherwise empty, then the Sending
HELLO message was included. Address List contains a single network address with maximum prefix
length (i.e. /32 for IPv64, /128 for IPv6) with address equal to
the sending address 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 an unordered list of all the network
addresses contained in the HELLO message with an associated addresses of all the interfaces of the router which generated the
Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF. HELLO message, i.e. is the Sending Address List, plus the network
addresses represented by address objects contained in the HELLO
message with an associated 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
the current time (e.g., current time - 1). preceding the current time (e.g., current time - 1).
o "Removed Address List" is a list of addresses created by this o "Removed Address List" is a list of network addresses created by
HELLO message processing which were formerly reported as local by this HELLO message processing which were formerly reported as
the router originating the HELLO message, but which are not local by the router originating the HELLO message, but which are
included in the Neighbor Address List. This list is initialized not included in the Neighbor Address List. This list is
as empty. initialized 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 network addresses which were formerly considered as
This list is initialized as empty. symmetric. This list is initialized as empty.
12.3. Updating the Neighbor Set 12.3. Updating the Neighbor Set
On receiving a HELLO message, the router MUST update its Neighbor Set On receiving a HELLO message, the router MUST update its Neighbor Set
and populate the Removed Address List and Lost Address List: and populate the Removed Address List and Lost Address List:
1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples) 1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples)
where: where N_neighbor_addr_list contains any network address which
overlaps with any network address in the Neighbor Address List.
* N_neighbor_addr_list contains at least one address in the
Neighbor Address List.
2. If there are no matching Neighbor Tuples, then: 2. If there are no matching Neighbor Tuples, then:
1. Create a new Neighbor Tuple with: 1. Create a new Neighbor Tuple with:
+ N_neighbor_addr_list := Neighbor Address List; + N_neighbor_addr_list := Neighbor Address List;
+ N_symmetric := false. + N_symmetric := false.
3. If there is one matching Neighbor Tuple, then: 3. If there is one matching Neighbor Tuple, then:
1. If the matching Neighbor Tuple's N_neighbor_addr_list != 1. If the matching Neighbor Tuple's N_neighbor_addr_list !=
Neighbor Address List, then: Neighbor Address List, then:
1. For each address (henceforth removed address) which is 1. For each network address (henceforth removed address)
contained in that N_neighbor_addr_list, but is not which is contained in that N_neighbor_addr_list, but is
contained in the Neighbor Address List: not contained in the Neighbor Address List:
1. Add the removed address to the Removed Address List. 1. Add removed address to the Removed Address List.
2. If N_symmetric = true, then add the removed address 2. If N_symmetric = true, then add removed address to
to the Lost Address List. the Lost Address List.
2. Update the matching Neighbor Tuple by: 2. Update the matching Neighbor Tuple by:
- N_neighbor_addr_list := Neighbor Address List. - N_neighbor_addr_list := Neighbor Address List.
4. If there are two or more matching Neighbor Tuples, then: 4. If there are two or more matching Neighbor Tuples, then:
1. For each address (henceforth removed address) which is 1. For each network address (henceforth removed address) which
contained in the N_neighbor_addr_list of any of the matching is contained in the N_neighbor_addr_list of any of the
Neighbor Tuples: matching Neighbor Tuples but is not contained in the Neighbor
Address List:
1. Add the removed address to the Removed Address List. 1. Add removed address to the Removed Address List.
2. If N_symmetric = true, then add the removed address to 2. If N_symmetric = true, then add removed address to the
the Lost Address List. Lost Address List.
2. Replace the matching Neighbor Tuples by a single Neighbor 2. Replace the matching Neighbor Tuples by a single Neighbor
Tuple with: Tuple with:
+ N_neighbor_addr_list := Neighbor Address List; + N_neighbor_addr_list := Neighbor Address List;
+ N_symmetric := false + N_symmetric := false
12.4. Updating the Lost Neighbor Set 12.4. Updating the Lost Neighbor Set
On receiving a HELLO message, a router MUST update its Lost Neighbor On receiving a HELLO message, a router MUST update its Lost Neighbor
Set: Set:
1. For each address (henceforth lost address) which is contained in 1. For each network address (henceforth lost address) which is
the Lost Address List, if no Lost Neighbor Tuple with contained in the Lost Address List, if no Lost Neighbor Tuple
NL_neighbor_addr = lost address exists, then add a Lost Neighbor with NL_neighbor_addr = lost address exists, then add a Lost
Tuple with: Neighbor Tuple with:
* NL_neighbor_addr := lost address; * NL_neighbor_addr := lost address;
* NL_time := current time + N_HOLD_TIME. * NL_time := current time + N_HOLD_TIME.
12.5. Updating the Link Set 12.5. Updating the Link Set
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 network addresses in the Removed Address List from the
L_neighbor_iface_addr_list of all Link Tuples. L_neighbor_iface_addr_list of all Link Tuples.
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now 2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now
empty; apply Section 13.2, but not Section 13.3. empty; apply Section 13.2, but not Section 13.3.
3. Find all Link Tuples (henceforth 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 network
the Sending Address List. addresses in 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:
* L_neighbor_iface_addr_list := empty; * L_neighbor_iface_addr_list := empty;
* L_HEARD_time := EXPIRED; * L_HEARD_time := EXPIRED;
skipping to change at page 38, line 31 skipping to change at page 41, line 4
* L_neighbor_iface_addr_list := empty; * L_neighbor_iface_addr_list := empty;
* L_HEARD_time := EXPIRED; * L_HEARD_time := EXPIRED;
* L_SYM_time := EXPIRED; * L_SYM_time := EXPIRED;
* L_quality := INITIAL_QUALITY; * L_quality := INITIAL_QUALITY;
* L_pending := INITIAL_PENDING; * L_pending := INITIAL_PENDING;
* L_lost := false; * L_lost := false;
* L_time := current time + validity time. * L_time := current time + validity time.
6. The matching Link Tuple, existing or new, is then modified as 6. The matching Link Tuple, existing or new, is then modified as
follows: follows:
1. If the router finds any address (henceforth receiving 1. If the router finds any network address (henceforth receiving
address) in the Receiving Address List in an Address Block in address) in the Receiving Address List in an Address Block in
the HELLO message, then the Link Tuple is modified as the HELLO message, then the Link Tuple is modified as
follows: follows:
1. If any receiving address in the HELLO message is 1. If any receiving address in the HELLO message is
associated with an Address Block TLV with Type = associated with an Address Block TLV with Type =
LINK_STATUS and with Value = HEARD or Value = SYMMETRIC LINK_STATUS and with Value = HEARD or Value = SYMMETRIC
then: then:
- L_SYM_time := current time + validity time. - L_SYM_time := current time + validity time.
2. Otherwise if any receiving address in the HELLO message 2. Otherwise if any receiving address in the HELLO message
is associated with an Address Block TLV with Type = is associated with an Address Block TLV with Type =
LINK_STATUS and Value = LOST then: LINK_STATUS and Value = LOST then:
1. if L_SYM_time has not expired, then: 1. if L_SYM_time has not expired, then:
1. L_SYM_time := EXPIRED. 1. L_SYM_time := EXPIRED.
2. if L_status = HEARD or L_status = SYMMETRIC, 2. if L_status = HEARD, then:
then:
* L_time := current time + L_HOLD_TIME. * L_time := current time + L_HOLD_TIME.
2. L_neighbor_iface_addr_list := Sending Address List. 2. L_neighbor_iface_addr_list := Sending Address List.
3. L_HEARD_time := max(current time + validity time, 3. L_HEARD_time := max(current time + validity time,
L_SYM_time). L_SYM_time).
4. If L_status = PENDING, then: 4. If L_status = PENDING, then:
skipping to change at page 39, line 36 skipping to change at page 42, line 10
5. Otherwise if L_status = HEARD or L_status = SYMMETRIC, then: 5. Otherwise 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).
12.6. Updating the 2-Hop Set 12.6. Updating the 2-Hop Set
On receiving a HELLO message a router MUST update its 2-Hop Set for On receiving a HELLO message a router MUST update its 2-Hop Set for
the MANET interface on which the HELLO message was received: the MANET interface on which the HELLO message was received:
1. Remove all addresses in the Removed Address List from the 1. Remove all network addresses in the Removed Address List from the
N2_neighbor_iface_addr_list of all 2-Hop Tuples. N2_neighbor_iface_addr_list of all 2-Hop Tuples.
2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending 2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending
Address List, has L_status = SYMMETRIC then: Address List, has L_status = SYMMETRIC then:
1. For each address (henceforth 2-hop address) in an Address 1. For each network address (henceforth 2-hop address) in an
Block of the HELLO message, where: Address Block of the HELLO message, where:
+ 2-hop address is not contained in the Neighbor Address + 2-hop address is not contained in the Neighbor Address
List; List;
+ 2-hop address is not contained in any + 2-hop address is not contained in any
I_local_iface_addr_list; AND I_local_iface_addr_list; AND
+ 2-hop address != any IR_local_iface_addr + 2-hop address != any IR_local_iface_addr
4. If 2-hop address has an associated Address Block TLV
perform the following processing:
1. If 2-hop address has an associated Address Block TLV
with: with:
- Type = LINK_STATUS and Value = SYMMETRIC; OR - Type = LINK_STATUS and Value = SYMMETRIC; OR
- Type = OTHER_NEIGHB and Value = SYMMETRIC, - Type = OTHER_NEIGHB and Value = SYMMETRIC,
then, if there is no 2-Hop Tuple such that: then, if there is no 2-Hop Tuple such that:
- 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 network addresses in the Sending Address List; AND
- N2_2hop_addr = 2-hop address. - N2_2hop_addr = 2-hop address.
then create a 2-Hop Neighbor Tuple with: then create a 2-Hop Neighbor Tuple with:
- N2_2hop_addr := 2-hop address. - N2_2hop_addr := 2-hop address.
This 2-Hop Tuple (existing or new) is then modified as This 2-Hop Tuple (existing or new) is then modified as
follows: follows:
skipping to change at page 40, line 26 skipping to change at page 43, line 4
- N2_2hop_addr = 2-hop address. - N2_2hop_addr = 2-hop address.
then create a 2-Hop Neighbor Tuple with: then create a 2-Hop Neighbor Tuple with:
- N2_2hop_addr := 2-hop address. - N2_2hop_addr := 2-hop address.
This 2-Hop Tuple (existing or new) is then modified as This 2-Hop Tuple (existing or new) is then modified as
follows: follows:
- 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 2. Otherwise if 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 = 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 network addresses in the Sending Address List; AND
- N2_2hop_addr = 2-hop address. - N2_2hop_addr = 2-hop address.
13. Other Information Base Changes 13. Other Information Base Changes
The Interface and Neighbor Information Bases MUST be changed when The Interface and Neighbor Information Bases MUST be changed when
certain events occur. These events may result from HELLO message certain events occur. These events may result from HELLO message
processing, or may be otherwise generated (e.g., expiry of timers or processing, or may be otherwise generated (e.g., expiry of timers or
link quality changes). link quality changes).
skipping to change at page 41, line 15 skipping to change at page 43, line 39
o A Link Tuple's L_status changes to SYMMETRIC. In this case, the o A Link Tuple's L_status changes to SYMMETRIC. In this case, the
actions specified in Section 13.1 are performed. actions specified in Section 13.1 are performed.
o A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple o A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple
is removed. In this case, the actions specified in Section 13.2 is removed. In this case, the actions specified in Section 13.2
are performed. are performed.
o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed. o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed.
In this case, the actions specified in Section 13.3 are performed. In this case, the actions specified in Section 13.3 are performed.
o Local interface address changes. In this case, the actions o Local interface network address changes. In this case, the
specified in Section 9 are performed. actions specified in Section 9 are performed.
o Link quality changes. In this case, the actions specified in o Link quality changes. In this case, the actions specified in
Section 14 are performed. 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 the actions specified in Section 13.2 MUST L_HEARD_time expires, then the actions specified in Section 13.2 MUST
be performed before the actions specified in Section 13.3 are be performed before the actions specified in Section 13.3 are
performed for that Link Tuple. performed for that Link Tuple.
A router MAY report updated information in response to any of these A router MAY report updated information in response to any of these
skipping to change at page 42, line 22 skipping to change at page 44, line 47
If for any Link Tuple with L_status = SYMMETRIC: If for any Link Tuple with L_status = SYMMETRIC:
o L_status changes to any other value; OR o L_status changes to any other value; OR
o the Link Tuple is removed; o the Link Tuple is removed;
then: then:
1. All 2-Hop Tuples for the same MANET interface with: 1. All 2-Hop Tuples for the same MANET interface with:
* N2_neighbor_iface_addr_list contains one or more addresses in * N2_neighbor_iface_addr_list contains one or more network
L_neighbor_iface_addr_list; addresses in L_neighbor_iface_addr_list;
are removed. are removed.
2. For the Neighbor Tuple whose N_neighbor_addr_list contains 2. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list: L_neighbor_iface_addr_list:
1. If there are no remaining Link Tuples for any MANET interface 1. If there are no remaining Link Tuples for any MANET interface
where: where:
+ L_neighbor_iface_addr_list is contained in + L_neighbor_iface_addr_list is contained in
N_neighbor_addr_list; AND N_neighbor_addr_list; AND
+ L_status = SYMMETRIC; + L_status = SYMMETRIC;
then modify the Neighbor Tuple by: then modify the Neighbor Tuple by:
1. N_symmetric := false. 1. N_symmetric := false.
2. For each address (henceforth neighbor address) in 2. For each network address (henceforth neighbor address) in
N_neighbor_addr_list, add a Lost Neighbor Tuple with: N_neighbor_addr_list, add a Lost Neighbor Tuple with:
- NL_neighbor_addr := neighbor address; - NL_neighbor_addr := neighbor address;
- NL_time := current time + N_HOLD_TIME. - NL_time := current time + N_HOLD_TIME.
13.3. Link Tuple Heard Timeout 13.3. Link Tuple Heard Timeout
If, for any Link Tuple: If, for any Link Tuple:
skipping to change at page 43, line 32 skipping to change at page 46, line 5
* 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.
As such, it is a "link admission" mechanism.
Link quality information for a link is generated (e.g., through Link quality information for a link is generated (e.g., through
access to signal to noise ratio, packet loss rate, or other access to signal to noise ratio, packet loss rate, or other
information from the link layer) and used only locally, i.e. is not information from the link layer) and used only locally, i.e. is not
included in signaling, and routers may interoperate whether they are included in signaling, and routers may interoperate whether they are
using the same, different, or no, link quality information. 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
skipping to change at page 47, line 21 skipping to change at page 49, line 46
o HT_MAXJITTER := HP_MAXJITTER o HT_MAXJITTER := HP_MAXJITTER
15.6. Constants 15.6. Constants
o C := 1/1024 second o C := 1/1024 second
16. Usage with Other Protocols 16. Usage with Other Protocols
Other protocols, such as MANET routing protocols, which use Other protocols, such as MANET routing protocols, which use
neighborhood discovery may need to interact with this protocol. This neighborhood discovery, may need to interact with this protocol.
protocol is designed to permit such interactions, in particular: This protocol is designed to permit such interactions, in particular:
o Through accessing, and possibly extending, the information in the o Through accessing, and possibly extending, the information in the
Local Information Base (Section 6), the Interface Information Base Local Information Base (Section 6), the Interface Information Base
(Section 7) and the Neighbor Information Base (Section 8). These (Section 7) and the Neighbor Information Base (Section 8). These
Information Bases record the interface configuration of the Information Bases record the interface configuration of the
router, as well as the local connectivity, up to two hops away. router, as well as the local connectivity, up to two hops away.
All updates to the elements specified in this document are subject All updates to the elements specified in this document are subject
to the constraints specified in Appendix B. to the constraints specified in Appendix B.
o Through accessing an outgoing HELLO message prior to it being o Through accessing an outgoing HELLO message prior to it being
skipping to change at page 48, line 10 skipping to change at page 50, line 35
completely processed by this protocol. This may, in particular, completely processed by this protocol. This may, in particular,
allow a protocol which has added information, such as relay allow a protocol which has added information, such as relay
selection information by way of inclusion of appropriate TLVs, selection information by way of inclusion of appropriate TLVs,
access to such information after appropriate updates have been access to such information after appropriate updates have been
recorded in the Information Bases in this protocol. recorded in the Information Bases in this protocol.
o Through requesting that a HELLO message be generated at a specific o Through requesting that a HELLO message be generated at a specific
time. In that case, HELLO message generation MUST still respect time. In that case, HELLO message generation MUST still respect
the constraints in Appendix B. the constraints in Appendix B.
Address objects in HELLO messages are processed according to their
associated Address Block TLVs. All such address objects are to be
processed according to this specification are associated with Address
Block TLVs with Type of LOCAL_IF, OTHER_NEIGHB or LINK_STATUS (and
type extension zero). Address objects not associated with an Address
Block TLV of any of these Types are therefore not processed by the
protocol described in this specification.
A protocol, such as a MANET routing protocol, interacting with this
protocol may need to add information to HELLO messages. This may be
in form of associating TLVs (of Type other than LOCAL_IF,
OTHER_NEIGHB or LINK_STATUS) to address objects already included by
this specification.
A protocol, such as a MANET routing protocol, interacting with this
protocol may also add information to HELLO messages by inserting
address objects not already included by this specification. Such
address objects are in the following called "inserted addresses".
These inserted addresses may added to Address Blocks already present
by virtue of the HELLO message generation in this specification, or
may appear in new Address Blocks. In both cases, the following MUST
be observed:
o An inserted address MUST NOT be associated with an Address Block
TLV of Type LOCAL_IF, OTHER_NEIGHB or LINK_STATUS. Consequently,
the processing in this specification will ignore such address
objects.
o Each inserted address MUST be associated with an Address Block
TLV, to be defined by the specification of the protocol inserting
the address object. In this way, all addresses present in a HELLO
message are associated with an Address Block TLV defining their
semantics.
Informally speaking, Address Block TLVs define the semantics of
address objects in an Address Block. If an address object in an
Address Block does not have any Address Block TLVs associated, that
address object has no semantics. Consequently, all protocols using
the protocol defined in this specification MUST respect the
following:
o An address object in an Address Block, which is not associated
with any Address Block TLV, MUST be silently ignored; the mere
presence of an address object without an associated Address Block
TLV in a HELLO message MUST NOT cause any processing.
Strict adherence to this enables unambiguous co-existence of future
"extensions" to HELLO messages.
In some cases, a protocol interacting with the protocol defined in
this specification, may need to recognize which HELLO messages to
process and which HELLO messages to discard. It is the
responsibility of that protocol to ensure that such messages are
suitably identifiable, e.g. through inclusion of a Message TLV or
through recognizing an administrative configuration (such as address
ranges). Note that such a protocol interacting with this protocol
MAY specify such interaction by recognizing an additional reason for
discarding a message. As suggested in Section 17 this might, for
example, be a security protocol discarding a message which does not
carry a Message TLV containing a cryptographic signature.
17. Security Considerations 17. Security Considerations
The objective of this protocol is to allow each router in the network The objective of this protocol is to allow each router in the network
to acquire information describing its 1-hop neighborhood and to acquire information describing its 1-hop neighborhood and
symmetric 2-hop neighborhood. This is acquired through HELLO message symmetric 2-hop neighborhood. This is acquired through HELLO message
exchange between neighboring routers. This information is made exchange between neighboring routers. This information is made
available through the Interface Information Bases and Neighbor available through the Interface Information Bases and Neighbor
Information Base, describing the router's 1-hop neighborhood and Information Base, describing the router's 1-hop neighborhood and
symmetric 2-hop neighborhood. symmetric 2-hop neighborhood.
skipping to change at page 48, line 31 skipping to change at page 52, line 21
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, transmits If a router for some reason, whether malice or malfunction, transmits
invalid HELLO messages, incorrect information may be recorded in invalid HELLO messages, incorrect information may be recorded in
other routers' Information Bases. This protocol specification does, other routers' Information Bases. This protocol specification does,
however, prevent inconsistent information from being included in the however, prevent inconsistent information from being included in the
Information Bases through the specified processing, which maintains Information Bases through the specified processing, which maintains
the constraints in Appendix B. The exact consequence of information the constraints in Appendix B. The exact consequence of information
inexactness depends on the use of these Information Bases, and should inexactness depends on the use of these Information Bases, and SHOULD
be reflected in the specification of protocols which use information therefore be reflected in the specification of protocols which use
provided by this neighborhood discovery protocol. information provided by this neighborhood discovery protocol.
This section, therefore, firstly outlines the ways in which correctly This section, therefore, firstly outlines the ways in which correctly
formed, but still invalid, HELLO messages may appear, in formed, but still invalid, HELLO messages may appear, in
Section 17.1. Section 17.1.
Injection of invalid HELLO messages into a network may be prevented Injection of invalid HELLO messages into a network may be prevented
by different means. If, for example, a network is deployed in a site by different means. If, for example, a network is deployed in a site
to which access is strictly regulated, in order that physical access to which access is strictly regulated, in order that physical access
and proximity to the network is prevented, then further security and proximity to the network is prevented, then further security
mechanisms to protect against malicious routers injecting invalid mechanisms to protect against malicious routers injecting invalid
skipping to change at page 49, line 29 skipping to change at page 53, line 19
Section 17.2, therefore, does not specify a single "one-size-fits- Section 17.2, therefore, does not specify a single "one-size-fits-
all" mechanism, but rather details how the security suggestions in all" mechanism, but rather details how the security suggestions in
[RFC5444] are considered for applicability within the context of this [RFC5444] are considered for applicability within the context of this
protocol, and with the purpose of aiding deployment-specific security protocol, and with the purpose of aiding deployment-specific security
mechanisms to be developed. mechanisms to be developed.
17.1. Invalid HELLO messages 17.1. Invalid HELLO messages
A correctly formed, but still invalid, HELLO message may take any of A correctly formed, but still invalid, HELLO message may take any of
the following forms. Note that a present or absent address in an the following forms. Note that a present or absent address object in
Address Block, does not in and by itself cause a problem. It is the an Address Block, does not by itself cause a problem. It is the
presence, absence, or incorrectness of associated LOCAL_IF, presence, absence, or incorrectness of associated LOCAL_IF,
LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems. LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems.
A router may provide false information about its own identity: A router may provide false information about its own identity:
* The HELLO message may contain addresses with an associated * The HELLO message may contain address objects with an
LOCAL_IF Address Block TLV which do not correspond to addresses associated LOCAL_IF Address Block TLV which do not correspond
of interfaces of the router transmitting the HELLO message. to addresses of interfaces of the router transmitting the HELLO
message.
* The HELLO message may omit addresses, or their associated * The HELLO message may omit network addresses, or their
LOCAL_IF Address Block TLV, of interfaces of the router associated LOCAL_IF Address Block TLV, of interfaces of the
transmitting the HELLO message (other than the allowed omission router transmitting the HELLO message (other than the allowed
of the only local interface address of the MANET interface over omission of the only local interface network address of the
which the HELLO message is transmitted, if that is the case). MANET interface over which the HELLO message is transmitted, if
that is the case).
* The HELLO message may incorrectly specify the LOCAL_IF Address * The HELLO message may incorrectly specify the LOCAL_IF Address
Block TLV Value associated with one or more local interface Block TLV Value associated with one or more local interface
addresses, indicating incorrectly whether they are associated network addresses, indicating incorrectly whether they are
with the MANET interface over which the HELLO message is associated with the MANET interface over which the HELLO
transmitted. message is transmitted.
A router may provide false information about the identity of other A router may provide false information about the identity of other
routers: routers:
* A present LINK_STATUS Address Block TLV may, incorrectly, * A present LINK_STATUS Address Block TLV may, incorrectly,
identify an address as being of a MANET interface which is or identify a network address as being of a MANET interface which
was heard on the MANET interface over which the HELLO message is or was heard on the MANET interface over which the HELLO
is transmitted. message is transmitted.
* A consistently absent LINK_STATUS Address Block TLV may, * A consistently absent LINK_STATUS Address Block TLV may,
incorrectly, fail to identify an address as being of a MANET incorrectly, fail to identify a network address as being of a
interface which is or was heard on the MANET interface over MANET interface which is or was heard on the MANET interface
which the HELLO message is transmitted. over which the HELLO message is transmitted.
* A present OTHER_NEIGHB Address Block TLV may, incorrectly, * A present OTHER_NEIGHB Address Block TLV may, incorrectly,
identify an address as being of a router which is or was in the identify a network address as being of a router which is or was
sending router's symmetric 1-hop neighborhood; in the sending router's symmetric 1-hop neighborhood;
* A consistently absent OTHER_NEIGHB Address Block TLV may, * A consistently absent OTHER_NEIGHB Address Block TLV may,
incorrectly, fail to identify an address as being of a router incorrectly, fail to identify a network address as being of a
which is or was in the sending router's symmetric 1-hop router which is or was in the sending router's symmetric 1-hop
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.
skipping to change at page 52, line 28 skipping to change at page 56, line 21
[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 18.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 network |
| | | | associated with a local interface | | | | | address is associated with a |
| | | | of the sending router | | | | | local interface of the sending |
| | | | router |
| Unassigned | TBD2 | 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 network |
| | | | (LOST, SYMMETRIC or HEARD) | | | | | address (LOST, SYMMETRIC or |
| | | | HEARD) |
| Unassigned | TBD3 | 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 network |
| | | | (SYMMETRIC) or recently was | | | | | address is (SYMMETRIC) or |
| | | | (LOST) of an interface of a | | | | | recently was (LOST) of an |
| | | | symmetric 1-hop neighbor of the | | | | | interface of a symmetric 1-hop |
| | | | router transmitting the message | | | | | neighbor of the router |
| | | | transmitting the message |
| Unassigned | TBD4 | 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
18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values 18.5. LOCAL_IF, 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:
skipping to change at page 55, line 13 skipping to change at page 59, line 15
[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
Networks", RFC 5449, February 2009. Networks", RFC 5449, February 2009.
Appendix A. Address Block TLV Combinations Appendix A. Address Block TLV Combinations
The algorithm for generating HELLO messages in Section 11 specifies The algorithm for generating HELLO messages in Section 11 specifies
which 1-hop addresses may be included in the Address Blocks, and with which 1-hop neighbor network addresses may be included in the Address
which associated Address Block TLVs. These Address Block TLVs may Blocks, and with which associated Address Block TLVs. These Address
have Type = LINK_STATUS or Type = OTHER_NEIGHB, or both. Address Block TLVs may have Type = LINK_STATUS or Type = OTHER_NEIGHB, or
Block TLVs with Type = LINK_STATUS may have three possible Values both. Address Block TLVs with Type = LINK_STATUS may have three
(Value = HEARD, Value = SYMMETRIC or Value = LOST), and Address Block possible Values (Value = HEARD, Value = SYMMETRIC or Value = LOST),
TLVs of TYPE = OTHER_NEIGHB may have two possible Values (Value = and Address Block TLVs of TYPE = OTHER_NEIGHB may have two possible
SYMMETRIC or Value = LOST). When both Address Block TLVs are Values (Value = SYMMETRIC or Value = LOST). When both Address Block
associated with the same address only certain combinations of these TLVs are associated with the same network address only certain
Address Block TLV Values are necessary, and are the only combinations combinations of these Address Block TLV Values are necessary, and are
generated by the algorithm in Section 11. These combinations are the only combinations generated by the algorithm in Section 11.
indicated in Table 9. These combinations are indicated in Table 9.
Cells labeled with "Yes" indicate the possible combinations which are Cells labeled with "Yes" indicate the possible combinations which are
generated by the algorithm in Section 11. Cells labeled with "No" generated by the algorithm in Section 11. Cells labeled with "No"
indicate combinations not generated by the algorithm in Section 11, indicate combinations not generated by the algorithm in Section 11,
but which are correctly parsed and interpreted by the algorithm in but which are correctly parsed and interpreted by the algorithm in
Section 12. The cell labeled with "No*" is actually inconsistent, it Section 12. The cell labeled with "No*" is actually inconsistent, it
is handled by ignoring the Address Block TLV with Type = is handled by ignoring the Address Block TLV with Type =
OTHER_NEIGHB. OTHER_NEIGHB, but SHOULD NOT be used.
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | Type = | Type = | Type = | | | Type = | Type = | Type = |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, | | | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value = | Value = LOST | | | (absent) | Value = | Value = LOST |
| | | SYMMETRIC | | | | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| Type = | No | Yes | Yes | | Type = | No | Yes | Yes |
| LINK_STATUS | | | | | LINK_STATUS | | | |
| (absent) | | | | | (absent) | | | |
skipping to change at page 56, line 38 skipping to change at page 60, line 38
Appendix B. Constraints Appendix B. Constraints
Any process which updates the Local Information Base or the Neighbor Any process which updates the Local Information Base or the Neighbor
Information Base MUST ensure that all constraints specified in this Information Base MUST ensure that all constraints specified in this
appendix are maintained. appendix are maintained.
In each Local Interface Tuple: In each Local Interface Tuple:
o I_local_iface_addr_list MUST NOT be empty. o I_local_iface_addr_list MUST NOT be empty.
o I_local_iface_addr_list MUST NOT contain any duplicated addresses. o I_local_iface_addr_list MUST NOT contain any duplicated network
addresses.
o I_local_iface_addr_list MUST NOT contain any address which is in o If I_manet = true, then I_local_iface_addr_list MUST NOT contain
the I_local_iface_addr_list of any other Local Interface Tuple. any network address which overlaps any network address in the
I_local_iface_addr_list of any other Local Interface Tuple with
I_manet = true, unless it is known that the corresponding MANET
interfaces will ALWAYS communicate with separate sets of MANET
interfaces on other routers.
In each Removed Interface Address Tuple: In each Removed Interface Address Tuple:
o IR_local_iface_addr MUST NOT contain any address which is in the o IR_local_iface_addr MUST NOT contain any network address which is
I_local_iface_addr_list of any Local Interface Tuple. in the I_local_iface_addr_list of any Local Interface Tuple.
o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
other Removed Interface Address Tuple. other Removed Interface Address Tuple.
In each Link Tuple: In each Link Tuple:
o L_neighbor_iface_addr_list MUST NOT be empty. o L_neighbor_iface_addr_list MUST NOT be empty.
o L_neighbor_iface_addr_list MUST NOT contain any address which is o L_neighbor_iface_addr_list MUST NOT contain any network address
in the I_local_iface_addr_list of any Local Interface Tuple or the which overlaps any network address in the I_local_iface_addr_list
IR_local_iface_addr of any Removed Interface Address Tuple. of any Local Interface Tuple or the IR_local_iface_addr of any
Removed Interface Address Tuple.
o L_neighbor_iface_addr_list MUST NOT contain any duplicated o L_neighbor_iface_addr_list MUST NOT contain any duplicated network
addresses. addresses.
o L_neighbor_iface_addr_list MUST NOT contain any address which is o L_neighbor_iface_addr_list MUST NOT contain any network address
in the L_neighbor_iface_addr_list of any other Link Tuple in the which is in the L_neighbor_iface_addr_list of any other Link Tuple
same Link Set. in the same Link Set.
o If L_HEARD_time has not expired then there MUST be a Neighbor o If L_HEARD_time has not expired then there MUST be a Neighbor
Tuple whose N_neighbor_addr_list contains Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list. L_neighbor_iface_addr_list.
o L_HEARD_time MUST NOT be greater than L_time. o L_HEARD_time MUST NOT be greater than L_time.
o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are
expired). expired).
o L_quality MUST NOT be less than 0 or greater than 1. o L_quality MUST NOT be less than 0 or greater than 1.
o If L_quality >= HYST_ACCEPT then L_pending MUST be false. o If L_quality >= HYST_ACCEPT then L_pending MUST be false.
o If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST. o If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST.
o L_pending MUST NOT be set to true if it is currently false. o L_pending MUST NOT be set to true if it is currently false.
In each Neighbor Tuple: In each Neighbor Tuple:
o N_neighbor_addr_list MUST NOT contain any address which is in the o N_neighbor_addr_list MUST NOT contain any network address which
I_local_iface_addr_list of any Local Interface Tuple or the overlaps any network address in the I_local_iface_addr_list of any
IR_local_iface_addr of any Removed Interface Address Tuple. Local Interface Tuple or the IR_local_iface_addr of any Removed
Interface Address Tuple.
o N_neighbor_addr_list MUST NOT contain any duplicated addresses. o N_neighbor_addr_list MUST NOT contain any duplicated network
addresses.
o N_neighbor_addr_list MUST NOT contain any address which is in the o N_neighbor_addr_list MUST NOT contain any network address which is
N_neighbor_addr_list of any other Neighbor Tuple. in the N_neighbor_addr_list of any other Neighbor Tuple.
o If N_symmetric is = true, then there MUST be one or more Link o If N_symmetric is = true, then there MUST be one or more Link
Tuples with: Tuples with:
* L_neighbor_iface_addr_list contained in N_neighbor_addr_list; * L_neighbor_iface_addr_list contained in N_neighbor_addr_list;
AND AND
* L_status = SYMMETRIC. * L_status = SYMMETRIC.
o If N_symmetric is = false, then there MUST be one or more Link o If N_symmetric is = false, then there MUST be one or more Link
Tuples with: Tuples with:
* L_neighbor_iface_addr_list contained in N_neighbor_addr_list. * L_neighbor_iface_addr_list contained in N_neighbor_addr_list.
All such Link Tuples MUST NOT have L_status = SYMMETRIC. At least All such Link Tuples MUST NOT have L_status = SYMMETRIC. At least
one such Link Tuple MUST have L_HEARD_time not expired. one such Link Tuple MUST have L_HEARD_time not expired.
In each Lost Neighbor Tuple: In each Lost Neighbor Tuple:
o NL_neighbor_addr MUST NOT be in the I_local_iface_addr_list of any o NL_neighbor_addr MUST NOT overlap any network address in the
Local Interface Tuple or the IR_local_iface_addr of any Removed I_local_iface_addr_list of any Local Interface Tuple or the
Interface Address Tuple. IR_local_iface_addr of any Removed Interface Address Tuple.
o NL_neighbor_addr MUST NOT equal the NL_neighbor_addr of any other o NL_neighbor_addr MUST NOT equal the NL_neighbor_addr of any other
Lost Neighbor Tuple. Lost Neighbor Tuple.
o NL_neighbor_addr MUST NOT be in the N_neighbor_addr_list of any o NL_neighbor_addr MUST NOT be in the N_neighbor_addr_list of any
Neighbor Tuple with N_symmetric = true. Neighbor Tuple with N_symmetric = true.
In each 2-Hop Tuple: In each 2-Hop Tuple:
o There MUST be a Link Tuple associated with the same MANET o There MUST be a Link Tuple associated with the same MANET
interface with: interface with:
* L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND * L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
* L_status = SYMMETRIC. * L_status = SYMMETRIC.
o N2_2hop_addr MUST NOT be in the I_local_iface_addr_list of any o N2_2hop_addr MUST NOT overlap any network address in the
Local Interface Tuple or the IR_local_iface_addr of any Removed I_local_iface_addr_list of any Local Interface Tuple or the
Interface Address Tuple. IR_local_iface_addr of any Removed Interface Address Tuple.
o N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple o N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple
in the same 2-Hop Set and with the same in the same 2-Hop Set and with the same
N2_neighbor_iface_addr_list. N2_neighbor_iface_addr_list.
o N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the o N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the
same 2-Hop Tuple. same 2-Hop Tuple.
Appendix C. HELLO Message Example Appendix C. HELLO Message Example
skipping to change at page 62, line 16 skipping to change at page 66, line 16
This informative appendix illustrates the relationship between This informative appendix illustrates the relationship between
message timers and intervals. (The adjustments to this timing when message timers and intervals. (The adjustments to this timing when
using timing jitter, as defined in [RFC5148], are not shown.) using timing jitter, as defined in [RFC5148], are not shown.)
E.1. HELLO Message Generation Timing E.1. HELLO Message Generation Timing
Figure 1 illustrates a basic HELLO message schedule for a router, on Figure 1 illustrates a basic HELLO message schedule for a router, on
a MANET interface, employing strictly periodic transmission of HELLO a MANET interface, employing strictly periodic transmission of HELLO
messages. The router transmits a HELLO message each HELLO_INTERVAL. messages. The router transmits a HELLO message each HELLO_INTERVAL.
Each HELLO message contains all neighbor addresses of the router that Each HELLO message contains all 1-hop neighbor network addresses of
are to be reported in any such HELLO message. (The parameter the router that are to be reported in any such HELLO message. (The
REFRESH_INTERVAL, not shown, is in this example equal to the parameter REFRESH_INTERVAL, not shown, is in this example equal to
parameter HELLO_INTERVAL.) the parameter HELLO_INTERVAL.)
The router includes a VALIDITY_TIME TLV in each HELLO message, The router includes a VALIDITY_TIME TLV in each HELLO message,
encoding the parameter H_HOLD_TIME, the duration for which encoding the parameter H_HOLD_TIME, the duration for which
information received in the HELLO message should be considered valid information received in the HELLO message should be considered valid
by receiving routers. Receiving routers will, when recording the by receiving routers. Receiving routers will, when recording the
information received in the HELLO message, each use this for setting information received in the HELLO message, each use this for setting
the L_HEARD_time, L_SYM_time and L_time elements of their the L_HEARD_time, L_SYM_time and L_time elements of their
corresponding Link Tuple, and the N2_time in the corresponding 2-Hop corresponding Link Tuple, and the N2_time in the corresponding 2-Hop
Tuple for each address. Only L_time is illustrated in Figure 1. Tuple for each network address. Only L_time is illustrated in
Figure 1.
H_HOLD_TIME: |-----------------------------| ... H_HOLD_TIME: |-----------------------------| ...
HELLO_INTERVAL: |---------|---------|---------| ... HELLO_INTERVAL: |---------|---------|---------| ...
Time: ---*---------*---------*---------*------> Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
HELLO (a, b, c, d) | | | HELLO (a, b, c, d) | | |
skipping to change at page 63, line 9 skipping to change at page 67, line 9
|-------------------- ... |-------------------- ...
|---------- ... |---------- ...
| ... | ...
Figure 1: HELLO message generation: regular schedule Figure 1: HELLO message generation: regular schedule
Figure 2 illustrates a message schedule similar to Figure 1, where Figure 2 illustrates a message schedule similar to Figure 1, where
the router announces its own presence more frequently by sending the router announces its own presence more frequently by sending
additional HELLO messages. HELLO messages are still sent regularly, additional HELLO messages. HELLO messages are still sent regularly,
at a reduced interval defined by a new value of HELLO_INTERVAL. at a reduced interval defined by a new value of HELLO_INTERVAL.
However REFRESH_INTERVAL has not been reduced. Each neighbor address However REFRESH_INTERVAL has not been reduced. Each 1-hop neighbor
included in these HELLO messages need be advertised only once within network address included in these HELLO messages need be advertised
each REFRESH_INTERVAL. Consequently the additional HELLO messages only once within each REFRESH_INTERVAL. Consequently the additional
due to the reduced value of HELLO_INTERVAL may therefore be empty. HELLO messages due to the reduced value of HELLO_INTERVAL may
(This is not the only allowed distribution of neighbor addresses, therefore be empty. (This is not the only allowed distribution of
they could, for example, be sent alternately a, b and c, d.) 1-hop neighbor network addresses, they could, for example, be sent
alternately a, b and c, d.)
H_HOLD_TIME: |-----------------------------| ... H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |---------|---------|---------| ... REFRESH_INTERVAL: |---------|---------|---------| ...
HELLO_INTERVAL: |----|----|----|----|----|----| ... HELLO_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------> Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
skipping to change at page 64, line 18 skipping to change at page 68, line 19
successive HELLO message transmissions is HELLO_INTERVAL, setting a successive HELLO message transmissions is HELLO_INTERVAL, setting a
lower bound on the message transmission rate. Hence, for each HELLO lower bound on the message transmission rate. Hence, for each HELLO
message transmission, the router must ensure that the next HELLO message transmission, the router must ensure that the next HELLO
message transmission must not wait more than HELLO_INTERVAL. message transmission must not wait more than HELLO_INTERVAL.
Figure 3 illustrates a message schedule similar to Figure 1, but with Figure 3 illustrates a message schedule similar to Figure 1, but with
HELLO messages responding to events at maximum rate, i.e. with HELLO HELLO messages responding to events at maximum rate, i.e. with HELLO
messages being sent each HELLO_MIN_INTERVAL. Note that when a HELLO messages being sent each HELLO_MIN_INTERVAL. Note that when a HELLO
message is sent, it is assumed that the following messages may all be message is sent, it is assumed that the following messages may all be
scheduled at an interval of HELLO_INTERVAL, and hence each HELLO scheduled at an interval of HELLO_INTERVAL, and hence each HELLO
message contains all neighbor addresses. In each HELLO message in message contains all 1-hop neighbor network addresses. In each HELLO
this example, a new neighbor address is added, reflecting the changes message in this example, a new 1-hop neighbor network address is
occuring since the last HELLO message was sent. HELLO messages are added, reflecting the changes occurring since the last HELLO message
sent at the maximum allowed rate in order to signal these changes as was sent. HELLO messages are sent at the maximum allowed rate in
rapidly as possible. order to signal these changes as rapidly as possible.
H_HOLD_TIME: |-----------------------------| ... H_HOLD_TIME: |-----------------------------| ...
HELLO_INTERVAL: |---------|---------|---------| ... HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ... HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------> Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
skipping to change at page 65, line 42 skipping to change at page 69, line 42
|--------------- ... |--------------- ...
|---------- ... |---------- ...
|----- ... |----- ...
| ... | ...
Figure 3: HELLO message generation: regular schedule with responsive Figure 3: HELLO message generation: regular schedule with responsive
messages messages
Figure 4 shows the same example as Figure 3, but with an increased Figure 4 shows the same example as Figure 3, but with an increased
REFRESH_INTERVAL, and showing partial HELLO messages which include REFRESH_INTERVAL, and showing partial HELLO messages which include
only the necessary addresses. only the necessary network addresses.
H_HOLD_TIME: |-----------------------------| ... H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |-------------------|---------- ... REFRESH_INTERVAL: |-------------------|---------- ...
|-------------------|----- ... |-------------------|----- ...
|-------------------| ... |-------------------| ...
|--------------- ... |--------------- ...
|---------- ... |---------- ...
|----- ... |----- ...
| ... | ...
skipping to change at page 68, line 8 skipping to change at page 72, line 8
| transmission | transmission
| |
Earliest time for next HELLO message Earliest time for next HELLO message
transmission transmission
Figure 5: HELLO message generation intervals Figure 5: HELLO message generation intervals
E.2. HELLO Message Processing Timing E.2. HELLO Message Processing Timing
Figure 6 illustrates the Link Set timers when receiving a HELLO Figure 6 illustrates the Link Set timers when receiving a HELLO
message not including the address of the receiving MANET interface. message not including the network address of the receiving MANET
interface.
VALIDITY_TIME: |--------------------------| VALIDITY_TIME: |--------------------------|
L_time: |--------------------------| L_time: |--------------------------|
L_HEARD_time: |--------------------------| L_HEARD_time: |--------------------------|
L_SYM_time: *-| (i.e. expired) L_SYM_time: *-| (i.e. expired)
Time: ---*--------------------------------> Time: ---*-------------------------------->
^ ^
| |
HELLO () received HELLO () received
Figure 6: HELLO message processing: address not present Figure 6: HELLO message processing: network address not present
Figure 7 illustrates the Link Set timers when, following the received Figure 7 illustrates the Link Set timers when, following the received
HELLO message illustrated in Figure 6, a router receives a HELLO HELLO message illustrated in Figure 6, a router receives a HELLO
message including the address (a) of the receiving interface with message including the network address (a) of the receiving interface
link status = HEARD (or SYM). with link status = HEARD (or SYM).
VALIDITY_TIME: |--------------------------| VALIDITY_TIME: |--------------------------|
|--------------------------| |--------------------------|
L_time: |--------------------------| L_time: |--------------------------|
|--------------------------| |--------------------------|
L_HEARD_time: |--------------------------| L_HEARD_time: |--------------------------|
|--------------------------| |--------------------------|
L_SYM_time: *-| (i.e. expired) L_SYM_time: *-| (i.e. expired)
L_SYM_time: |--------------------------| L_SYM_time: |--------------------------|
Time: -*-----*---------------------------------> Time: -*-----*--------------------------------->
^ ^ ^ ^
| | | |
HELLO () received | HELLO () received |
| |
HELLO (a:HEARD) received HELLO (a:HEARD) received
Figure 7: HELLO message processing: address present Figure 7: HELLO message processing: network address present
Figure 8 illustrates the Link Set timers when, following the received Figure 8 illustrates the Link Set timers when, following the received
HELLO messages illustrated in Figure 7, a router receives a HELLO HELLO messages illustrated in Figure 7, a router receives a HELLO
message including the address (a) of the receiving interface with message including the network address (a) of the receiving interface
link status = LOST. with link status = LOST.
VALIDITY_TIME: |--------------------------| VALIDITY_TIME: |--------------------------|
|--------------------------| |--------------------------|
|--------------------------| |--------------------------|
L_time: |--------------------------| L_time: |--------------------------|
|--------------------------| |--------------------------|
|--------------------------| |--------------------------|
L_HEARD_time: |--------------------------| L_HEARD_time: |--------------------------|
skipping to change at page 69, line 32 skipping to change at page 73, line 33
Time: -*-----*-----*---------------------------------> Time: -*-----*-----*--------------------------------->
^ ^ ^ ^ ^ ^
| | | | | |
HELLO () received | | HELLO () received | |
| | | |
HELLO (a:HEARD) received | HELLO (a:HEARD) received |
| |
HELLO (a:LOST) received HELLO (a:LOST) received
Figure 8: HELLO message processing: address lost Figure 8: HELLO message processing: network address lost
E.3. Other HELLO Message Timing E.3. Other HELLO Message Timing
There are three other timing parameters which are used by a router to There are three other timing parameters which are used by a router to
control HELLO message generation and processing. control HELLO message generation and processing.
Figure 9 illustrates the time, with duration L_HOLD_TIME, during Figure 9 illustrates the time, with duration L_HOLD_TIME, during
which the appropriate addresses of a formerly, but no longer, which the appropriate network addresses of a formerly, but no longer,
symmetric 1-hop neighbor, as connected by this MANET interface, are symmetric 1-hop neighbor, as connected by this MANET interface, are
advertised as LOST using a LINK_STATUS TLV in HELLO messages on this advertised as LOST using a LINK_STATUS TLV in HELLO messages on this
MANET interface, thus allowing that 1-hop neighbor to update its Link MANET interface, thus allowing that 1-hop neighbor to update its Link
Set accordingly. Set accordingly.
L_HOLD_TIME: |----------------------------| L_HOLD_TIME: |----------------------------|
Time: ---*----------------------------------> Time: ---*---------------------------------->
^ ^ ^ ^
| | | |
Formerly symmetric 1-hop neighbor | Formerly symmetric 1-hop neighbor |
ceases to be symmetric on this | ceases to be symmetric on this |
MANET interface | MANET interface |
| |
Time until which addresses of this Time until which network addresses of
neighbor connected using this MANET this neighbor connected using this MANET
interface are advertised in HELLO interface are advertised in HELLO
messages on this MANET interface messages on this MANET interface
using a LINK_STATUS TLV, Value = LOST using a LINK_STATUS TLV, Value = LOST
Figure 9: HELLO message generation: advertisement of formerly Figure 9: HELLO message generation: advertisement of formerly
symmetric 1-hop neighbor on this MANET interface as lost symmetric 1-hop neighbor on this MANET interface as lost
Figure 10 illustrates the time, with duration N_HOLD_TIME, during Figure 10 illustrates the time, with duration N_HOLD_TIME, during
which all addresses of a formerly, but no longer, symmetric 1-hop which all network addresses of a formerly, but no longer, symmetric
neighbor, are advertised as LOST in HELLO messages on all MANET 1-hop neighbor, are advertised as LOST in HELLO messages on all MANET
interfaces using an OTHER_NEIGHB TLV (if not also reported using a interfaces using an OTHER_NEIGHB TLV (if not also reported using a
LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to
update their 2-Hop Sets accordingly. update their 2-Hop Sets accordingly.
L_HOLD_TIME: |----------------------------| L_HOLD_TIME: |----------------------------|
Time: ---*----------------------------------> Time: ---*---------------------------------->
^ ^ ^ ^
| | | |
Formerly symmetric 1-hop neighbor | Formerly symmetric 1-hop neighbor |
ceases to be symmetric | ceases to be symmetric |
| |
Time until which addresses of this Time until which network addresses of
neighbor are advertised in HELLO this neighbor are advertised in HELLO
messages on all MANET interfaces messages on all MANET interfaces
using an OTHER_NEIGHB TLV, using an OTHER_NEIGHB TLV,
Value = LOST Value = LOST
Figure 10: HELLO message generation: advertisement of formerly Figure 10: HELLO message generation: advertisement of formerly
symmetric 1-hop neighbor on any MANET interface as lost symmetric 1-hop neighbor on any MANET interface as lost
Figure 11 illustrates the time, with duration I_HOLD_TIME, during Figure 11 illustrates the time, with duration I_HOLD_TIME, during
which a formerly, but no longer, used local interface address is which a formerly, but no longer, used local interface network address
excluded from being considered as a 2-hop neighbor address (in order is excluded from being considered as a 2-hop neighbor network address
that a router is not recorded as its own 2-hop neighbor during that (in order that a router is not recorded as its own 2-hop neighbor
period). during that period).
I_HOLD_TIME: |----------------------------| I_HOLD_TIME: |----------------------------|
Time: ---*-----------------------------------> Time: ---*----------------------------------->
^ ^ ^ ^
| | | |
Formerly used local interface | Formerly used local interface |
address ceases to be assigned | network address ceases to be |
to a local interface | assigned to a local interface |
| |
Time until which this address Time until which this network
is excluded from being included address is excluded from being
in this router's 2-Hop Set included in this router's 2-Hop Set
Figure 11: Local interface removed address Figure 11: Local interface removed network address
Appendix F. Topology Pictures Appendix F. Topology Pictures
This appendix illustrates various examples of physical topologies, as This appendix illustrates various examples of physical topologies, as
well as how these are logically recorded by NHDP from the point of well as how these are logically recorded by NHDP from the point of
view of the router A. This representation is a composite of view of the router A. This representation is a composite of
information which would be contained within A's various Information information which would be contained within A's various Information
Bases after NHDP has been running for sufficiently long time for the Bases after NHDP has been running for sufficiently long time for the
state to converge. state to converge.
 End of changes. 196 change blocks. 
563 lines changed or deleted 775 lines changed or added

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