draft-ietf-manet-nhdp-12.txt   draft-ietf-manet-nhdp-13.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: September 24, 2010 BAE Systems ATC Expires: January 13, 2011 BAE Systems ATC
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
March 23, 2010 July 12, 2010
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-12 draft-ietf-manet-nhdp-13
Abstract Abstract
This document describes a 1-hop and symmetric 2-hop neighborhood This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs). discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 2, line 36 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . 13 4.2.2. Interface Information Bases . . . . . . . . . . . . . 13
4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 13 4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 14
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 15 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 15
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 15 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 15
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 17 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 17
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 18 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 18
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 18 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 18
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 18 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 18
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 18 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 18
5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 18 5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 19
5.3.2. Information Validity Times . . . . . . . . . . . . . . 20 5.3.2. Information Validity Times . . . . . . . . . . . . . . 21
5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 20 5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 21
5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 21 5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 22
5.4.1. Information Validity Time . . . . . . . . . . . . . . 21 5.4.1. Information Validity Time . . . . . . . . . . . . . . 22
5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 23
5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 22 5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 24
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 24
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 23 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 25
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 24 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 25
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 24 7. Interface Information Bases . . . . . . . . . . . . . . . . . 26
7. Interface Information Bases . . . . . . . . . . . . . . . . . 25 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 28
8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 27 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 28
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 27 9. Local Information Base Changes . . . . . . . . . . . . . . . . 29
9. Local Information Base Changes . . . . . . . . . . . . . . . . 28 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 29
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 28 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 29
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 28 9.3. Adding a Network Address to an Interface . . . . . . . . . 30
9.3. Adding a Network Address to an Interface . . . . . . . . . 29 9.4. Removing a Network Address from an Interface . . . . . . . 31
9.4. Removing a Network Address from an Interface . . . . . . . 30 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 30 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 32
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 31
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 32 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 32
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 33 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 34
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 34 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 34
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 36 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 37
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 36 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 37
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 37 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 37
12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 37 12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 38
12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 39 12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 39
12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 40 12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 40
12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 41 12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 41
12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 41 12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 42
12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 43 12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 43
13. Other Information Base Changes . . . . . . . . . . . . . . . . 44 13. Other Information Base Changes . . . . . . . . . . . . . . . . 45
13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 45 13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 46
13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 45 13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 46
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 46 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 47
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 47 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 47 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 48
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 47 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 48
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 48 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 49
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 49 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 50
15. Proposed Values for Parameters and Constants . . . . . . . . . 49 15. Proposed Values for Parameters and Constants . . . . . . . . . 50
15.1. Message Interval Interface Parameters . . . . . . . . . . 50 15.1. Message Interval Interface Parameters . . . . . . . . . . 50
15.2. Information Validity Time Interface Parameters . . . . . . 50 15.2. Information Validity Time Interface Parameters . . . . . . 51
15.3. Information Validity Time Router Parameters . . . . . . . 50 15.3. Information Validity Time Router Parameters . . . . . . . 51
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 50 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 51
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 50 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 51
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 50 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 51
16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 50 16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 51
17. Security Considerations . . . . . . . . . . . . . . . . . . . 53 17. Security Considerations . . . . . . . . . . . . . . . . . . . 54
17.1. Invalid HELLO Messages . . . . . . . . . . . . . . . . . . 54 17.1. Invalid HELLO Messages . . . . . . . . . . . . . . . . . . 55
17.2. Authentication, Integrity and Confidentiality 17.2. Authentication, Integrity and Confidentiality
Suggestions . . . . . . . . . . . . . . . . . . . . . . . 55 Suggestions . . . . . . . . . . . . . . . . . . . . . . . 56
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 56 18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 57
18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 56 18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 57
18.3. Message-Type-Specific TLV Type Registries . . . . . . . . 56 18.3. Message-Type-Specific TLV Type Registries . . . . . . . . 57
18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 57 18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 58
18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 58 18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 59
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 59 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 60
20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
21.1. Normative References . . . . . . . . . . . . . . . . . . . 60 21.1. Normative References . . . . . . . . . . . . . . . . . . . 61
21.2. Informative References . . . . . . . . . . . . . . . . . . 60 21.2. Informative References . . . . . . . . . . . . . . . . . . 61
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 60 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 61
Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 61 Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 62
Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 64 Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 65
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 66 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 67
Appendix E. Interval and Timer Illustrations . . . . . . . . . . 67 Appendix E. Interval and Timer Illustrations . . . . . . . . . . 68
E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 67 E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 68
E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 73 E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 74
E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 74 E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 75
Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 76 Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 77
F.1. Example 1: Standard Single Interface Topology . . . . . . 76 F.1. Example 1: Standard Single Interface Topology . . . . . . 77
F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor . . 77 F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor . . 78
F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor . . 78 F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor . . 79
F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 78 F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 79
F.5. Example 5: Dual Interface on 2-Hop Neighbor . . . . . . . 79 F.5. Example 5: Dual Interface on 2-Hop Neighbor . . . . . . . 80
F.6. Example 6: Dual interface on 1-Hop Neighbor . . . . . . . 79 F.6. Example 6: Dual interface on 1-Hop Neighbor . . . . . . . 80
F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors . . 80 F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors . . 81
F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor . 81 F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor . 82
F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 81 F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 82
F.10. Example 10: Dual Addressed Dual Interfaces on All F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers . . . . . . . . . . . . . . . . . . . . . . . . . 82 Routers . . . . . . . . . . . . . . . . . . . . . . . . . 83
F.11. Example 11: Single Addressed Dual Interface Locally . . . 83 F.11. Example 11: Single Addressed Dual Interface Locally . . . 84
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].
1-hop neighborhood information is recorded for use by MANET routing
protocols to determine direct (1-hop) connectivity to neighboring
routers. 2-hop symmetric neighborhood information is recorded so as
to enable MANET routing protocols to employ flooding reduction
techniques, e.g., to select reduced relay sets for use for network
wide link state advertisements.
1-hop and symmetric 2-hop neighborhood information is recorded in the 1-hop and symmetric 2-hop neighborhood information is recorded in the
form of Information Bases. These are available for use by other form of Information Bases. These are available for use by other
protocols, such as MANET routing protocols, which require information protocols, such as MANET routing protocols, which require information
regarding the local network connectivity. This protocol is designed regarding the local network connectivity. This protocol is designed
to maintain the information in these Information Bases even in the to maintain the information in these Information Bases even in the
presence of a dynamic network topology and wireless communication presence of a dynamic network topology and wireless communication
channel characteristics. channel characteristics.
This protocol makes no assumptions about the underlying link layer, This protocol makes no assumptions about the underlying link layer,
other than support of local broadcast or multicast for communication other than support of local broadcast or multicast for communication
skipping to change at page 8, line 34 skipping to change at page 8, line 40
router parameter values at any time, subject to some constraints. router parameter values at any time, subject to some constraints.
Information Base - A collection of information maintained by this Information Base - A collection of information maintained by this
protocol, and which is to be made available to MANET routing protocol, and which is to be made available to MANET routing
protocols. An Information Base may be associated with a MANET protocols. An Information Base may be associated with a MANET
interface, or with a router. interface, or with a router.
Furthermore, this document uses the following notational conventions: Furthermore, this document uses the following notational conventions:
X contains y, or y is contained in X, is an unordered list X contains y, or y is contained in X, is an unordered list
membership operator, returning true if the unordered list X membership operator. X is an unordered list and y is an element.
includes the element y, and returning false otherwise. "X contains y" or "y is contained in X" returns true if the
unordered list X includes the element y, and returns 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. X and Y are both unordered lists. "X contains Y" or "Y
elements y which are contained in Y, and returning false is contained in X" returns true if the unordered list X contains
all elements y which are contained in Y, and returns false
otherwise. otherwise.
A overlaps B, if A and B are network addresses, and the range of A overlaps B, if A and B are network addresses, and the range of
addresses represented by A, and the range of addresses represented addresses represented by A, and the range of addresses represented
by B both contain at least one common address. (This is only by B both contain at least one common address. (This is only
possible if one range is a sub-range of the other.) 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,
network addresses, or unordered lists (they must be of the same network addresses, or unordered lists (they must be of the same
skipping to change at page 9, line 15 skipping to change at page 9, line 25
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, network addresses, or unordered lists (they must be may be values, network addresses, or unordered lists (they must be
of the 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 c contains d and d contains c (i.e., considered to be equal if c contains d and d contains c (i.e.,
they contain the same set of elements, regardless of the order in they contain the same set of elements, regardless of the order in
which they are recorded in the lists). If c and d are network which they are recorded in the lists). If c and d are network
addresses, they are considered equal only if both addresses and addresses, they are considered equal only if both addresses and
prefix lengths are equal (i.e., they represent the same ). prefix lengths are equal (i.e., they represent the same ).
e != f, is a comparison operator, returning true where (e = f) would e != f, is a comparison operator, returning not (e = f). i.e.,
have returned false, and returning false where (e = f) would have returning true where (e = f) would have returned false, and
returned true. returning false where (e = f) would have returned true.
3. Applicability Statement 3. Applicability Statement
This protocol: This protocol:
o Is applicable to networks, especially wireless networks, in which o Is applicable to networks, especially wireless networks, in which
unknown neighbors can be reached by local broadcast or multicast unknown neighbors can be reached by local broadcast or multicast
packets. packets.
o Is designed to work in networks with a dynamic topology, and in o Is designed to work in networks with a dynamic topology, and in
skipping to change at page 15, line 31 skipping to change at page 15, line 37
HELLO_INTERVAL may be fixed, or may be dynamic. For example HELLO_INTERVAL may be fixed, or may be dynamic. For example
HELLO_INTERVAL may be backed off due to congestion or network HELLO_INTERVAL may be backed off due to congestion or network
stability. stability.
o As a response to a change in the router itself, or its 1-hop o As a response to a change in the router itself, or its 1-hop
neighborhood, for example on first becoming active or in response neighborhood, for example on first becoming active or in response
to a new, lost, or changed status link. to a new, lost, or changed status link.
o In a combination of these proactive and responsive mechanisms. o In a combination of these proactive and responsive mechanisms.
Jittering of HELLO message generation and transmission, as described Jittering of HELLO message generation and transmission SHOULD be used
in Section 11.2, SHOULD be used if appropriate. as described in Section 11.2, unless the medium access control
mechanism in use prevents any simultaneous transmissions by
potentially interefering routers.
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 network addresses in the o A HELLO message MUST contain all of the network addresses in the
Local Interface Set of the router on which the HELLO message is Local Interface Set of the router on which the HELLO message is
being generated. This includes: being generated. This includes:
* At least one network address of each MANET interface of the o At least one network address of each MANET interface of the
router. router.
* Network addresses that include all source addresses of any IP o Network addresses that include all source addresses of any IP
datagrams sent by the router on any MANET interface. datagrams sent by the router on any MANET interface.
* All other network addresses of the router which are to be made o All other network addresses of the router which are to be made
known to any other router for any reason. known to any other router for any reason.
o For each MANET interface, within every time interval equal to the o For each MANET interface, within every time interval equal to the
corresponding REFRESH_INTERVAL, sent HELLO messages MUST corresponding REFRESH_INTERVAL, sent HELLO messages MUST
collectively include all of the relevant information in the collectively include all of the relevant information in the
corresponding Link Set and the Neighbor Information Base. Note corresponding Link Set and the Neighbor Information Base. Note
that when determining whether to include information in a HELLO that when determining whether to include information in a HELLO
message, the sender MUST consider all times up to the latest time message, the sender MUST consider all times up to the latest time
when it may send its next HELLO message on this MANET interface. when it may send its next HELLO message on this MANET interface.
skipping to change at page 18, line 5 skipping to change at page 18, line 8
Note that Link Quality is a "link admittance" mechanism, allowing a Note that Link Quality is a "link admittance" mechanism, allowing a
router to determine that a given link is too unstable to even router to determine that a given link is too unstable to even
consider for use. It is specifically not a link metric nor a consider for use. It is specifically not a link metric nor a
substitute for one. substitute for one.
Link quality information is only used locally and is not used in Link quality information is only used locally and is not used in
signaling. Routers may interoperate whether they are using the same, signaling. Routers may interoperate whether they are using the same,
different, or no, link quality information. Link quality information different, or no, link quality information. Link quality information
is thus not equivalent to a link metric. is thus not equivalent to a link metric.
Link quality information is defined in this specification as a
normalised, dimensionless, value in the interval zero to one,
inclusive, where the greater the value, the better the link quality.
See Section 14 for further details.
5. Protocol Parameters and Constants 5. Protocol Parameters and Constants
The parameters and constants used in this specification are described The parameters and constants used in this specification are described
in this section. in this section.
5.1. Protocol and Port Numbers 5.1. Protocol and Port Numbers
This protocol specifies HELLO messages, which are included in packets This protocol specifies HELLO messages, which are included in packets
as defined by [RFC5444]. These packets may be sent either using the as defined by [RFC5444]. These packets may be sent either using the
"manet" protocol number or the "manet" well-known UDP port number, as "manet" protocol number or the "manet" well-known UDP port number, as
skipping to change at page 19, line 31 skipping to change at page 19, line 40
[RFC5148].) [RFC5148].)
REFRESH_INTERVAL - is the maximum interval between advertisements, REFRESH_INTERVAL - is the maximum interval between advertisements,
in a HELLO message on this MANET interface, of each 1-hop neighbor in a HELLO message on this MANET interface, of each 1-hop neighbor
network address and its status. In all intervals of length network address and its status. In all intervals of length
REFRESH_INTERVAL, a router MUST include each 1-hop neighbor REFRESH_INTERVAL, a router MUST include each 1-hop neighbor
network address and its status in at least one HELLO message on network address and its status in at least one HELLO message on
this MANET interface. (This may be in the same or in different this MANET interface. (This may be in the same or in different
HELLO messages.) HELLO messages.)
REFRESH_INTERVAL thus represents the frequency at which a piece of
information, as received in HELLO messages, can be expected to be
refreshed. Thus, the REFRESH_INTERVAL is used as a basis for
determining when such information expires in receiving routers (see
Section 5.3.2). HELLO_INTERVAL represents the frequency of HELLO
message emissions. Logically, HELLO_INTERVAL cannot be greater than
the REFRESH_INTERVAL, otherwise information cannot be refreshed in a
timely manner.
HELLO messages can, however, be sent with a higher frequency. A
possible use for sending HELLO messages at such a higher frequency
includes sending partial HELLO messages (e.g., accommodating
constraints on packet sizes from the underlying medium) refreshing
only part of the information in each HELLO message. Another use is
for a router to send "empty HELLO messages", advertising its own
presence frequently in smaller HELLO messages (e.g., in case HELLO
message exchange success rates are used for link quality estimation,
or to enable rapid detection by new routers in the neighborhood) in
between HELLO messages refreshing neighbor information in other
routers.
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o HELLO_INTERVAL > 0 o HELLO_INTERVAL > 0
o HELLO_MIN_INTERVAL >= 0 o HELLO_MIN_INTERVAL >= 0
o HELLO_INTERVAL >= HELLO_MIN_INTERVAL o HELLO_INTERVAL >= HELLO_MIN_INTERVAL
o REFRESH_INTERVAL >= HELLO_INTERVAL o REFRESH_INTERVAL >= HELLO_INTERVAL
o If an INTERVAL_TIME Message TLV as defined in [RFC5497] is o If an INTERVAL_TIME Message TLV as defined in [RFC5497] is
included in a HELLO messages, then HELLO_INTERVAL MUST be included in a HELLO messages, then HELLO_INTERVAL MUST be
representable as described in [RFC5497]. representable as described in [RFC5497].
If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute
its neighbor advertisements between HELLO messages in any manner, its neighbor advertisements between HELLO messages in any manner,
subject to the constraints above. subject to the constraints above.
For a router to employ this protocol in a purely responsive manner on In the absence of any changes to the local neighborhood, a router
a MANET interface, REFRESH_INTERVAL and HELLO_INTERVAL SHOULD both be will send a HELLO message on a MANET interface after a (possibly
set to a value such that a responsive HELLO message is always jittered) interval of length HELLO_INTERVAL. For a router to employ
expected in a shorter period than this value. this protocol in a purely responsive manner on a MANET interface,
i.e., for the router to only send HELLO messages on that MANET
interface as a response to external events, HELLO_INTERVAL (and hence
also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such
that a responsive HELLO message is always expected with a shorter
period than this value.
If a router has more than one MANET interface, then, even if the If a router has more than one MANET interface, then, even if the
router configures different values of HELLO_INTERVAL on each MANET router configures different values of HELLO_INTERVAL on each MANET
interface, the router SHOULD configure the same value of interface, the router SHOULD configure the same value of
HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO
messages may be sent. messages may be sent. (This ensures that changes observed on one
MANET interface are reported on other MANET interfaces, so that 1-hop
neighbors connected to the latter can maintain up to date 2-hop
neighborhood information.)
5.3.2. Information Validity Times 5.3.2. Information Validity Times
The following interface parameters manage the validity time of link The following interface parameters manage the validity time of link
information: information:
L_HOLD_TIME - is the period of advertisement, on this MANET L_HOLD_TIME - is the period of advertisement, on this MANET
interface, of former 1-hop neighbor network addresses as lost in interface, of former 1-hop neighbor network addresses as lost in
HELLO 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.
Note that as each item of neighbor information is included in HELLO
messages within an interval of length REFRESH~_INTERVAL, contrainst
on H_HOLD_TIME are based on REFRESH_INTERVAL, not on HELLO_INTERVAL.
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o L_HOLD_TIME >= 0 o L_HOLD_TIME >= 0
o H_HOLD_TIME >= REFRESH_INTERVAL o H_HOLD_TIME >= REFRESH_INTERVAL
o If HELLO messages can be lost then both parameters SHOULD be o If HELLO messages can be lost then both parameters SHOULD be
significantly greater than REFRESH_INTERVAL. significantly greater than REFRESH_INTERVAL.
o H_HOLD_TIME MUST be representable as described in [RFC5497]. o H_HOLD_TIME MUST be representable as described in [RFC5497].
skipping to change at page 22, line 28 skipping to change at page 23, line 21
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 o If the HELLO_INTERVAL for a MANET interface increases, then the
next HELLO message on this MANET interface MUST be generated next HELLO message on this MANET interface MUST be generated
according to the previous, shorter, HELLO_INTERVAL. A number according to the previous, shorter, HELLO_INTERVAL. A number
of subsequent HELLO messages MAY be generated according to the of subsequent HELLO messages MAY be generated according to the
previous, shorter, HELLO_INTERVAL (but MUST include times previous, shorter, HELLO_INTERVAL (but MUST include times
according to current parameters). This ensures that "promises" according to current parameters). This ensures that "promises"
as to timely transmission of a future HELLO message is kept as to timely transmission of a future HELLO message is kept
until these previous promises have expired. until these previous promises have expired.
* If the HELLO_INTERVAL for a MANET interface decreases, then the o If the HELLO_INTERVAL for a MANET interface decreases, then the
following HELLO messages on this MANET interface MUST be following HELLO messages on this MANET interface MUST be
generated according to this current, shorter, HELLO_INTERVAL. generated according to this current, shorter, HELLO_INTERVAL.
REFRESH_INTERVAL REFRESH_INTERVAL
* If the REFRESH_INTERVAL for a MANET interface increases, then o If the REFRESH_INTERVAL for a MANET interface increases, then
the content of subsequent HELLO messages must be organized such the content of subsequent HELLO messages must be organized such
that the specification of the old value of REFRESH_INTERVAL is that the specification of the old value of REFRESH_INTERVAL is
satisfied for a further period equal to the old value of satisfied for a further period equal to the old value of
REFRESH_INTERVAL. REFRESH_INTERVAL.
* If the REFRESH_INTERVAL for a MANET interface decreases, then o If the REFRESH_INTERVAL for a MANET interface decreases, then
it MAY be necessary to reschedule HELLO message generation on it MAY be necessary to reschedule HELLO message generation on
that MANET interface, in order that the specification of that MANET interface, in order that the specification of
REFRESH_INTERVAL is satisfied from the time of change. REFRESH_INTERVAL is satisfied from the time of change.
HYST_ACCEPT and HYST_REJECT HYST_ACCEPT and HYST_REJECT
* If HYST_ACCEPT or HYST_REJECT changes, then the appropriate o If HYST_ACCEPT or HYST_REJECT changes, then the appropriate
actions for link quality change, as specified in Section 14.3, actions for link quality change, as specified in Section 14.3,
MUST be taken. MUST be taken.
L_HOLD_TIME L_HOLD_TIME
* If L_HOLD_TIME changes, then the expiry times of all relevant o If L_HOLD_TIME changes, then the expiry times of all relevant
Link Tuples MUST be changed. Link Tuples MUST be changed.
N_HOLD_TIME N_HOLD_TIME
* If N_HOLD_TIME changes, then the expiry times of all relevant o If N_HOLD_TIME changes, then the expiry times of all relevant
Lost Neighbor Tuples MUST be changed. Lost Neighbor Tuples MUST be changed.
HP_MAXJITTER HP_MAXJITTER
* If HP_MAXJITTER changes, then the periodic HELLO message o If HP_MAXJITTER changes, then the periodic HELLO message
schedule on this MANET interface MAY be changed. schedule on this MANET interface MAY be changed.
HT_MAXJITTER HT_MAXJITTER
* If HT_MAXJITTER changes, then externally triggered HELLO o 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 of a about its interfaces (MANET and non-MANET). Each interface of a
skipping to change at page 29, line 5 skipping to change at page 29, line 48
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 network 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, if that I_local_iface_addr_list of that Local Interface Tuple, if that
network address is not in the I_local_iface_addr_list of any network address is not in the I_local_iface_addr_list of any
other Local Interface Tuple, then create a Removed Interface other Local Interface Tuple, then create a Removed Interface
Address Tuple with: Address Tuple with:
* IR_local_iface_addr := removed address; o IR_local_iface_addr := removed address;
* IR_time := current time + I_HOLD_TIME. o IR_time := current time + I_HOLD_TIME.
3. Remove that Local Interface Tuple from the Local Interface Set. 3. Remove that Local Interface Tuple from the Local Interface Set.
4. If the interface to be removed is a MANET interface (i.e., with 4. If the interface to be removed is a MANET interface (i.e., with
I_manet = true) then: I_manet = true) then:
1. Remove the Interface Information Base for that MANET 1. Remove the Interface Information Base for that MANET
interface; interface;
2. All Neighbor Tuples for which none of the network addresses 2. All Neighbor Tuples for which none of the network addresses
skipping to change at page 29, line 44 skipping to change at page 30, line 40
Information Bases: Information Bases:
1. Remove any Removed Interface Address Tuple whose 1. Remove any Removed Interface Address Tuple whose
IR_local_iface_addr is the added network address. IR_local_iface_addr is the added network address.
2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a 2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a
network address that overlaps the added network address. network address that overlaps the added network address.
3. Remove any Link Tuples, in any Link Set, for which either: 3. Remove any Link Tuples, in any Link Set, for which either:
* L_neighbor_iface_addr_list contains any network address in the o L_neighbor_iface_addr_list contains any network address in the
N_neighbor_addr_list of any removed Neighbor Tuple; OR N_neighbor_addr_list of any removed Neighbor Tuple; OR
* L_neighbor_iface_addr_list contains a network address that o L_neighbor_iface_addr_list contains a network address that
overlaps the added network address. overlaps the added network address.
Apply Section 13.2, but not Section 13.3. Apply Section 13.2, but not Section 13.3.
4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps 4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps
the added network address. the added network address.
5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added 5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added
network address. network address.
skipping to change at page 30, line 40 skipping to change at page 31, line 34
then remove that interface as specified in Section 9.2. then remove that interface as specified in Section 9.2.
3. Otherwise: 3. Otherwise:
1. Remove the removed address from this I_local_iface_addr_list. 1. Remove the removed address from this I_local_iface_addr_list.
2. If the removed address is not in the I_local_iface_addr_list 2. If the removed address is not in the I_local_iface_addr_list
of any other Local Interface Tuple, then create a Removed of any other Local Interface Tuple, then create a Removed
Interface Address Tuple with: Interface Address Tuple with:
+ IR_local_iface_addr := removed address; o IR_local_iface_addr := removed address;
+ IR_time := current time + I_HOLD_TIME. o IR_time := current time + I_HOLD_TIME.
After removing the network address and making these changes, a HELLO After removing the network address and making these changes, a HELLO
message MAY be sent on all MANET interfaces. message MAY be sent on all MANET interfaces.
10. Packets and Messages 10. Packets and Messages
The packet and message format used by this protocol is defined in The packet and message format used by this protocol is defined in
[RFC5444], which is used with the following considerations: [RFC5444], which is used with the following considerations:
o This protocol specifies one Message Type, the HELLO message. o This protocol specifies one Message Type, the HELLO message.
skipping to change at page 35, line 18 skipping to change at page 35, line 47
Each such address object (see [RFC5444]) MUST be associated with one Each such address object (see [RFC5444]) MUST be associated with one
or more appropriate Address Block TLVs. Specifically: or more appropriate Address Block TLVs. Specifically:
1. For each address object (henceforth linked address) which 1. For each address object (henceforth linked address) which
represents a network address contained in an represents a network address contained in an
L_neighbor_iface_addr_list of a Link Tuple in the Link Set for L_neighbor_iface_addr_list of a Link Tuple in the Link Set for
this MANET interface, for which L_status != PENDING, include the this MANET interface, for which L_status != PENDING, include the
linked address with an associated Address Block TLV with: linked address with an associated Address Block TLV with:
* Type := LINK_STATUS; AND o Type := LINK_STATUS; AND
* Value := L_status. o Value := L_status.
2. For each address object (henceforth neighbor address) which 2. For each address object (henceforth neighbor address) which
represents a network address contained in an N_neighbor_addr_list represents a network address contained in an N_neighbor_addr_list
in a Neighbor Tuple with N_symmetric = true, and which has not in a Neighbor Tuple with N_symmetric = true, and which has not
already been included with an associated Address Block TLV with already been included with an associated Address Block TLV with
Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor
network address with an associated Address Block TLV with: network address with an associated Address Block TLV with:
* Type := OTHER_NEIGHB; AND o Type := OTHER_NEIGHB; AND
* Value := SYMMETRIC. o Value := SYMMETRIC.
3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth 3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth
lost address) has not already been represented as an address lost address) has not already been represented as an address
object and included, include lost address with an associated object and included, include lost address with an associated
Address Block TLV with: Address Block TLV with:
* Type := OTHER_NEIGHB; AND o Type := OTHER_NEIGHB; AND
* Value := LOST. o Value := LOST.
If any such network addresses have been added to these Information If any such network addresses have been added to these Information
Bases since the last HELLO message was sent on this MANET interface, Bases since the last HELLO message was sent on this MANET interface,
or if 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 network address) have changed since that network associate with that network address) have changed since that network
address was last reported on this MANET interface, then that network address was last reported on this MANET interface, then that network
address, and the indicated TLVs, SHOULD be included in the HELLO address, and the indicated TLVs, SHOULD be included in the HELLO
message. message.
If the address object (see [RFC5444]) representing a network address If the address object (see [RFC5444]) representing a network address
skipping to change at page 40, line 18 skipping to change at page 40, line 49
and populate the Removed Address List and Lost Address List: and populate the Removed Address List and Lost Address List:
1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples) 1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples)
where N_neighbor_addr_list contains any network address which where N_neighbor_addr_list contains any network address which
overlaps with any network address in the Neighbor Address List. overlaps with any network address in the Neighbor Address List.
2. If there are no matching Neighbor Tuples, then: 2. If there are no matching Neighbor Tuples, then:
1. Create a new Neighbor Tuple with: 1. Create a new Neighbor Tuple with:
+ N_neighbor_addr_list := Neighbor Address List; o N_neighbor_addr_list := Neighbor Address List;
+ N_symmetric := false. o N_symmetric := false.
3. If there is one matching Neighbor Tuple, then: 3. If there is one matching Neighbor Tuple, then:
1. If the matching Neighbor Tuple's N_neighbor_addr_list != 1. If the matching Neighbor Tuple's N_neighbor_addr_list !=
Neighbor Address List, then: Neighbor Address List, then:
1. For each network address (henceforth removed address) 1. For each network address (henceforth removed address)
which is contained in that N_neighbor_addr_list, but is which is contained in that N_neighbor_addr_list, but is
not contained in the Neighbor Address List: not contained in the Neighbor Address List:
1. Add removed address to the Removed Address List. 1. Add removed address to the Removed Address List.
2. If N_symmetric = true, then add removed address to 2. If N_symmetric = true, then add removed address 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. o N_neighbor_addr_list := Neighbor Address List.
4. If there are two or more matching Neighbor Tuples, then: 4. If there are two or more matching Neighbor Tuples, then:
1. For each network address (henceforth removed address) which 1. For each network address (henceforth removed address) which
is contained in the N_neighbor_addr_list of any of the is contained in the N_neighbor_addr_list of any of the
matching Neighbor Tuples but is not contained in the Neighbor matching Neighbor Tuples but is not contained in the Neighbor
Address List: Address List:
1. Add removed address to the Removed Address List. 1. Add removed address to the Removed Address List.
2. If N_symmetric = true, then add removed address to the 2. If N_symmetric = true, then add removed address to the
Lost Address List. Lost Address List.
2. Replace the matching Neighbor Tuples by a single Neighbor 2. Replace the matching Neighbor Tuples by a single Neighbor
Tuple with: Tuple with:
+ N_neighbor_addr_list := Neighbor Address List; o N_neighbor_addr_list := Neighbor Address List;
+ N_symmetric := false o N_symmetric := false
12.4. Updating the Lost Neighbor Set 12.4. Updating the Lost Neighbor Set
On receiving a HELLO message, a router MUST update its Lost Neighbor On receiving a HELLO message, a router MUST update its Lost Neighbor
Set: Set:
1. For each network address (henceforth lost address) which is 1. For each network address (henceforth lost address) which is
contained in the Lost Address List, if no Lost Neighbor Tuple contained in the Lost Address List, if no Lost Neighbor Tuple
with NL_neighbor_addr = lost address exists, then add a Lost with NL_neighbor_addr = lost address exists, then add a Lost
Neighbor Tuple with: Neighbor Tuple with:
* NL_neighbor_addr := lost address; o NL_neighbor_addr := lost address;
* NL_time := current time + N_HOLD_TIME. o 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 network addresses in the Removed Address List from the 1. Remove all network addresses in the Removed Address List from the
L_neighbor_iface_addr_list of all Link Tuples. L_neighbor_iface_addr_list of all Link Tuples.
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now 2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now
empty; apply Section 13.2, but not Section 13.3. empty; apply Section 13.2, but not Section 13.3.
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 network o L_neighbor_iface_addr_list contains one or more network
addresses in 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; o L_neighbor_iface_addr_list := empty;
* L_HEARD_time := EXPIRED; o L_HEARD_time := EXPIRED;
* L_SYM_time := EXPIRED;
* L_quality := INITIAL_QUALITY; o L_SYM_time := EXPIRED;
* L_pending := INITIAL_PENDING; o L_quality := INITIAL_QUALITY;
* L_lost := false; o L_pending := INITIAL_PENDING;
* L_time := current time + validity time. o L_lost := false;
o 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 network address (henceforth receiving 1. If the router finds any network address (henceforth receiving
address) in the Receiving Address List in an Address Block in address) in the Receiving Address List in an Address Block in
the HELLO message, then the Link Tuple is modified as the HELLO message, then the Link Tuple is modified as
follows: follows:
1. If any receiving address in the HELLO message is 1. If any receiving address in the HELLO message is
associated with an Address Block TLV with Type = associated with an Address Block TLV with Type =
LINK_STATUS and with Value = HEARD or Value = SYMMETRIC LINK_STATUS and with Value = HEARD or Value = SYMMETRIC
then: then:
- L_SYM_time := current time + validity time. o L_SYM_time := current time + validity time.
2. Otherwise if any receiving address in the HELLO message 2. Otherwise if any receiving address in the HELLO message
is associated with an Address Block TLV with Type = is associated with an Address Block TLV with Type =
LINK_STATUS and Value = LOST then: LINK_STATUS and Value = LOST then:
1. if L_SYM_time has not expired, then: 1. if L_SYM_time has not expired, then:
1. L_SYM_time := EXPIRED. 1. L_SYM_time := EXPIRED.
2. if L_status = HEARD, then: 2. if L_status = HEARD, then:
* L_time := current time + L_HOLD_TIME. o L_time := current time + L_HOLD_TIME.
2. L_neighbor_iface_addr_list := Sending Address List. 2. L_neighbor_iface_addr_list := Sending Address List.
3. L_HEARD_time := max(current time + validity time, 3. L_HEARD_time := max(current time + validity time,
L_SYM_time). L_SYM_time).
4. If L_status = PENDING, then: 4. If L_status = PENDING, then:
+ L_time := max(L_time, L_HEARD_time). o L_time := max(L_time, L_HEARD_time).
5. Otherwise if L_status = HEARD or L_status = SYMMETRIC, then: 5. Otherwise if L_status = HEARD or L_status = SYMMETRIC, then:
+ L_time := max(L_time, L_HEARD_time + L_HOLD_TIME). o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
12.6. Updating the 2-Hop Set 12.6. Updating the 2-Hop Set
On receiving a HELLO message a router MUST update its 2-Hop Set for On receiving a HELLO message a router MUST update its 2-Hop Set for
the MANET interface on which the HELLO message was received: the MANET interface on which the HELLO message was received:
1. Remove all network addresses in the Removed Address List from the 1. Remove all network addresses in the Removed Address List from the
N2_neighbor_iface_addr_list of all 2-Hop Tuples. N2_neighbor_iface_addr_list of all 2-Hop Tuples.
2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending 2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending
Address List, has L_status = SYMMETRIC then: Address List, has L_status = SYMMETRIC then:
1. For each network address (henceforth 2-hop address) in an 1. For each network address (henceforth 2-hop address) in an
Address Block of the HELLO message, where: Address Block of the HELLO message, where:
+ 2-hop address is not contained in the Neighbor Address o 2-hop address is not contained in the Neighbor Address
List; List;
+ 2-hop address is not contained in any o 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 o 2-hop address != any IR_local_iface_addr
perform the following processing: perform the following processing:
1. If 2-hop address has an associated Address Block TLV 1. If 2-hop address has an associated Address Block TLV
with: with:
- Type = LINK_STATUS and Value = SYMMETRIC; OR o Type = LINK_STATUS and Value = SYMMETRIC; OR
- Type = OTHER_NEIGHB and Value = SYMMETRIC, o Type = OTHER_NEIGHB and Value = SYMMETRIC,
then, if there is no 2-Hop Tuple such that: then, if there is no 2-Hop Tuple such that:
- N2_neighbor_iface_addr_list contains one or more o N2_neighbor_iface_addr_list contains one or more
network addresses in the Sending Address List; AND network addresses in the Sending Address List; AND
- N2_2hop_addr = 2-hop address. o N2_2hop_addr = 2-hop address.
then create a 2-Hop Neighbor Tuple with: then create a 2-Hop Neighbor Tuple with:
- N2_2hop_addr := 2-hop address. o N2_2hop_addr := 2-hop address.
This 2-Hop Tuple (existing or new) is then modified as This 2-Hop Tuple (existing or new) is then modified as
follows: follows:
- N2_neighbor_iface_addr_list := Sending Address List; o N2_neighbor_iface_addr_list := Sending Address List;
- N2_time := current time + validity time. o N2_time := current time + validity time.
2. Otherwise if 2-hop address has an Address Block TLV with: 2. Otherwise if 2-hop address has an Address Block TLV with:
- Type = LINK_STATUS and Value = LOST or Value = HEARD; o Type = LINK_STATUS and Value = LOST or Value = HEARD;
OR OR
- Type = OTHER_NEIGHB and Value = LOST; o Type = OTHER_NEIGHB and Value = LOST;
then remove all 2-Hop Tuples with: then remove all 2-Hop Tuples with:
- N2_neighbor_iface_addr_list contains one or more o N2_neighbor_iface_addr_list contains one or more
network addresses in the Sending Address List; AND network addresses in the Sending Address List; AND
- N2_2hop_addr = 2-hop address. o N2_2hop_addr = 2-hop address.
13. Other Information Base Changes 13. Other Information Base Changes
The Interface and Neighbor Information Bases MUST be changed when The Interface and Neighbor Information Bases MUST be changed when
certain events occur. These events may result from HELLO message certain events occur. These events may result from HELLO message
processing, or may be otherwise generated (e.g., expiry of timers or processing, or may be otherwise generated (e.g., expiry of timers or
link quality changes). link quality changes).
Events which cause changes in the Information Bases are: Events which cause changes in the Information Bases are:
skipping to change at page 45, line 27 skipping to change at page 46, line 11
such as to indicate a change in L_status of any 1-hop neighbors such as to indicate a change in L_status of any 1-hop neighbors
(including the addition or removal of any 1-hop neighbors, other (including the addition or removal of any 1-hop neighbors, other
than those considered pending). than those considered pending).
13.1. Link Tuple Symmetric 13.1. Link Tuple Symmetric
If, for any Link Tuple which does not have L_status = SYMMETRIC: If, for any Link Tuple which does not have L_status = SYMMETRIC:
o L_status changes to SYMMETRIC; o L_status changes to SYMMETRIC;
(this includes a newly created Link Tuple which is immediately then:
updated such that L_status = SYMMETRIC) then:
1. For the Neighbor Tuple whose N_neighbor_addr_list contains 1. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list, set: L_neighbor_iface_addr_list, set:
* N_symmetric := true. o N_symmetric := true.
2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is 2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is
contained in that N_neighbor_addr_list. contained in that N_neighbor_addr_list.
This includes any newly created Link Tuples whose status is
immediately updated such that L_status = SYMMETRIC. (Note that in
this specification all Link Tuples are created such that their
L_status is not SYMMETRIC, but a Link Tuple may be immediately
updated by subsequent processing of the same HELLO message that
caused the creation of the Link Tuple such that the Link Tuple's
L_status changes to SYMMETRIC.)
13.2. Link Tuple Not Symmetric 13.2. Link Tuple Not Symmetric
If for any Link Tuple with L_status = SYMMETRIC: If for any Link Tuple with L_status = SYMMETRIC:
o L_status changes to any other value; OR o L_status changes to any other value; OR
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 network o N2_neighbor_iface_addr_list contains one or more network
addresses in 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 o L_neighbor_iface_addr_list is contained in
N_neighbor_addr_list; AND N_neighbor_addr_list; AND
+ L_status = SYMMETRIC; o 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 network 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; o NL_neighbor_addr := neighbor address;
- NL_time := current time + N_HOLD_TIME. o 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:
o L_HEARD_time expires; OR o L_HEARD_time expires; OR
o the Link Tuple is removed; o the Link Tuple is removed;
then: then:
1. For the Neighbor Tuple whose N_neighbor_addr_list contains 1. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list, if no Link Tuples for any MANET L_neighbor_iface_addr_list, if no Link Tuples for any MANET
interface remain where: interface remain where:
* L_neighbor_iface_addr_list is contained in o L_neighbor_iface_addr_list is contained in
N_neighbor_addr_list; AND N_neighbor_addr_list; AND
* L_HEARD_time is not expired; o 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. 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. Link
quality information is specified as a normalised, dimensionless
figure in the interval zero to one, inclusive, a higher value
indicating a better link quality.
For deployments where no link quality is used, the considerations in For deployments where no link quality is used, the considerations in
Section 14.1 apply. For deployments where link quality is used, the Section 14.1 apply. For deployments where link quality is used, the
general principles of link quality usage are described in general principles of link quality usage are described in
Section 14.2. Section 14.3 and Section 14.4 detail link quality Section 14.2. Section 14.3 and Section 14.4 detail link quality
functioning. functioning.
14.1. Deployment Without Link Quality 14.1. Deployment Without Link Quality
In order for a router to not employ link quality, the router MUST In order for a router to not employ link quality, the router MUST
skipping to change at page 48, line 5 skipping to change at page 48, line 45
accepted or rejected (depending on which threshold it has most accepted or rejected (depending on which threshold it has most
recently crossed, or, if neither, on the value of parameter recently crossed, or, if neither, on the value of parameter
INITIAL_PENDING). With appropriate values of these parameters, this INITIAL_PENDING). With appropriate values of these parameters, this
prevents over-rapid changes of link status. prevents over-rapid changes of link status.
The basic principles of link quality usage are as follows: The basic principles of link quality usage are as follows:
o A router does not advertise a neighbor interface in any state o A router does not advertise a neighbor interface in any state
until L_quality is acceptable: until L_quality is acceptable:
* If INITIAL_PENDING = true, then the link is advertised when o If INITIAL_PENDING = true, then the link is advertised when
link L_quality >= HYST_ACCEPT. link L_quality >= HYST_ACCEPT.
* Otherwise the link is advertised when L_quality >= HYST_REJECT. o Otherwise the link is advertised when L_quality >= HYST_REJECT.
A link which is not yet advertised has L_pending = true. A link which is not yet advertised has L_pending = true.
o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false, o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false,
indicating that the link can be advertised. indicating that the link can be advertised.
o A link for which L_pending = false is advertised until its o A link for which L_pending = false is advertised until its
L_quality drops below HYST_REJECT. L_quality drops below HYST_REJECT.
o If a link has L_pending = false and L_quality < HYST_REJECT, the o If a link has L_pending = false and L_quality < HYST_REJECT, the
skipping to change at page 48, line 47 skipping to change at page 49, line 40
1. If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is 1. If L_quality >= HYST_ACCEPT then the corresponding Link Tuple is
modified by: modified by:
1. L_pending := false; 1. L_pending := false;
2. L_lost := false; 2. L_lost := false;
3. If L_status = HEARD or L_status = SYMMETRIC, then: 3. If L_status = HEARD or L_status = SYMMETRIC, then:
+ L_time := max(L_time, L_HEARD_time + L_HOLD_TIME). o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
2. If L_status != PENDING, and L_quality < HYST_REJECT then the 2. If L_status != PENDING, and L_quality < HYST_REJECT then the
corresponding Link Tuple is modified by: corresponding Link Tuple is modified by:
1. If L_lost = false, then: 1. If L_lost = false, then:
+ L_lost := true; o L_lost := true;
+ L_time := min(L_time, current time + L_HOLD_TIME). o L_time := min(L_time, current time + L_HOLD_TIME).
Any appropriate action indicted in Section 13 MUST also be taken. As a result of this processing, the L_STATUS of a Link Tuple may
change. In this case, the processing actions corresponding to this
change, as specified in in Section 13, MUST also be taken.
If L_quality for a link is updated based on HELLO message reception, If L_quality for a link is updated based on HELLO message reception,
or on reception of a packet including a HELLO message, then L_quality or on reception of a packet including a HELLO message, then L_quality
MUST be updated prior to the HELLO message processing described in MUST be updated prior to the HELLO message processing described in
Section 12. (If the receipt of the HELLO message, or the packet Section 12. (If the receipt of the HELLO message, or the packet
containing it, creates the Link Tuple, then the Link Tuple MUST be containing it, creates the Link Tuple, then the Link Tuple MUST be
created with the appropriately updated L_quality value, rather than created with the appropriately updated L_quality value, rather than
with L_quality := INITIAL_QUALITY.) with L_quality := INITIAL_QUALITY.)
14.4. Updating Link Quality 14.4. Updating Link Quality
skipping to change at page 53, line 39 skipping to change at page 54, line 35
the constraints in Appendix B. The exact consequence of information the constraints in Appendix B. The exact consequence of information
inexactness depends on the use of these Information Bases, and SHOULD inexactness depends on the use of these Information Bases, and SHOULD
therefore be reflected in the specification of protocols which use therefore be reflected in the specification of protocols which use
information provided by this neighborhood discovery protocol. information provided by this neighborhood discovery protocol.
This section, therefore, firstly outlines the ways in which correctly This section, therefore, firstly outlines the ways in which correctly
formed, but still invalid, HELLO messages may appear, in formed, but still invalid, HELLO messages may appear, in
Section 17.1. Section 17.1.
Injection of invalid HELLO messages into a network may be prevented Injection of invalid HELLO messages into a network may be prevented
by different means. If, for example, a network is deployed in a site in a number of ways. If, for example, a network is deployed in a
to which access is strictly regulated, in order that physical access site to which access is strictly regulated, so that physical access
and proximity to the network is prevented, then further security and proximity to the network is prevented, then further security
mechanisms to protect against malicious routers injecting invalid mechanisms to protect against malicious routers injecting invalid
HELLO messages may not be required. Similarly, if the link layer HELLO messages may not be required. Similarly, if the link layer
over which the network is formed provides appropriate over which the network is formed provides appropriate
confidentiality, authentication, and integrity, then this may, for a confidentiality, authentication, and integrity, then this may, for a
given deployment, suffice to appropriately protect against disclosure given deployment, suffice to appropriately protect against disclosure
of information to an eavesdropper, and against a malicious router of information to an eavesdropper, and against a malicious router
injecting invalid HELLO messages. In the latter case the link layer injecting invalid HELLO messages. In the latter case the link layer
would discard frames that fail the link layer checks, without would discard frames that fail the link layer checks, without
attempting to deliver such frames to IP. Finally, certain usage may attempting to deliver such frames to IP. Finally, certain usage may
skipping to change at page 54, line 35 skipping to change at page 55, line 30
17.1. Invalid HELLO Messages 17.1. Invalid HELLO Messages
A correctly formed, but still invalid, HELLO message may take any of A correctly formed, but still invalid, HELLO message may take any of
the following forms. Note that a present or absent address object in the following forms. Note that a present or absent address object in
an Address Block, does not by itself cause a problem. It is the an Address Block, does not by itself cause a problem. It is the
presence, absence, or incorrectness of associated LOCAL_IF, presence, absence, or incorrectness of associated LOCAL_IF,
LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems. LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems.
A router may provide false information about its own identity: A router may provide false information about its own identity:
* The HELLO message may contain address objects with an o The HELLO message may contain address objects with an
associated LOCAL_IF Address Block TLV which do not correspond associated LOCAL_IF Address Block TLV which do not correspond
to addresses of interfaces of the router transmitting the HELLO to addresses of interfaces of the router transmitting the HELLO
message. message.
* The HELLO message may omit network addresses, or their o The HELLO message may omit network addresses, or their
associated LOCAL_IF Address Block TLV, of interfaces of the associated LOCAL_IF Address Block TLV, of interfaces of the
router transmitting the HELLO message (other than the allowed router transmitting the HELLO message (other than the allowed
omission of the only local interface network address of the omission of the only local interface network address of the
MANET interface over which the HELLO message is transmitted, if MANET interface over which the HELLO message is transmitted, if
that is the case). that is the case).
* The HELLO message may incorrectly specify the LOCAL_IF Address o The HELLO message may incorrectly specify the LOCAL_IF Address
Block TLV Value associated with one or more local interface Block TLV Value associated with one or more local interface
network addresses, indicating incorrectly whether they are network addresses, indicating incorrectly whether they are
associated with the MANET interface over which the HELLO associated with the MANET interface over which the HELLO
message is transmitted. message is transmitted.
A router may provide false information about the identity of other A router may provide false information about the identity of other
routers: routers:
* A present LINK_STATUS Address Block TLV may, incorrectly, o A present LINK_STATUS Address Block TLV may, incorrectly,
identify a network address as being of a MANET interface which identify a network address as being of a MANET interface which
is or was heard on the MANET interface over which the HELLO is or was heard on the MANET interface over which the HELLO
message is transmitted. message is transmitted.
* A consistently absent LINK_STATUS Address Block TLV may, o A consistently absent LINK_STATUS Address Block TLV may,
incorrectly, fail to identify a network address as being of a incorrectly, fail to identify a network address as being of a
MANET interface which is or was heard on the MANET interface MANET interface which is or was heard on the MANET interface
over which the HELLO message is transmitted. over which the HELLO message is transmitted.
* A present OTHER_NEIGHB Address Block TLV may, incorrectly, o A present OTHER_NEIGHB Address Block TLV may, incorrectly,
identify a network address as being of a router which is or was identify a network address as being of a router which is or was
in the 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, o A consistently absent OTHER_NEIGHB Address Block TLV may,
incorrectly, fail to identify a network address as being of a incorrectly, fail to identify a network address as being of a
router which is or was in the sending router's symmetric 1-hop router 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 o The Value of a LINK_STATUS Address Block TLV may incorrectly
indicate the status (LOST, SYMMETRIC or HEARD) of the link from indicate the status (LOST, SYMMETRIC or HEARD) of the link from
a 1-hop neighbor. a 1-hop neighbor.
* The Value of an OTHER_NEIGHB Address Block TLV may incorrectly o The Value of an OTHER_NEIGHB Address Block TLV may incorrectly
indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop
neighbor. neighbor.
17.2. Authentication, Integrity and Confidentiality Suggestions 17.2. Authentication, Integrity and Confidentiality Suggestions
The security suggestions in [RFC5444] regarding inclusion of a The security suggestions in [RFC5444] regarding inclusion of a
cryptographic signature in a Message TLV or a Packet TLV can be cryptographic signature in a Message TLV or a Packet TLV can be
applied to this protocol. Failure to verify either form of applied to this protocol. Failure to verify either form of
cryptographic signature should cause a HELLO message to be rejected cryptographic signature should cause a HELLO message to be rejected
without being processed. without being processed.
skipping to change at page 63, line 19 skipping to change at page 64, line 19
o N_neighbor_addr_list MUST NOT contain any duplicated network o N_neighbor_addr_list MUST NOT contain any duplicated network
addresses. addresses.
o N_neighbor_addr_list MUST NOT contain any network address which is o N_neighbor_addr_list MUST NOT contain any network address which is
in the N_neighbor_addr_list of any other Neighbor Tuple. in the N_neighbor_addr_list of any other Neighbor Tuple.
o If N_symmetric is = true, then there MUST be one or more Link o If N_symmetric is = true, then there MUST be one or more Link
Tuples with: Tuples with:
* L_neighbor_iface_addr_list contained in N_neighbor_addr_list; o L_neighbor_iface_addr_list contained in N_neighbor_addr_list;
AND AND
* L_status = SYMMETRIC. o 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. o 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 overlap any network address in the o NL_neighbor_addr MUST NOT overlap any network address in the
I_local_iface_addr_list of any Local Interface Tuple or the I_local_iface_addr_list of any Local Interface Tuple or the
IR_local_iface_addr of any Removed Interface Address Tuple. IR_local_iface_addr of any Removed Interface Address Tuple.
skipping to change at page 63, line 49 skipping to change at page 64, line 49
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 o L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
* L_status = SYMMETRIC. o L_status = SYMMETRIC.
o N2_2hop_addr MUST NOT overlap any network address in the o N2_2hop_addr MUST NOT overlap any network address in the
I_local_iface_addr_list of any Local Interface Tuple or the I_local_iface_addr_list of any Local Interface Tuple or the
IR_local_iface_addr of any Removed 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
skipping to change at page 64, line 26 skipping to change at page 65, line 26
Appendix C. HELLO Message Example Appendix C. HELLO Message Example
HELLO messages are instances of [RFC5444] messages, and this protocol HELLO messages are instances of [RFC5444] messages, and this protocol
supports any combination of message header options and address supports any combination of message header options and address
encodings, enabled by [RFC5444] that convey the required information. encodings, enabled by [RFC5444] that convey the required information.
As a consequence, there is no single way to represent how all HELLO As a consequence, there is no single way to represent how all HELLO
messages look. This appendix illustrates two HELLO message with messages look. This appendix illustrates two HELLO message with
similar content, the exact values included are explained in the similar content, the exact values included are explained in the
following text. following text.
The message has Message Header containing hop-limit, hop-count and The HELLO message's four bit Message Flags (MF) field has value 7
message sequence number (four bit Flags field value is 14). Its four indicating that the message header contains hop limit, hop count and
bit Message Address Length field has value 3 and hence addresses in message sequence number fields. Its four bit Message Address Length
the message have length four octets, here being IPv4 addresses. The (MAL) field has value 3 indicating addresses in the message have
message is as transmitted with a hop limit of 1 and a hop count of 0. length four octets, here being IPv4 addresses. The message is as
The overall message length is 45 octets. transmitted, with a hop limit of 1 and a hop count of 0. The overall
message length is 45 octets.
The message contains a Message TLV Block with content length 8 octets The message contains a Message TLV Block with content length 8 octets
containing two Message TLVs, of types VALIDITY_TIME and containing two Message TLVs, of types VALIDITY_TIME and
INTERVAL_TIME. Each uses a Message TLV with Flags octet value 16, INTERVAL_TIME. Each uses a Message TLV with Flags octet (MTLVF)
indicating that each has a Value. Each has a Value Length of 1 value 16, indicating that each has a Value, and each has a Value
octet; the Values included (0x64 and 0x58) are time codes Length of 1 octet. The Values included are time codes (as defined in
representing the default values of parameters H_HOLD_TIME and [RFC5497]) representing the parameters H_HOLD_TIME and
HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the HELLO_INTERVAL, respectively.
default value of constant C (1/1024 second).
The message has a single Address Block containing 5 addresses. The The message has a single Address Block containing 5 addresses. The
Flags octet value 128 indicates an address Head but no address Tail, Address Block Flags octet (ABF) value 128 indicates an address Head
and no address prefixes. The Head Length of 3 octets indicates but no address Tail, and no address prefixes. The Head Length of 3
address Mid sections of one octet each (Mid 0 to Mid 4). octets indicates address Mid sections of one octet each (Mid 0 to Mid
4).
The following Address Block TLV Block (content length 14 octets) The following Address Block TLV Block (content length 14 octets)
includes two Address Block TLVs. The first is a LOCAL_IF Address includes two Address Block TLVs. The first is a LOCAL_IF Address
Block TLV which (with Flags octet value 80) indicates that a single Block TLV with Flags octet (ATLVF) value 80, which indicates that a
address, with index 0 (i.e., Head:Mid 0) is the single local single address, with index 0 (i.e., the address Head:Mid 0) is the
interface address of this router (the 1 octet Value THIS_IF indicates single local interface address of this router (the 1 octet Value
that this address is of this interface). The second is a LINK_STATUS THIS_IF indicates that this address is of this interface). The
Address Block TLV which (with Flags octet value 48) specifies the second is a LINK_STATUS Address Block TLV with Flags octet (ATLVF)
link status values of all reported neighbors in a single multivalue value 52, which specifies the link status values of all reported
Address Block TLV which covers the addresses with indexes 1 to 4. neighbors in a single multivalue Address Block TLV that covers the
The Address Block TLV Value Length of 4 octets indicates one octet addresses with indexes 1 to 4, inclusive. The Address Block TLV
per Value per address. The last four addresses have associated link Value Length of 4 octets indicates one octet per Value per address.
status, the first and second HEARD, the third SYMMETRIC, and the The last four addresses thus are of neighbors, each an with
fourth LOST. associated link status: the first and second HEARD, the third
SYMMETRIC, and the fourth LOST.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO |1 1 1 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1| | HELLO | MF=7 | MAL=3 | Message Length = 45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | | Hop Limit = 1 | Hop Count = 0 | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0| | Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 1 0 0 0 0| | Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0| | Value Len = 1 | Value (Time) | Num Addrs = 5 | ABF = 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head | | Head Len = 3 | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 0 | Mid 1 | Mid 2 | Mid 3 | | Mid 0 | Mid 1 | Mid 2 | Mid 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF | | Mid 4 | Address TLV Block Length = 14 | LOCAL_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF | | ATLVF = 80 | Index = 0 | Value Len = 1 | THIS_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS |0 0 1 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| | LINK_STATUS | ATLV = 52 | Strt Indx = 1 | Stop Indx = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | | Value Len = 4 | HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST | | LOST |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Note that this example is for illustrative purposes. The essential Note that this example is for illustrative purposes. The essential
information can be conveyed, more efficiently (assuming that the information can be conveyed, more efficiently (assuming that the
local interface address will be supplied by IP, and that the local interface address will be supplied by IP, and that the
INTERVAL_TIME TLV is not needed) by the 29 octets: INTERVAL_TIME TLV is not needed) by the 29 octets:
0 1 2 3 0 1 2 3
skipping to change at page 66, line 25 skipping to change at page 67, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 1 | Mid 2 | Mid 3 | Mid 4 | | Mid 1 | Mid 2 | Mid 3 | Mid 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC | |0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST | | LOST |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Note that the above example assumes that H_HOLD_TIME and C have their
default values of 6 seconds and 1/1024 second, and thus result in a
time code of 100 (hexadecimal 64).
Appendix D. Flow and Congestion Control Appendix D. Flow and Congestion Control
This protocol specifies one Message Type, the HELLO message. The This protocol specifies one Message Type, the HELLO message. The
maximum size of a HELLO message is proportional to the size of the maximum size of a HELLO message is proportional to the size of the
originating router's 1-hop neighborhood. HELLO messages MUST NOT be originating router's 1-hop neighborhood. HELLO messages MUST NOT be
forwarded. forwarded.
A router MUST report its 1-hop neighborhood in HELLO messages on each A router MUST report its 1-hop neighborhood in HELLO messages on each
of its MANET interfaces at least each REFRESH_INTERVAL. This puts a of its MANET interfaces at least each REFRESH_INTERVAL. This puts a
lower bound on the control traffic generated by each router in the lower bound on the control traffic generated by each router in the
 End of changes. 131 change blocks. 
235 lines changed or deleted 297 lines changed or added

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