draft-ietf-manet-nhdp-11.txt   draft-ietf-manet-nhdp-12.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: April 29, 2010 BAE Systems ATC Expires: September 24, 2010 BAE Systems ATC
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
October 26, 2009 March 23, 2010
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-11 draft-ietf-manet-nhdp-12
Abstract
This document describes a 1-hop and symmetric 2-hop neighborhood
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on September 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document describes a 1-hop and symmetric 2-hop neighborhood This document may contain material from IETF Documents or IETF
discovery protocol (NHDP) for mobile ad hoc networks (MANETs). Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11 4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11
4.2. Information Base Overview . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . 16 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 17
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 17 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 18
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 17 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 18
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 17 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 18
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 17 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 18
5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 18 5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 18
5.3.2. Information Validity Times . . . . . . . . . . . . . . 19 5.3.2. Information Validity Times . . . . . . . . . . . . . . 20
5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 20 5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 20
5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 21 5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 21
5.4.1. Information Validity Time . . . . . . . . . . . . . . 21 5.4.1. Information Validity Time . . . . . . . . . . . . . . 21
5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 21
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 22 5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 22
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 23 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 23
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 23 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 24
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 24 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 24
7. Interface Information Base . . . . . . . . . . . . . . . . . . 24 7. Interface Information Bases . . . . . . . . . . . . . . . . . 25
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 26 8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 27
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 27 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 27
9. Local Information Base Changes . . . . . . . . . . . . . . . . 27 9. Local Information Base Changes . . . . . . . . . . . . . . . . 28
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 27 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 28
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 28 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 28
9.3. Adding a Network Address to an Interface . . . . . . . . . 28 9.3. Adding a Network Address to an Interface . . . . . . . . . 29
9.4. Removing a Network Address from an Interface . . . . . . . 29 9.4. Removing a Network Address from an Interface . . . . . . . 30
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 30 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 30
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 30 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 31
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 31 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 32
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 32 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 33
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 33 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 34
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 35 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 36
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 35 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 36
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 35 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 37
12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 36 12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 37
12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37 12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 39
12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 38 12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 40
12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 40 12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 41
12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 40 12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 41
12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 42 12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 43
13. Other Information Base Changes . . . . . . . . . . . . . . . . 43 13. Other Information Base Changes . . . . . . . . . . . . . . . . 44
13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 44 13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 45
13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 44 13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 45
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 45 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 46
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 45 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 46 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 47
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 46 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 47
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 47 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 48
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 48 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 49
15. Proposed Values for Parameters and Constants . . . . . . . . . 48 15. Proposed Values for Parameters and Constants . . . . . . . . . 49
15.1. Message Interval Interface Parameters . . . . . . . . . . 48 15.1. Message Interval Interface Parameters . . . . . . . . . . 50
15.2. Information Validity Time Interface Parameters . . . . . . 49 15.2. Information Validity Time Interface Parameters . . . . . . 50
15.3. Information Validity Time Router Parameters . . . . . . . 49 15.3. Information Validity Time Router Parameters . . . . . . . 50
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 49 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 50
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 49 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 50
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 49 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 50
16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 49 16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 50
17. Security Considerations . . . . . . . . . . . . . . . . . . . 51 17. Security Considerations . . . . . . . . . . . . . . . . . . . 53
17.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 53 17.1. Invalid HELLO Messages . . . . . . . . . . . . . . . . . . 54
17.2. Authentication, Integrity and Confidentiality 17.2. Authentication, Integrity and Confidentiality
Suggestions . . . . . . . . . . . . . . . . . . . . . . . 54 Suggestions . . . . . . . . . . . . . . . . . . . . . . . 55
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 55 18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 56
18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 55 18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 56
18.3. Message-Type-specific TLV Type Registries . . . . . . . . 55 18.3. Message-Type-Specific TLV Type Registries . . . . . . . . 56
18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 56 18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 57
18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 57 18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 58
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 57 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 59
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
21.1. Normative References . . . . . . . . . . . . . . . . . . . 58 21.1. Normative References . . . . . . . . . . . . . . . . . . . 60
21.2. Informative References . . . . . . . . . . . . . . . . . . 58 21.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 59 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 60
Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 60 Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 61
Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 63 Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 64
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 65 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 66
Appendix E. Interval and Timer Illustrations . . . . . . . . . . 66 Appendix E. Interval and Timer Illustrations . . . . . . . . . . 67
E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 66 E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 67
E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 72 E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 73
E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 73 E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 74
Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 75 Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 76
F.1. Example 1: Standard Single Interface Topology . . . . . . 75 F.1. Example 1: Standard Single Interface Topology . . . . . . 76
F.2. Example 2: Dual Addressed Interface on One Hop Neighbor . 76 F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor . . 77
F.3. Example 3: Dual Addressed Interface on Two Hop Neighbor . 77 F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor . . 78
F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 77 F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 78
F.5. Example 5: Dual Interface on Two Hop Neighbor . . . . . . 78 F.5. Example 5: Dual Interface on 2-Hop Neighbor . . . . . . . 79
F.6. Example 6: Dual interface on One Hop Neighbor . . . . . . 78 F.6. Example 6: Dual interface on 1-Hop Neighbor . . . . . . . 79
F.7. Example 7: Dual Interface on One and Two Hop Neighbors . . 79 F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors . . 80
F.8. Example 8: Dual Interface Locally and on One Hop F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor . 81
Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . 80 F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 81
F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 80
F.10. Example 10: Dual Addressed Dual Interfaces on All F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers . . . . . . . . . . . . . . . . . . . . . . . . . 81 Routers . . . . . . . . . . . . . . . . . . . . . . . . . 82
F.11. Example 11: Single Addressed Dual Interface Locally . . . 82 F.11. Example 11: Single Addressed Dual Interface Locally . . . 83
1. Introduction 1. Introduction
This document describes a neighborhood discovery protocol (NHDP) for This document describes a neighborhood discovery protocol (NHDP) for
a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a
local exchange of HELLO messages in order that each router can local exchange of HELLO messages in order that each router can
determine the presence of, and connectivity to, its 1-hop and determine the presence of, and connectivity to, its 1-hop and
symmetric 2-hop neighbors. Messages are defined and sent in packets symmetric 2-hop neighbors. Messages are defined and sent in packets
according to the specification [RFC5444]. according to the specification [RFC5444].
skipping to change at page 7, line 5 skipping to change at page 7, line 5
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
All terms introduced in [RFC5444], including "packet", "message", All terms introduced in [RFC5444], including "packet", "message",
"Address Block", "TLV Block", "TLV", "address", "address prefix", and "Address Block", "TLV Block", "TLV", "address", "address prefix", and
"address object" are to be interpreted as described therein. "address object" are to be interpreted as described therein.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Network Address An address plus an associated prefix length. This Network Address - An address plus an associated prefix length. This
may be an address with an associated maximum prefix length, or an may be an address with an associated maximum prefix length, or an
address prefix including a prefix length. address prefix including a prefix length. A Network Address thus
represents a range of addresses.
Router - A MANET router which implements this neighborhood discovery Router - A MANET router which implements this neighborhood discovery
protocol. protocol.
Interface - A network device, configured and assigned one or more Interface - A network device, configured and assigned one or more
addresses. addresses.
MANET interface - An interface participating in a MANET and using MANET interface - An interface participating in a MANET and using
this neighborhood discovery protocol. A router may have several this neighborhood discovery protocol. A router may have several
MANET interfaces. MANET interfaces.
Heard - A MANET interface of router X is considered heard on a MANET Heard - A MANET interface of router X is considered heard on a MANET
interface of a router Y if the latter can receive traffic from the interface of a router Y if the latter can receive control
former. messages, according to this specification, from the former.
Link - A link between two MANET interfaces exists if either can be Link - A link between two MANET interfaces exists if either can be
heard by the other. heard by the other.
Symmetric link - A symmetric link between two MANET interfaces Symmetric link - A symmetric link between two MANET interfaces
exists if both can be heard by the other. exists if both can be heard by the other.
1-hop neighbor - A router X is a 1-hop neighbor of a router Y if a 1-hop neighbor - A router X is a 1-hop neighbor of a router Y if a
MANET interface of router X is heard by a MANET interface of MANET interface of router X is heard by a MANET interface of
router Y. router Y.
Symmetric 1-hop neighbor - A router X is a symmetric 1-hop neighbor Symmetric 1-hop neighbor - A router X is a symmetric 1-hop neighbor
of a router Y if a symmetric link exists between a MANET interface of a router Y if a symmetric link exists between a MANET interface
on router X and a MANET interface on router Y. on router X and a MANET interface on router Y.
2-hop neighbor - A router X is a 2-hop neighbor of a router Y if 2-hop neighbor - A router X is a 2-hop neighbor of a router Y if
router X is a 1-hop neighbor of a 1-hop neighbor of router Y, but router X is a 1-hop neighbor of a 1-hop neighbor of router Y, but
is not router Y itself. is not router Y itself.
Symmetric 2-hop neighbor - A router X is a symmetric 2-hop neighbor Symmetric 2-hop neighbor - A router X is a symmetric 2-hop neighbor
of a router Y if router X is a symmetric 1-hop neighbor of a of a router Y if router X is a symmetric 1-hop neighbor of a
symmetric 1-hop neighbor of router Y, but is not router Y itself. symmetric 1-hop neighbor of router Y, but is not router Y itself.
1-hop neighborhood - The 1-hop neighborhood of a router X is the set 1-hop neighborhood - The 1-hop neighborhood of a router X is the set
of the 1-hop neighbors of router X. of the 1-hop neighbors of router X.
Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a
router X is the set of the symmetric 1-hop neighbors of router X. router X is the set of the symmetric 1-hop neighbors of router X.
2-hop neighborhood - The 2-hop neighborhood of a router X is the set 2-hop neighborhood - The 2-hop neighborhood of a router X is the set
of the 2-hop neighbors of router X. (This may include routers in of the 2-hop neighbors of router X. (This may include routers in
the 1-hop neighborhood of router X.) the 1-hop neighborhood of router X.)
Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a
router X is the set of the symmetric 2-hop neighbors of router X. router X is the set of the symmetric 2-hop neighbors of router X.
(This may include routers in the 1-hop neighborhood, or even in (This may include routers in the 1-hop neighborhood, or even in
the symmetric 1-hop neighborhood, of router X.) the symmetric 1-hop neighborhood, of router X.)
Constant - A numerical value which MUST be the same for all MANET Constant - A numerical value which MUST be the same for all MANET
interfaces of all routers in the MANET, at all times. interfaces of all routers in the MANET, at all times.
Interface parameter - A boolean or numerical value, specified Interface parameter - A boolean or numerical value, specified
separately for each MANET interface of each router. A router MAY separately for each MANET interface of each router. A router MAY
change interface parameter values at any time, subject to some change interface parameter values at any time, subject to some
constraints. constraints.
Router parameter - A boolean or numerical value, specified for each Router parameter - A boolean or numerical value, specified for each
router, and not specific to an interface. A router MAY change router, and not specific to an interface. A router MAY change
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, returning true if the unordered list X
includes the element y, and returning false otherwise. includes the element y, and returning false otherwise.
X contains Y, or Y is contained in X, is an unordered list inclusion X contains Y, or Y is contained in X, is an unordered list inclusion
operator, returning true if the unordered list X contains all operator, returning true if the unordered list X contains all
elements y which are contained in Y, and returning false elements y which are contained in Y, and returning false
otherwise. otherwise.
A overlaps B if A and B are network addresses, and the range of A overlaps B, if A and B are network addresses, and the range of
network addresses represented by A, and the range of network addresses represented by A, and the range of addresses represented
addresses represented by B both contain at least one common by B both contain at least one common address. (This is only
network address. (This is only possible if one range is a sub- possible if one range is a sub-range of the other.)
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
type). type).
c = d is a comparison operator, returning true if the value of the c = d, is a comparison operator, returning true if the value of the
left side (c) is equal to the value of the right side (d). c and d left side (c) is equal to the value of the right side (d). c and d
may be values, 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 they contain the same set of elements, considered to be equal if c contains d and d contains c (i.e.,
regardless of the order in which they are recorded in either list they contain the same set of elements, regardless of the order in
(in which case c contains d, and d contains c). If c and d are which they are recorded in the lists). If c and d are network
network addresses, they are considered equal only if both addresses, they are considered equal only if both addresses and
addresses and prefix lengths are equal. 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 true where (e = f) would
have returned false, and returning false where (e = f) would have have returned false, and returning false where (e = f) would have
returned true. returned true.
3. Applicability Statement 3. Applicability Statement
This protocol: This protocol:
o Is applicable to networks, especially wireless networks, in which o Is applicable to networks, especially wireless networks, in which
unknown neighbors can be reached by local broadcast or multicast unknown neighbors can be reached by local broadcast or multicast
packets. packets.
skipping to change at page 11, line 25 skipping to change at page 11, line 25
4.1. Routers and Interfaces 4.1. Routers and Interfaces
In order for a router to participate in a MANET, it MUST have at In order for a router to participate in a MANET, it MUST have at
least one, and possibly more, MANET interfaces. least one, and possibly more, MANET interfaces.
Each MANET interface: Each MANET interface:
o Is configured with one or more network addresses. All addresses o Is configured with one or more network addresses. All addresses
represented by these network addresses MUST be unique to this represented by these network addresses MUST be unique to this
router at least within its 2-hop neighborhood. All such addresses router. All such addresses MUST be unique to this MANET
MUST be unique to this MANET interface, except that an address can interface, except that an address can be used by more than one
be used by more than one MANET interface on the same router if MANET interface on the same router if those MANET interfaces are
those MANET interfaces are "isolated" from each other (no MANET "isolated" from each other (no MANET interface on another router
interface on another router can hear or be heard by two MANET can communicate to, from, or one to and one from, two MANET
interfaces using overlapping network addresses). interfaces using overlapping network addresses).
o Has a set of interface parameters, defining the behavior of this o Has a set of interface parameters, defining the behavior of this
MANET interface. Each MANET interface MAY be individually MANET interface. Each MANET interface MAY be individually
parameterized. parameterized.
o Has an Interface Information Base, recording information regarding o Has an Interface Information Base, recording information regarding
links to this MANET interface and symmetric 2-hop neighbors which links to this MANET interface and symmetric 2-hop neighbors which
can be reached through such links. can be reached through such links.
skipping to change at page 12, line 33 skipping to change at page 12, line 33
transmitted HELLO messages. Such information has a limited duration transmitted HELLO messages. Such information has a limited duration
in which it is considered valid. This duration is determined from in which it is considered valid. This duration is determined from
the VALIDITY_TIME TLV in the HELLO message in which the information the VALIDITY_TIME TLV in the HELLO message in which the information
is received, which in turn is set by the router that originated the is received, which in turn is set by the router that originated the
HELLO message, using its corresponding interface parameter HELLO message, using its corresponding interface parameter
H_HOLD_TIME. H_HOLD_TIME.
Appendix E illustrates the relationship between message reception, Appendix E illustrates the relationship between message reception,
included VALIDITY_TIME TLVs, and the duration for which information included VALIDITY_TIME TLVs, and the duration for which information
received in a HELLO message is considered valid. Appendix F received in a HELLO message is considered valid. Appendix F
illustrates some example two hop topologies and how they correspond illustrates some example topologies and how they correspond to
to information in the Information Bases. information in the Information Bases.
4.2.1. Local Information Base 4.2.1. Local Information Base
Each router maintains a Local Information Base, which contains the Each router maintains a Local Information Base, which contains the
router's local configuration information, specifically: router's local configuration information, specifically:
o The Local Interface Set, which consists of Local Interface Tuples, o The Local Interface Set, which consists of Local Interface Tuples,
each of which represents an interface (MANET or non-MANET) of the each of which represents an interface (MANET or non-MANET) of the
router. router.
skipping to change at page 16, line 16 skipping to change at page 16, line 16
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.
o For each MANET interface, within every time interval equal to the
corresponding REFRESH_INTERVAL, sent HELLO messages MUST
collectively include all of the relevant information in the
corresponding Link Set and the Neighbor Information Base.
o When determining whether to include a given piece of neighbor
information in a HELLO message, it is not sufficient to consider
whether that information has been sent in the interval of length
REFRESH_INTERVAL up to the current time. Instead, the router MUST
consider the interval of length REFRESH_INTERVAL that will end at
the latest possible time at which the next HELLO message will be
sent on this MANET interface. (Normally, this will be
HELLO_INTERVAL past the current time, but MAY be earlier if this
router elects to divide its neighbor information among more than
one HELLO message in order to reduce the size of its HELLO
messages.) All neighbor information MUST be sent in this
interval, i.e., the router MUST ensure that this HELLO message
includes all neighbour information that has not already been
included in any HELLO messages sent since the start of this
interval (normally the current time - (REFRESH_INTERVAL -
HELLO_INTERVAL)).
o A HELLO message MUST include exactly one VALIDITY_TIME Message o A HELLO message MUST include exactly one VALIDITY_TIME Message
TLV, as specified in [RFC5497], that indicates the length of time TLV, as specified in [RFC5497], that indicates the length of time
for which the message content is to be considered valid, and is for which the message content is to be considered valid, and is
therefore to be included in the receiving router's Interface therefore to be included in the receiving router's Interface
Information Base. Information Base.
o A periodically generated HELLO message SHOULD include exactly one o A periodically generated HELLO message SHOULD include exactly one
INTERVAL_TIME Message TLV, as specified in [RFC5497], that INTERVAL_TIME Message TLV, as specified in [RFC5497], that
indicates the current value of HELLO_INTERVAL for that MANET indicates the current value of HELLO_INTERVAL for that MANET
interface, i.e. the period within which a further HELLO message is interface, i.e., the period within which a further HELLO message
guaranteed to be sent on that MANET interface. is guaranteed to be sent on that MANET interface.
4.3.3. HELLO Message Processing 4.3.3. HELLO Message Processing
HELLO messages received by a router are used to update the Interface HELLO messages received by a router are used to update the Interface
Information Base for the MANET interface over which that HELLO Information Base for the MANET interface over which that HELLO
message was received, as well as the Neighbor Information Base of the message was received, as well as the Neighbor Information Base of the
router. Specifically: router. Specifically:
o The router ensures that there is a single Neighbor Tuple o The router ensures that there is a single Neighbor Tuple
corresponding to the originator of that HELLO message. corresponding to the originator of that HELLO message.
skipping to change at page 18, line 32 skipping to change at page 19, line 12
1-hop neighbors. The frequency of these advertisements is 1-hop neighbors. The frequency of these advertisements is
regulated by the interface parameters HELLO_INTERVAL and regulated by the interface parameters HELLO_INTERVAL and
HELLO_MIN_INTERVAL. HELLO_MIN_INTERVAL.
o To advertise this router's knowledge of each of its 1-hop o To advertise this router's knowledge of each of its 1-hop
neighbors. The frequency of the advertisement of each such neighbors. The frequency of the advertisement of each such
neighbor is regulated by the interface parameter REFRESH_INTERVAL. neighbor is regulated by the interface parameter REFRESH_INTERVAL.
Specifically, these parameters are as follows: Specifically, these parameters are as follows:
HELLO_INTERVAL - is the maximum time between the transmission of two HELLO_INTERVAL - is the maximum time between the transmission of two
successive HELLO messages on this MANET interface. If using successive HELLO messages on this MANET interface. If using
periodic transmission of HELLO messages, these SHOULD be at a periodic transmission of HELLO messages, these SHOULD be at a
separation of HELLO_INTERVAL, possibly modified by jitter as separation of HELLO_INTERVAL, possibly modified by jitter as
specified in [RFC5148]. specified in [RFC5148].
HELLO_MIN_INTERVAL - is the minimum interval between transmission of HELLO_MIN_INTERVAL - is the minimum interval between transmission of
two successive HELLO messages, on this MANET interface. (This two successive HELLO messages, on this MANET interface. (This
minimum interval MAY be modified by jitter, as defined in minimum interval MAY be modified by jitter, as defined in
[RFC5148].) [RFC5148].)
REFRESH_INTERVAL - is the maximum interval between advertisements, 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.)
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o HELLO_INTERVAL > 0 o HELLO_INTERVAL > 0
skipping to change at page 19, line 37 skipping to change at page 20, line 17
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.
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.
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
skipping to change at page 20, line 19 skipping to change at page 20, line 46
o If HELLO messages can be lost then both parameters SHOULD be o If HELLO messages can be lost then both parameters SHOULD be
significantly greater than REFRESH_INTERVAL. significantly greater than REFRESH_INTERVAL.
o H_HOLD_TIME MUST be representable as described in [RFC5497]. o H_HOLD_TIME MUST be representable as described in [RFC5497].
5.3.3. Link Quality 5.3.3. Link Quality
The following interface parameters manage the usage of link quality The following interface parameters manage the usage of link quality
(see Section 14): (see Section 14):
HYST_ACCEPT - is the link quality threshold at or above which a link HYST_ACCEPT - is the link quality threshold at or above which a link
becomes usable, if it was not already so. becomes usable, if it was not already so.
HYST_REJECT - is the link quality threshold below which a link HYST_REJECT - is the link quality threshold below which a link
becomes unusable, if it was not already so. becomes unusable, if it was not already so.
INITIAL_QUALITY - is the initial quality of a newly identified link. INITIAL_QUALITY - is the initial quality of a newly identified link.
INITIAL_PENDING - if true, then a newly identified link is INITIAL_PENDING - if true, then a newly identified link is
considered pending, and is not usable until the link quality has considered pending, and is not usable until the link quality has
reached or exceeded the HYST_ACCEPT threshold. reached or exceeded the HYST_ACCEPT threshold.
The following constraints apply to these interface parameters: The following constraints apply to these interface parameters:
o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1 o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1
o 0 <= INITIAL_QUALITY <= 1. o 0 <= INITIAL_QUALITY <= 1.
o If link quality is not updated, then INITIAL_QUALITY >= o If link quality is not updated, then INITIAL_QUALITY >=
skipping to change at page 20, line 49 skipping to change at page 21, line 32
o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false. o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false.
o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true. o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true.
5.3.4. Jitter 5.3.4. Jitter
If jitter, as defined in [RFC5148], is used then these parameters are If jitter, as defined in [RFC5148], is used then these parameters are
as follows: as follows:
HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for periodically generated HELLO messages on this MANET interface. for periodically generated HELLO messages on this MANET interface.
HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for externally triggered HELLO messages on this MANET interface. for externally triggered HELLO messages on this MANET interface.
For constraints on these interface parameters see [RFC5148]. For constraints on these interface parameters see [RFC5148].
5.4. Router Parameters 5.4. Router Parameters
The two router parameters defined by this specification are in the The two router parameters defined by this specification are in the
category of information validity time. category of information validity time.
5.4.1. Information Validity Time 5.4.1. Information Validity Time
The following router parameter manages the validity time of lost The following router parameter manages the validity time of lost
symmetric 1-hop neighbor information: symmetric 1-hop neighbor information:
N_HOLD_TIME - is used as the period during which former 1-hop N_HOLD_TIME - is used as the period during which former 1-hop
neighbor network addresses are advertised as lost in HELLO neighbor network addresses are advertised as lost in HELLO
messages, allowing recipients of these HELLO messages to messages, allowing recipients of these HELLO messages to
accelerate removal of this information from their 2-Hop Sets. accelerate removal of this information from their 2-Hop Sets.
N_HOLD_TIME MAY be set to zero, if accelerated information removal N_HOLD_TIME MAY be set to zero, if accelerated information removal
is not required. is not required.
I_HOLD_TIME - is the period for which a recently used local I_HOLD_TIME - is the period for which a recently used local
interface network address is recorded. interface network address is recorded.
The following constraints applies to these router parameters: The following constraints applies to these router parameters:
o N_HOLD_TIME >= 0 o N_HOLD_TIME >= 0
o I_HOLD_TIME >= 0 o I_HOLD_TIME >= 0
5.5. Parameter Change Constraints 5.5. Parameter Change Constraints
skipping to change at page 22, line 30 skipping to change at page 23, line 13
REFRESH_INTERVAL is satisfied from the time of change. REFRESH_INTERVAL is satisfied from the time of change.
HYST_ACCEPT and HYST_REJECT HYST_ACCEPT and HYST_REJECT
* If HYST_ACCEPT or HYST_REJECT changes, then the appropriate * If HYST_ACCEPT or HYST_REJECT changes, then the appropriate
actions for link quality change, as specified in Section 14.3, actions for link quality change, as specified in Section 14.3,
MUST be taken. MUST be taken.
L_HOLD_TIME L_HOLD_TIME
* If L_HOLD_TIME changes, then L_time for all relevant Link * If L_HOLD_TIME changes, then the expiry times of all relevant
Tuples MUST be changed. Link Tuples MUST be changed.
N_HOLD_TIME N_HOLD_TIME
* If N_HOLD_TIME changes, then NL_time for all relevant Lost * If N_HOLD_TIME changes, then the expiry times of all relevant
Neighbor Tuples MUST be changed. Lost Neighbor Tuples MUST be changed.
HP_MAXJITTER HP_MAXJITTER
* If HP_MAXJITTER changes, then the periodic HELLO message * If HP_MAXJITTER changes, then the periodic HELLO message
schedule on this MANET interface MAY be changed. schedule on this MANET interface MAY be changed.
HT_MAXJITTER HT_MAXJITTER
* If HT_MAXJITTER changes, then externally triggered HELLO * If HT_MAXJITTER changes, then externally triggered HELLO
messages on this MANET interface MAY be rescheduled. messages on this MANET interface MAY be rescheduled.
skipping to change at page 23, line 23 skipping to change at page 24, line 4
The Local Information Base is not modified by signaling. If a The Local Information Base is not modified by signaling. If a
router's interface configuration changes, then the Local Information router's interface configuration changes, then the Local Information
Base MUST reflect these changes. This MAY also result in signaling Base MUST reflect these changes. This MAY also result in signaling
to advertise these changes. to advertise these changes.
It is not necessary to include all addresses of an interface in the It is not necessary to include all addresses of an interface in the
Local Information Base, and hence in HELLO messages. However any Local Information Base, and hence in HELLO messages. However any
address that may be the source address of an IP datagram sent from address that may be the source address of an IP datagram sent from
that interface MUST be included (and at least one address MUST be that interface MUST be included (and at least one address MUST be
included). A protocol using this specification MAY add additional included). A protocol using this specification MAY add additional
requirements to these, e.g. that any address that may be the requirements to these, e.g., that any address that may be the
destination address of an IP datagram is also included. destination address of an IP datagram is also included.
The addresses assigned to an interface are "owned" by the router, and The addresses assigned to an interface are "owned" by the router, and
MUST NOT be used by any other router as an interface address. If an MUST NOT be used by any other router as an interface address. If an
address has a prefix length and represents a range of addresses, this address has a prefix length and represents a range of addresses, this
applies to all addresses in that range (i.e. such ranges MUST NOT applies to all addresses in that range (i.e., such ranges MUST NOT
overlap). overlap).
The addresses assigned to different interfaces on the same router The addresses assigned to different interfaces on the same router
MUST be distinct (hence network address ranges MUST NOT overlap) MUST be distinct (hence network address ranges MUST NOT overlap)
except that: except that:
o The same address MAY be assigned to any number of non-MANET o The same address MAY be assigned to any number of non-MANET
interfaces as well as to one (or more if the following condition interfaces as well as to one (or more if the following condition
also applies) MANET interface. also applies) MANET interface.
skipping to change at page 24, line 5 skipping to change at page 24, line 35
6.1. Local Interface Set 6.1. Local Interface Set
A router's Local Interface Set records its local interfaces. It A router's Local Interface Set records its local interfaces. It
consists of Local Interface Tuples, one per interface: consists of Local Interface Tuples, one per interface:
(I_local_iface_addr_list, I_manet) (I_local_iface_addr_list, I_manet)
where: where:
I_local_iface_addr_list is an unordered list of the network I_local_iface_addr_list - is an unordered list of the network
addresses of this interface. addresses of this interface.
I_manet is a boolean flag, describing if this interface is a MANET I_manet - is a boolean flag, describing if this interface is a MANET
interface. interface.
Local Interface Tuples are removed from the Local Interface Set only Local Interface Tuples are removed from the Local Interface Set only
when the routers' interface configuration changes, subject to when the routers' interface configuration changes, subject to
Section 9, i.e. they are not subject to timer-based expiration. Section 9, i.e., they are not subject to timer-based expiration.
6.2. Removed Interface Address Set 6.2. Removed Interface Address Set
A router's Removed Interface Address Set records network addresses A router's Removed Interface Address Set records network addresses
which were recently used as local interface network addresses. If a which were recently used as local interface network addresses. If a
router's interface network addresses are immutable then the Removed router's interface network addresses are immutable then the Removed
Interface Address Set is always empty and MAY be omitted. It Interface Address Set is always empty and MAY be omitted. It
consists of Removed Interface Address Tuples, one per network consists of Removed Interface Address Tuples, one per network
address: address:
(IR_local_iface_addr, IR_time) (IR_local_iface_addr, IR_time)
where: where:
IR_local_iface_addr is a recently used network address of an IR_local_iface_addr - is a recently used network address of an
interface of this router. interface of this router.
IR_time specifies when this Tuple expires and MUST be removed. IR_time - specifies when this Tuple expires and MUST be removed.
7. Interface Information Base 7. Interface Information Bases
A router maintains an Interface Information Base for each of its A router maintains an Interface Information Base for each of its
MANET interfaces. This records information about links to that MANET MANET interfaces. This records information about links to that MANET
interface and symmetric 2-hop neighbors which can be reached in two interface and symmetric 2-hop neighbors which can be reached in two
hops using those links as the first hop. The Interface Information hops using those links as the first hop. Each Interface Information
Base includes the Link Set and the 2-Hop Set. Base includes a Link Set and a 2-Hop Set.
A network address of a symmetric 2-hop neighbor can also be present A network address of a symmetric 2-hop neighbor can also be present
as the network address of a 1-hop neighbor. This allows the router as the network address of a 1-hop neighbor. This allows the router
using this network address to be immediately considered as a using this network address to be immediately considered as a
symmetric 2-hop neighbor if it fails to be a symmetric 1-hop symmetric 2-hop neighbor if it fails to be a symmetric 1-hop
neighbor. neighbor.
An element which specifies a time is considered expired if the An element which specifies a time is considered expired if the
current time is greater than or equal to that time. One such current time is greater than or equal to that time. One such
element, present in most Tuples, indicates when expired that the element, present in most Tuples, indicates when expired that the
Tuple itself is considered expired and MUST be removed. Tuples which Tuple itself is considered expired and MUST be removed. Tuples which
do not have such a time element are removed at other times as do not have such a time element are removed at other times as
specified, for example a Neighbor Tuple is removed when all specified, for example a Neighbor Tuple is removed when all
corresponding Link Tuples have been removed. corresponding Link Tuples have been removed.
7.1. Link Set 7.1. Link Set
A router's Link Set records links from other routers which are, or An interface's Link Set records links from other routers which are,
recently were, 1-hop neighbors. It consists of Link Tuples, each or recently were, 1-hop neighbors. It consists of Link Tuples, each
representing a single link: representing a single link:
(L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time,
L_quality, L_pending, L_lost, L_time) L_quality, L_pending, L_lost, L_time)
where: where:
L_neighbor_iface_addr_list is an unordered list of the network L_neighbor_iface_addr_list - is an unordered list of the network
addresses of the MANET interface of the 1-hop neighbor; addresses of the MANET interface of the 1-hop neighbor;
L_HEARD_time is the time until which the MANET interface of the L_HEARD_time - is the time up to which the MANET interface of the
1-hop neighbor would be considered heard if not considering link 1-hop neighbor would be considered heard if not considering link
quality; quality;
L_SYM_time is the time until which the link to the 1-hop neighbor L_SYM_time - is the time up to which the link to the 1-hop neighbor
would be considered symmetric if not considering link quality; would be considered symmetric if not considering link quality;
L_quality is a dimensionless number between 0 (inclusive) and 1 L_quality - is a dimensionless number between 0 (inclusive) and 1
(inclusive) describing the quality of a link; a greater value of (inclusive) describing the quality of a link; a greater value of
L_quality indicating a higher quality link; L_quality indicating a higher quality link;
L_pending is a boolean flag, describing if a link is considered L_pending - is a boolean flag, describing if a link is considered
pending (i.e. a candidate, but not yet established, link); pending (i.e., a candidate, but not yet established, link);
L_lost is a boolean flag, describing if a link is considered lost L_lost - is a boolean flag, describing if a link is considered lost
due to low link quality; due to low link quality;
L_time specifies when this Tuple expires and MUST be removed. L_time - specifies when this Tuple expires and MUST be removed.
The status of the link, as obtained through HELLO message exchange The status of the link, as obtained through HELLO message exchange
and using link quality, is denoted L_status. L_status can take the and using link quality, is denoted L_status. L_status can take the
Values PENDING, HEARD, SYMMETRIC and LOST. The values LOST, Values PENDING, HEARD, SYMMETRIC and LOST. The values LOST,
SYMMETRIC and HEARD are defined in Section 18.5. The Value PENDING SYMMETRIC and HEARD are defined in Section 18.5. The Value PENDING
is never used in a HELLO message, it is only used locally by a is never used in a HELLO message, it is only used locally by a
router, and any Value distinct from LOST, SYMMETRIC and HEARD may be router, and any Value distinct from LOST, SYMMETRIC and HEARD may be
used. used.
L_status is defined by: L_status is defined by:
skipping to change at page 26, line 16 skipping to change at page 26, line 48
3. otherwise, if L_SYM_time is not expired, then L_status := 3. otherwise, if L_SYM_time is not expired, then L_status :=
SYMMETRIC; SYMMETRIC;
4. otherwise, if L_HEARD_time is not expired, then L_status := 4. otherwise, if L_HEARD_time is not expired, then L_status :=
HEARD; HEARD;
5. otherwise, L_status := LOST. 5. otherwise, L_status := LOST.
7.2. 2-Hop Set 7.2. 2-Hop Set
A router's 2-Hop Set records network addresses of symmetric 2-hop An interface's 2-Hop Set records network addresses of symmetric 2-hop
neighbors, and the symmetric links to symmetric 1-hop neighbors neighbors, and the symmetric links to symmetric 1-hop neighbors
through which these symmetric 2-hop neighbors can be reached. It through which these symmetric 2-hop neighbors can be reached. It
consists of 2-Hop Tuples, each representing a single network address consists of 2-Hop Tuples, each representing a single network address
of a symmetric 2-hop neighbor, and a single MANET interface of a of a symmetric 2-hop neighbor, and a single MANET interface of a
symmetric 1-hop neighbor. symmetric 1-hop neighbor.
(N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time) (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)
where: where:
N2_neighbor_iface_addr_list is an unordered list of the network N2_neighbor_iface_addr_list - is an unordered list of the network
addresses of the MANET interface of the symmetric 1-hop neighbor addresses of the MANET interface of the symmetric 1-hop neighbor
from which this information was received; from which this information was received;
N2_2hop_addr is a network address of a symmetric 2-hop neighbor N2_2hop_addr - is a network address of a symmetric 2-hop neighbor
which has a symmetric link (using any MANET interface) to the which has a symmetric link (using any MANET interface) to the
indicated symmetric 1-hop neighbor; indicated symmetric 1-hop neighbor;
N2_time specifies when this Tuple expires and MUST be removed. N2_time - specifies when this Tuple expires and MUST be removed.
8. Neighbor Information Base 8. Neighbor Information Base
Each router maintains a Neighbor Information Base that records Each router maintains a Neighbor Information Base that records
information about network addresses of current and recently symmetric information about network addresses of current and recently symmetric
1-hop neighbors. 1-hop neighbors.
8.1. Neighbor Set 8.1. Neighbor Set
A router's Neighbor Set records all network addresses of each 1-hop A router's Neighbor Set records all network addresses of each 1-hop
neighbor. It consists of Neighbor Tuples, each representing a single neighbor. It consists of Neighbor Tuples, each representing a single
1-hop neighbor: 1-hop neighbor:
(N_neighbor_addr_list, N_symmetric) (N_neighbor_addr_list, N_symmetric)
where: where:
N_neighbor_addr_list is an unordered list of the network addresses N_neighbor_addr_list - is an unordered list of the network addresses
of a 1-hop neighbor; of a 1-hop neighbor;
N_symmetric is a boolean flag, describing if this is a symmetric N_symmetric - is a boolean flag, describing if this is a symmetric
1-hop neighbor. 1-hop neighbor.
Neighbor Tuples are removed from the Neighbor Set only when Neighbor Tuples are removed from the Neighbor Set only when
corresponding Link Tuples expire from the routers' Link Set, i.e. corresponding Link Tuples expire from the routers' Link Set, i.e.,
Neighbor Tuples are not directly subject to timer-based expiration. Neighbor Tuples are not directly subject to timer-based expiration.
8.2. Lost Neighbor Set 8.2. Lost Neighbor Set
A router's Lost Neighbor Set records network addresses of routers A router's Lost Neighbor Set records network addresses of routers
which recently were symmetric 1-hop neighbors, but which are now which recently were symmetric 1-hop neighbors, but which are now
advertised as lost. It consists of Lost Neighbor Tuples, each advertised as lost. It consists of Lost Neighbor Tuples, each
representing a single such network address: representing a single such network address:
(NL_neighbor_addr, NL_time) (NL_neighbor_addr, NL_time)
where: where:
NL_neighbor_addr is a network address of a router which recently was NL_neighbor_addr - is a network address of a router which recently
a symmetric 1-hop neighbor of this router; was a symmetric 1-hop neighbor of this router;
NL_time specifies when this Tuple expires and MUST be removed. NL_time - specifies when this Tuple expires and MUST be removed.
9. Local Information Base Changes 9. Local Information Base Changes
The Local Information Base MUST be updated in response to changes in The Local Information Base MUST be updated in response to changes in
the router's local interface configuration. These may also change the router's local interface configuration. These MAY also change
the the Interface Information Base and the Neighbor Information Base. the Interface Information Base and the Neighbor Information Base. If
If any changes to the latter Information Bases satisfy any of the any changes to the latter Information Bases satisfy any of the
conditions described in Section 13, then those changes must be conditions described in Section 13, then those changes MUST be
applied immediately, unless noted otherwise below. applied immediately, unless noted otherwise below.
A router MAY transmit HELLO messages in response to these changes. A router MAY transmit HELLO messages in response to these changes.
9.1. Adding an Interface 9.1. Adding an Interface
If an interface is added to the router, then this is indicated by the If an interface is added to the router, then this is indicated by the
addition of a Local Interface Tuple to the Local Interface Set. If addition of a Local Interface Tuple to the Local Interface Set. If
the new interface is a MANET interface, then an initially empty the new interface is a MANET interface, then an initially empty
Interface Information Base MUST be created for this new MANET Interface Information Base MUST be created for this new MANET
skipping to change at page 28, line 26 skipping to change at page 29, line 11
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; * IR_local_iface_addr := removed address;
* IR_time := current time + I_HOLD_TIME. * IR_time := current time + I_HOLD_TIME.
3. Remove that Local Interface Tuple from the Local Interface Set. 3. Remove that Local Interface Tuple from the Local Interface Set.
4. If the interface to be removed is a MANET interface (i.e. with 4. If the interface to be removed is a MANET interface (i.e., with
I_manet = true) then: I_manet = true) then:
1. Remove the Interface Information Base for that MANET 1. Remove the Interface Information Base for that MANET
interface; interface;
2. All Neighbor Tuples for which none of the network addresses 2. All Neighbor Tuples for which none of the network addresses
in its N_neighbor_addr_list are contained in any in its N_neighbor_addr_list are contained in any
L_neighbor_iface_addr_list in any remaining Link Tuple, are L_neighbor_iface_addr_list in any remaining Link Tuple, are
removed. removed.
If the removed interface is the last MANET interface of the router, If the removed interface is the last MANET interface of the router,
then there will be no remaining Interface Information Bases, and the then there will be no remaining Interface Information Bases, and the
router will longer participate in this protocol. router will no longer participate in this protocol.
After removing the interface and making these changes, a HELLO After removing the interface and making these changes, a HELLO
message MAY be sent on all remaining MANET interfaces. message MAY be sent on all remaining MANET interfaces.
9.3. Adding a Network Address to an Interface 9.3. Adding a Network Address to an Interface
If a network address is added to an interface then this is indicated If a network address is added to an interface then this is indicated
by the addition of a network address to the appropriate by the addition of a network address to the appropriate
I_local_iface_addr_list. The following changes MUST be made to the I_local_iface_addr_list. The following changes MUST be made to the
Information Bases: Information Bases:
1. Any Removed Interface Address Tuple whose IR_local_iface_addr is 1. Remove any Removed Interface Address Tuple whose
the added network address is removed. IR_local_iface_addr is the added network address.
2. Any Neighbor Tuples whose N_neighbor_addr_list contains the added 2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a
network address, are removed. network address that overlaps the added network address.
3. Any Link Tuples, in any Link Set, whose 3. Remove any Link Tuples, in any Link Set, for which either:
L_neighbor_iface_addr_list contains:
* the added network address; OR * L_neighbor_iface_addr_list contains any network address in the
N_neighbor_addr_list of any removed Neighbor Tuple; OR
* any network address in the N_neighbor_addr_list of any removed * L_neighbor_iface_addr_list contains a network address that
Neighbor Tuple overlaps the added network address.
are removed; apply Section 13.2, but not Section 13.3. Apply Section 13.2, but not Section 13.3.
4. Any Lost Neighbor Tuples whose NL_neighbor_addr = the added 4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps
network address, are removed. the added network address.
5. Any 2-Hop Tuples whose N2_2hop_addr = the added network address, 5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added
are removed. network address.
After adding the network address and making these changes, a HELLO After adding the network address and making these changes, a HELLO
message MAY be sent on all MANET interfaces. message MAY be sent on all MANET interfaces.
These changes, other than to the appropriate I_local_iface_addr_list, These changes, other than to the appropriate I_local_iface_addr_list,
are made in order to maintain consistency of the Information Bases. are made in order to maintain consistency of the Information Bases.
Specifically, these changes remove any record of any use of this Specifically, these changes remove any record of any use of this
network address by routers in the 1-hop neighborhood or in the network address by routers in the 1-hop neighborhood or in the
symmetric 2-hop neighborhood of this router. symmetric 2-hop neighborhood of this router.
skipping to change at page 30, line 22 skipping to change at page 31, line 10
10. Packets and Messages 10. Packets and Messages
The packet and message format used by this protocol is defined in The packet and message format used by this protocol is defined in
[RFC5444], which is used with the following considerations: [RFC5444], which is used with the following considerations:
o This protocol specifies one Message Type, the HELLO message. o This protocol specifies one Message Type, the HELLO message.
o A HELLO message MAY use any combination of Message Header options o A HELLO message MAY use any combination of Message Header options
specified in [RFC5444]. specified in [RFC5444].
o HELLO messages MUST NOT be forwarded, i.e. a <msg-hop-limit>, if o HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if
present, MUST have the value 1. present, MUST have the value 1.
o HELLO messages MAY be included in multi-message packets as o HELLO messages MAY be included in multi-message packets as
specified in [RFC5444]. specified in [RFC5444].
o Received HELLO messages MUST be parsed in accordance with o Received HELLO messages MUST be parsed in accordance with
[RFC5444]. A HELLO message which is not in conformance with [RFC5444]. A HELLO message which is not in conformance with
[RFC5444] MUST be discarded without being processed. A HELLO [RFC5444] MUST be discarded without being processed. A HELLO
message can also be discarded without being processed for other message can also be discarded without being processed for other
reasons, see Section 12.1. reasons, see Section 12.1.
skipping to change at page 31, line 20 skipping to change at page 32, line 10
A HELLO message MAY contain: A HELLO message MAY contain:
o Other Message TLVs. o Other Message TLVs.
o One or more Address Blocks, each with an associated Address Block o One or more Address Blocks, each with an associated Address Block
TLV Block, which MAY contain other Address Block TLVs. TLV Block, which MAY contain other Address Block TLVs.
10.1.1. Address Blocks 10.1.1. Address Blocks
All network addresses in a router's Local Interface Set (i.e. in any All network addresses in a router's Local Interface Set (i.e., in any
I_local_iface_addr_list) MUST be represented as address objects (see I_local_iface_addr_list) MUST be represented as address objects (see
[RFC5444]), and included in the Address Blocks in all generated HELLO [RFC5444]), and included in the Address Blocks in all generated HELLO
messages, with the following permitted exception: messages, with the following permitted exception:
o If the MANET interface on which the HELLO message is to be sent o If the MANET interface on which the HELLO message is to be sent
has a single address with maximum prefix length (i.e. /32 for has a single address with maximum prefix length (i.e., /32 for
IPv4, /128 for IPv6), then that address MAY be omitted from being IPv4, /128 for IPv6), then that address MAY be omitted from being
included in any Address Block, provided that this address is included in any Address Block, provided that this address is
included as the sending address of the IP datagram in which the included as the sending address of the IP datagram in which the
HELLO message is included. HELLO message is included.
All network addresses of the router's interfaces included in any All network addresses of the router's interfaces included in any
Address Block(s) MUST be associated with an Address Block TLV with Address Block(s) MUST be associated with an Address Block TLV with
Type = LOCAL_IF, as defined in Table 1. Type = LOCAL_IF, as defined in Table 1.
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
skipping to change at page 32, line 34 skipping to change at page 33, line 34
Value = LOST also performs the function of an Address Block TLV with Value = LOST also performs the function of an Address Block TLV with
Type = OTHER_NEIGHB and the same Value. Including the latter Type = OTHER_NEIGHB and the same Value. Including the latter
associated with the same address object is discouraged for efficiency associated with the same address object is discouraged for efficiency
reasons. If an Address Block TLV with Type = LINK_STATUS and Value = reasons. If an Address Block TLV with Type = LINK_STATUS and Value =
SYMMETRIC is combined with an Address Block TLV with Type = SYMMETRIC is combined with an Address Block TLV with Type =
OTHER_NEIGHB and Value = LOST associated with the same address OTHER_NEIGHB and Value = LOST associated with the same address
object, then the latter MUST be ignored, and SHOULD NOT be included. object, then the latter MUST be ignored, and SHOULD NOT be included.
See Appendix A. See Appendix A.
Other network addresses MAY be represented as address objects (see Other network addresses MAY be represented as address objects (see
[RFC5444] and included in Address Blocks, but MUST NOT be associated [RFC5444]) and included in Address Blocks, but MUST NOT be associated
with any of the Address Block TLVs specified in this specification. with any of the Address Block TLVs specified in this specification.
11. HELLO Message Generation 11. HELLO Message Generation
Each MANET interface MUST generate HELLO messages according to the Each MANET interface MUST generate HELLO messages according to the
specification in this section. HELLO messages are generated for each specification in this section. HELLO messages are generated for each
MANET interface independently. HELLO message generation and MANET interface independently. HELLO message generation and
scheduling MUST be according to the interface parameters for that scheduling MUST be according to the interface parameters for that
MANET interface, and MAY be independent for each MANET interface or, MANET interface, and MAY be independent for each MANET interface or,
interface parameters permitting, MANET interfaces MAY use the same interface parameters permitting, MANET interfaces MAY use the same
skipping to change at page 33, line 14 skipping to change at page 34, line 14
11.1. HELLO Message Specification 11.1. HELLO Message Specification
HELLO messages are generated independently on each MANET interface. HELLO messages are generated independently on each MANET interface.
All network addresses in any I_local_iface_addr_list MUST be All network addresses in any I_local_iface_addr_list MUST be
included, represented as address objects (see [RFC5444]), except included, represented as address objects (see [RFC5444]), except
that: that:
o If the interface on which the HELLO message is to be sent has a o If the interface on which the HELLO message is to be sent has a
single address with maximum prefix length (i.e. /32 for IPv4, /128 single address with maximum prefix length (i.e., /32 for IPv4,
for IPv6) then that address MAY be omitted, provided that this /128 for IPv6) then that address MAY be omitted, provided that
address is included as the sending address of the IP datagram in this address is included as the sending address of the IP datagram
which the HELLO message is included. in which the HELLO message is included.
All such included address objects MUST be associated with an Address All such included address objects MUST be associated with an Address
Block TLV with Type := LOCAL_IF and Value according to the following: Block TLV with Type := LOCAL_IF and Value according to the following:
o If the address object represents a network address of the sending o If the address object represents a network address of the sending
MANET interface, then Value := THIS_IF. MANET interface, then Value := THIS_IF.
o Otherwise, Value := OTHER_IF. o Otherwise, Value := OTHER_IF.
If such a network address is included in more than one If such a network address is included in more than one
skipping to change at page 33, line 41 skipping to change at page 34, line 41
MUST be Value := THIS_IF if the address object represents a network MUST be Value := THIS_IF if the address object represents a network
address of the sending MANET interface. address of the sending MANET interface.
The following network addresses of current or former 1-hop neighbors The following network addresses of current or former 1-hop neighbors
MAY be represented as address objects (see [RFC5444]) and included in MAY be represented as address objects (see [RFC5444]) and included in
any HELLO message, respecting the parameter REFRESH_INTERVAL for each any HELLO message, respecting the parameter REFRESH_INTERVAL for each
association for that MANET interface, and according to the following: association for that MANET interface, and according to the following:
o Network addresses of MANET interfaces of 1-hop neighbors from the o Network addresses of MANET interfaces of 1-hop neighbors from the
Link Set of the Interface Information Base for this MANET Link Set of the Interface Information Base for this MANET
interface (i.e. from an L_neighbor_iface_addr_list), other than interface (i.e., from an L_neighbor_iface_addr_list), other than
those from Link Tuples with L_status = PENDING. those from Link Tuples with L_status = PENDING.
o Other network addresses of symmetric 1-hop neighbors from the o Other network addresses of symmetric 1-hop neighbors from the
Neighbor Set of this router's Neighbor Information Base (i.e. from Neighbor Set of this router's Neighbor Information Base (i.e.,
an N_neighbor_addr_list). from an N_neighbor_addr_list).
o Network addresses of MANET interfaces of previously symmetric or o Network addresses of MANET interfaces of previously symmetric or
heard 1-hop neighbors connected on this MANET interface from the heard 1-hop neighbors connected on this MANET interface from the
Link Set of the Interface Information Base for this MANET Link Set of the Interface Information Base for this MANET
interface (i.e. from an L_neighbor_iface_addr_list with L_status = interface (i.e., from an L_neighbor_iface_addr_list with L_status
LOST). = LOST).
o Other network addresses of previously symmetric 1-hop neighbors o Other network addresses of previously symmetric 1-hop neighbors
from the Lost Neighbor Set of this router's Neighbor Information from the Lost Neighbor Set of this router's Neighbor Information
Base (i.e. from an NL_neighbor_addr). Base (i.e., from an NL_neighbor_addr).
Each such address object (see [RFC5444]) MUST be associated with one Each such address object (see [RFC5444]) MUST be associated with one
or more appropriate Address Block TLVs. Specifically: or more appropriate Address Block TLVs. Specifically:
1. For each address object (henceforth linked address) which 1. For each address object (henceforth linked address) 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:
skipping to change at page 34, line 47 skipping to change at page 35, line 47
* Type := OTHER_NEIGHB; AND * Type := OTHER_NEIGHB; AND
* Value := LOST. * 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, MUST 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
of a 1-hop neighbor is specified with more than one associated of a 1-hop neighbor is specified with more than one associated
Address Block TLV, then these Address Block TLVs MAY be independently Address Block TLV, then these Address Block TLVs MAY be independently
included or excluded from each HELLO message. Each such Address included or excluded from each HELLO message. Each such Address
Block TLV MUST be included associated with the address object Block TLV MUST be included associated with the address object
representation of that network address in a HELLO message sent on representation of that network address in a HELLO message sent on
that MANET interface in every interval of length equal to that MANET that MANET interface in every interval of length equal to that MANET
interface's parameter REFRESH_INTERVAL. Address Block TLVs interface's parameter REFRESH_INTERVAL. Address Block TLVs
associated with the same address object included in the same HELLO associated with the same address object included in the same HELLO
message MAY be applied to the same or different copies of that message MAY be applied to the same or different copies of that
address object. address object.
An implementation of this protocol MAY limit the information included
in each HELLO message, for example to acommodate smaller MTU sizes.
HELLO messages remain constrained by the above requirements, in
particular that all local interface information MUST be included in
all HELLO messages, and that all neighbor information MUST be sent
within each interval of length REFRESH_INTERVAL. This neighbor
information MAY, however, be sent in the same or in different HELLO
messages.
11.2. HELLO Message Transmission 11.2. HELLO Message Transmission
HELLO messages are transmitted in the format specified by [RFC5444]. HELLO messages are transmitted in the format specified by [RFC5444].
11.2.1. HELLO Message Jitter 11.2.1. HELLO Message Jitter
HELLO messages MAY be sent using periodic message generation or HELLO messages MAY be sent using periodic message generation or
externally triggered message generation. If using data link and externally triggered message generation. If using data link and
physical layers which are subject to packet loss due to collisions, physical layers which are subject to packet loss due to collisions,
HELLO messages SHOULD be jittered as described in [RFC5148]. HELLO messages SHOULD be jittered as described in [RFC5148].
skipping to change at page 36, line 27 skipping to change at page 37, line 36
12.1. Invalid Message 12.1. Invalid Message
A received HELLO message is invalid for processing by this router if A received HELLO message is invalid for processing by this router if
any of the following conditions are true: any of the following conditions are true:
o The address length as specified in the Message Header is not equal o The address length as specified in the Message Header is not equal
to the length of the addresses used by this router. to the length of the addresses used by this router.
o The message has a <msg-hop-limit> field in its Message Header with o The message has a <msg-hop-limit> field in its Message Header with
a value other than one. (Note that the message need not have a a value other than one. (Note that the message does not need to
<msg-hop-limit> field.) have a <msg-hop-limit> field.)
o The message has a <msg-hop-count> field in its Message Header with o The message has a <msg-hop-count> field in its Message Header with
a value other than zero. (Note that the message need not have a a value other than zero. (Note that the message does not need to
<msg-hop-count> field.) have a <msg-hop-count> field.)
o The message does not have a Message TLV with Type = VALIDITY_TIME o The message does not have a Message TLV with Type = VALIDITY_TIME
in its Message TLV Block. in its Message TLV Block.
o The message has more than one Message TLV with Type = o The message has more than one Message TLV with Type =
VALIDITY_TIME in its Message TLV Block. VALIDITY_TIME in its Message TLV Block.
o The message has more than one Message TLV with Type = o The message has more than one Message TLV with Type =
INTERVAL_TIME in its Message TLV Block. INTERVAL_TIME in its Message TLV Block.
skipping to change at page 37, line 8 skipping to change at page 38, line 16
any single Value v such that v != THIS_IF and v != OTHER_IF. any single Value v such that v != THIS_IF and v != OTHER_IF.
o Any address object (including different address objects o Any address object (including different address objects
representing the same network address, in the same or different representing the same network address, in the same or different
Address Blocks) is associated with more than one Value by one or Address Blocks) is associated with more than one Value by one or
more Address Block TLV(s) with Type = LOCAL_IF. more Address Block TLV(s) with Type = LOCAL_IF.
o Any address object (henceforth local address) associated with an o Any address object (henceforth local address) associated with an
Address Block TLV with Type = LOCAL_IF represents one of the Address Block TLV with Type = LOCAL_IF represents one of the
receiving router's current or recently used network addresses receiving router's current or recently used network addresses
(i.e. local address overlaps any network address in any (i.e., local address overlaps any network address in any
I_local_iface_addr_list in the Local Interface Set or any I_local_iface_addr_list in the Local Interface Set or any
IR_local_iface_addr in the Removed Interface Address Set). IR_local_iface_addr in the Removed Interface Address Set).
o The message has any Address Block TLV(s) with Type = LINK_STATUS o The message has any Address Block TLV(s) with Type = LINK_STATUS
with any single Value v such that v != LOST, v != SYMMETRIC, and v with any single Value v such that v != LOST, v != SYMMETRIC, and v
!= HEARD. != HEARD.
o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB
with any single Value v such that v != LOST and v != SYMMETRIC. with any single Value v such that v != LOST and v != SYMMETRIC.
skipping to change at page 37, line 40 skipping to change at page 38, line 48
object, in the same or different Address Blocks) is associated object, in the same or different Address Blocks) is associated
with more than one Value by one or more Address Block TLVs with with more than one Value by one or more Address Block TLVs with
Type = LINK_STATUS. Type = LINK_STATUS.
o Any address object (including different copies of an address o Any address object (including different copies of an address
object, in the same or different Address Blocks) is associated object, in the same or different Address Blocks) is associated
with more than one Value by one or more Address Block TLVs with with more than one Value by one or more Address Block TLVs with
Type = OTHER_NEIGHB. Type = OTHER_NEIGHB.
A router MAY recognize additional reasons for identifying that a A router MAY recognize additional reasons for identifying that a
message is badly formed and therefore invalid for processing, e.g. to message is badly formed and therefore invalid for processing, e.g.,
allow a security protocol as suggested in Section 17 to perform to allow a security protocol as suggested in Section 17 to perform
verification of HELLO message signatures and prevent processing of verification of HELLO message signatures and prevent processing of
unverifiable HELLO messages by this protocol. unverifiable HELLO messages by this protocol.
An invalid message MUST be silently discarded, without updating the An invalid message MUST be silently discarded, without updating the
router's Information Bases. router's Information Bases.
12.2. Definitions 12.2. Definitions
For the purpose of this section, note the following definitions: For the purpose of this section, note the following definitions:
skipping to change at page 38, line 17 skipping to change at page 39, line 24
(Note that, as specified by Section 12.1, there must be exactly (Note that, as specified by Section 12.1, there must be exactly
one such Message TLV in the HELLO message.) All information in one such Message TLV in the HELLO message.) All information in
the HELLO message used by this specification has the same validity the HELLO message used by this specification has the same validity
time. time.
o "Receiving Address List" is the I_local_iface_addr_list o "Receiving Address List" is the I_local_iface_addr_list
corresponding to the MANET interface on which the HELLO message corresponding to the MANET interface on which the HELLO message
was received was received
o "Sending Address List" is an unordered list of network addresses o "Sending Address List" is an unordered list of network addresses
of the MANET interface over which the HELLO message was sent, i.e. of the MANET interface over which the HELLO message was sent,
is an unordered list of the network addresses represented by i.e., is an unordered list of the network addresses represented by
address objects contained in the HELLO message with an associated address objects contained in the HELLO message with an associated
Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If
the Sending Address List is otherwise empty, then the Sending the Sending Address List is otherwise empty, then the Sending
Address List contains a single network address with maximum prefix Address List contains a single network address with maximum prefix
length (i.e. /32 for IPv64, /128 for IPv6) with address equal to length (i.e., /32 for IPv64, /128 for IPv6) with address equal to
the sending address of the IP datagram in which the HELLO message the sending address of the IP datagram in which the HELLO message
was included. was included.
o "Neighbor Address List" is an unordered list of all the network o "Neighbor Address List" is an unordered list of all the network
addresses of all the interfaces of the router which generated the addresses of all the interfaces of the router which generated the
HELLO message, i.e. is the Sending Address List, plus the network HELLO message, i.e., is the Sending Address List, plus the network
addresses represented by address objects contained in the HELLO addresses represented by address objects contained in the HELLO
message with an associated Address Block TLV with Type = LOCAL_IF message with an associated Address Block TLV with Type = LOCAL_IF
and Value = OTHER_IF. and Value = OTHER_IF.
o "EXPIRED" indicates that a timer is set to a value clearly o "EXPIRED" indicates that a timer is set to a value clearly
preceding the current time (e.g., current time - 1). preceding the current time (e.g., , current time - 1).
o "Removed Address List" is a list of network addresses created by o "Removed Address List" is a list of network addresses created by
this HELLO message processing which were formerly reported as this HELLO message processing which were formerly reported as
local by the router originating the HELLO message, but which are local by the router originating the HELLO message, but which are
not included in the Neighbor Address List. This list is not included in the Neighbor Address List. This list is
initialized as empty. initialized as empty.
o "Lost Address List" is a subset of the Removed Address List o "Lost Address List" is a subset of the Removed Address List
containing network addresses which were formerly considered as containing network addresses which were formerly considered as
symmetric. This list is initialized as empty. symmetric. This list is initialized as empty.
skipping to change at page 46, line 4 skipping to change at page 47, line 10
* L_HEARD_time is not expired; * L_HEARD_time is not expired;
then remove the Neighbor Tuple. then remove the Neighbor Tuple.
14. Link Quality 14. Link Quality
Link quality is a mechanism whereby a router MAY take considerations Link quality is a mechanism whereby a router MAY take considerations
other than message exchange into account for determining when a link other than message exchange into account for determining when a link
is and is not a candidate for being considered as HEARD or SYMMETRIC. is and is not a candidate for being considered as HEARD or SYMMETRIC.
As such, it is a "link admission" mechanism. As such, it is a "link admission" mechanism.
Link quality information for a link is generated (e.g., through Link quality information for a link is generated (e.g., through
access to signal to noise ratio, packet loss rate, or other access to signal to noise ratio, packet loss rate, or other
information from the link layer) and used only locally, i.e. is not information from the link layer) and used only locally, i.e., is not
included in signaling, and routers may interoperate whether they are included in signaling, and routers may interoperate whether they are
using the same, different, or no, link quality information. using the same, different, or no, link quality information.
For deployments where no link quality is used, the considerations in For deployments where no link quality is used, the considerations in
Section 14.1 apply. For deployments where link quality is used, the Section 14.1 apply. For deployments where link quality is used, the
general principles of link quality usage are described in general principles of link quality usage are described in
Section 14.2. Section 14.3 and Section 14.4 detail link quality Section 14.2. Section 14.3 and Section 14.4 detail link quality
functioning. functioning.
14.1. Deployment Without Link Quality 14.1. Deployment Without Link Quality
skipping to change at page 48, line 22 skipping to change at page 49, line 27
containing it, creates the Link Tuple, then the Link Tuple MUST be containing it, creates the Link Tuple, then the Link Tuple MUST be
created with the appropriately updated L_quality value, rather than created with the appropriately updated L_quality value, rather than
with L_quality := INITIAL_QUALITY.) with L_quality := INITIAL_QUALITY.)
14.4. Updating Link Quality 14.4. Updating Link Quality
A router MAY update link quality based on any information available A router MAY update link quality based on any information available
to it. Particular cases that MAY be used include: to it. Particular cases that MAY be used include:
o Information from the link layer, such as signal to noise ratio or o Information from the link layer, such as signal to noise ratio or
packet acknowledgement reception and loss information. packet acknowledgment reception and loss information.
o Receipt or loss of control packets. If control packets include a o Receipt or loss of control packets. If control packets include a
sequential packet sequence number, as defined in [RFC5444], then sequential packet sequence number, as defined in [RFC5444], then
link quality can be updated when a control packet is received, link quality can be updated when a control packet is received,
whether or not it contains a HELLO message. The link quality may whether or not it contains a HELLO message. The link quality may
then, for example, be based on whether the last N out of M control then, for example, be based on whether the last N out of M control
packets on the link were received, or may use a "leaky integrator" packets on the link were received, or may use a "leaky integrator"
tracking packet reception and loss. tracking packet reception and loss.
o Receipt or loss of HELLO messages. If the maximum interval o Receipt or loss of HELLO messages. If the maximum interval
skipping to change at page 48, line 44 skipping to change at page 49, line 49
messages of a Message TLV with Type := INTERVAL_TIME, as defined messages of a Message TLV with Type := INTERVAL_TIME, as defined
in [RFC5497]) then the loss of HELLO messages can be determined in [RFC5497]) then the loss of HELLO messages can be determined
without the need to receive a later HELLO message. Note that if without the need to receive a later HELLO message. Note that if
this case is combined with the previous case then care must be this case is combined with the previous case then care must be
taken to avoid "double counting" a lost HELLO message in a lost taken to avoid "double counting" a lost HELLO message in a lost
packet. packet.
15. Proposed Values for Parameters and Constants 15. Proposed Values for Parameters and Constants
This section lists the parameters and constants used in the This section lists the parameters and constants used in the
specification of the protocol, and proposed values of each which may specification of the protocol, and proposed values of each which MAY
be used when a single value of each is used. be used when a single value of each is used.
15.1. Message Interval Interface Parameters 15.1. Message Interval Interface Parameters
o HELLO_INTERVAL := 2 seconds o HELLO_INTERVAL := 2 seconds
o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4 o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4
o REFRESH_INTERVAL := HELLO_INTERVAL o REFRESH_INTERVAL := HELLO_INTERVAL
15.2. Information Validity Time Interface Parameters 15.2. Information Validity Time Interface Parameters
o H_HOLD_TIME := 3 x REFRESH_INTERVAL o H_HOLD_TIME := 3 x REFRESH_INTERVAL
o L_HOLD_TIME := H_HOLD_TIME o L_HOLD_TIME := H_HOLD_TIME
skipping to change at page 50, line 11 skipping to change at page 51, line 15
o Through accessing, and possibly extending, the information in the o Through accessing, and possibly extending, the information in the
Local Information Base (Section 6), the Interface Information Base Local Information Base (Section 6), the Interface Information Base
(Section 7) and the Neighbor Information Base (Section 8). These (Section 7) and the Neighbor Information Base (Section 8). These
Information Bases record the interface configuration of the Information Bases record the interface configuration of the
router, as well as the local connectivity, up to two hops away. router, as well as the local connectivity, up to two hops away.
All updates to the elements specified in this document are subject All updates to the elements specified in this document are subject
to the constraints specified in Appendix B. to the constraints specified in Appendix B.
o Through accessing an outgoing HELLO message prior to it being o Through accessing an outgoing HELLO message prior to it being
transmitted over any MANET interface, and to add information transmitted over any MANET interface, and to add information
(e.g., TLVs) as specified in [RFC5444]. This may, for example, be (e.g., , TLVs) as specified in [RFC5444]. This may, for example,
to allow a security protocol, as suggested in Section 17, to add a be to allow a security protocol, as suggested in Section 17, to
TLV containing a cryptographic signature to the message, or be to add a TLV containing a cryptographic signature to the message, or
allow inserting relay selection information into a HELLO message be to allow inserting relay selection information into a HELLO
by way of adding a TLV to an outgoing HELLO message prior to it message by way of adding a TLV to an outgoing HELLO message prior
being transmitted. to it being transmitted.
o Through accessing an incoming HELLO message, and potentially o Through accessing an incoming HELLO message, and potentially
discarding it prior to processing by this protocol. This may, for discarding it prior to processing by this protocol. This may, for
example, allow a security protocol as suggested in Section 17 to example, allow a security protocol as suggested in Section 17 to
perform verification of HELLO message signatures and prevent perform verification of HELLO message signatures and prevent
processing of unverifiable HELLO messages by this protocol. processing of unverifiable HELLO messages by this protocol.
o Through accessing an incoming HELLO message after it has been o Through accessing an incoming HELLO message after it has been
completely processed by this protocol. This may, in particular, completely processed by this protocol. This may, in particular,
allow a protocol which has added information, such as relay allow a protocol which has added information, such as relay
skipping to change at page 51, line 33 skipping to change at page 52, line 37
Address Block does not have any Address Block TLVs associated, that Address Block does not have any Address Block TLVs associated, that
address object has no semantics. Consequently, all protocols using address object has no semantics. Consequently, all protocols using
the protocol defined in this specification MUST respect the the protocol defined in this specification MUST respect the
following: following:
o An address object in an Address Block, which is not associated o An address object in an Address Block, which is not associated
with any Address Block TLV, MUST be silently ignored; the mere with any Address Block TLV, MUST be silently ignored; the mere
presence of an address object without an associated Address Block presence of an address object without an associated Address Block
TLV in a HELLO message MUST NOT cause any processing. TLV in a HELLO message MUST NOT cause any processing.
Strict adherence to this enables unambiguous co-existence of future A protocol interacting with this protocol MAY also add an originator
"extensions" to HELLO messages. address to HELLO messages, as specified in [RFC5444]. Such an
originator address MUST be unique to the originating router, it MAY
be a local interface address of the router. It SHOULD be used
consistently, but SHOULD NOT be constrained in any other way.
Strict adherence to these points will enable unambiguous co-existence
of future "extensions" to HELLO messages.
In some cases, a protocol interacting with the protocol defined in In some cases, a protocol interacting with the protocol defined in
this specification, may need to recognize which HELLO messages to this specification, may need to recognize which HELLO messages to
process and which HELLO messages to discard. It is the process and which HELLO messages to discard. It is the
responsibility of that protocol to ensure that such messages are responsibility of that protocol to ensure that such messages are
suitably identifiable, e.g. through inclusion of a Message TLV or suitably identifiable, e.g., through inclusion of a Message TLV or
through recognizing an administrative configuration (such as address through recognizing an administrative configuration (such as address
ranges). Note that such a protocol interacting with this protocol ranges). Note that such a protocol interacting with this protocol
MAY specify such interaction by recognizing an additional reason for MAY specify such interaction by recognizing an additional reason for
discarding a message. As suggested in Section 17 this might, for discarding a message. As suggested in Section 17 this might, for
example, be a security protocol discarding a message which does not example, be a security protocol discarding a message which does not
carry a Message TLV containing a cryptographic signature. carry a Message TLV containing a cryptographic signature.
17. Security Considerations 17. Security Considerations
The objective of this protocol is to allow each router in the network The objective of this protocol is to allow each router in the network
to acquire information describing its 1-hop neighborhood and to acquire information describing its 1-hop neighborhood and
symmetric 2-hop neighborhood. This is acquired through HELLO message symmetric 2-hop neighborhood. This is acquired through HELLO message
exchange between neighboring routers. This information is made exchange between neighboring routers. This information is made
available through the Interface Information Bases and Neighbor available through the Interface Information Bases and Neighbor
Information Base, describing the router's 1-hop neighborhood and Information Base, describing the router's 1-hop neighborhood and
symmetric 2-hop neighborhood. symmetric 2-hop neighborhood.
Under normal circumstances, the information recorded in these Under normal circumstances, the information recorded in these
Information Bases is correct, i.e. corresponds to the actual network Information Bases is correct, i.e., corresponds to the actual network
topology, apart from any changes which have not (yet) been tracked by topology, apart from any changes which have not (yet) been tracked by
the HELLO message exchanges. the HELLO message exchanges.
If a router for some reason, whether malice or malfunction, transmits If a router for some reason, whether malice or malfunction, transmits
invalid HELLO messages, incorrect information may be recorded in invalid HELLO messages, incorrect information may be recorded in
other routers' Information Bases. This protocol specification does, other routers' Information Bases. This protocol specification does,
however, prevent inconsistent information from being included in the however, prevent inconsistent information from being included in the
Information Bases through the specified processing, which maintains Information Bases through the specified processing, which maintains
the constraints in Appendix B. The exact consequence of information the constraints in Appendix B. The exact consequence of information
inexactness depends on the use of these Information Bases, and SHOULD inexactness depends on the use of these Information Bases, and SHOULD
skipping to change at page 53, line 16 skipping to change at page 54, line 25
message "has the right key" but also the precise identity of the message "has the right key" but also the precise identity of the
originator may be required to be proved, and computational resources originator may be required to be proved, and computational resources
may be available to make such a requirement feasible. may be available to make such a requirement feasible.
Section 17.2, therefore, does not specify a single "one-size-fits- Section 17.2, therefore, does not specify a single "one-size-fits-
all" mechanism, but rather details how the security suggestions in all" mechanism, but rather details how the security suggestions in
[RFC5444] are considered for applicability within the context of this [RFC5444] are considered for applicability within the context of this
protocol, and with the purpose of aiding deployment-specific security protocol, and with the purpose of aiding deployment-specific security
mechanisms to be developed. mechanisms to be developed.
17.1. Invalid HELLO messages 17.1. Invalid HELLO Messages
A correctly formed, but still invalid, HELLO message may take any of A correctly formed, but still invalid, HELLO message may take any of
the following forms. Note that a present or absent address object in the following forms. Note that a present or absent address object in
an Address Block, does not by itself cause a problem. It is the an Address Block, does not by itself cause a problem. It is the
presence, absence, or incorrectness of associated LOCAL_IF, presence, absence, or incorrectness of associated LOCAL_IF,
LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems. LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems.
A router may provide false information about its own identity: A router may provide false information about its own identity:
* The HELLO message may contain address objects with an * The HELLO message may contain address objects with an
skipping to change at page 54, line 12 skipping to change at page 55, line 20
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, * 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, * 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, * 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 * The Value of a LINK_STATUS Address Block TLV may incorrectly
indicate the status (LOST, SYMMETRIC or HEARD) of the link from indicate the status (LOST, SYMMETRIC or HEARD) of the link from
a 1-hop neighbor. a 1-hop neighbor.
* The Value of an OTHER_NEIGHB Address Block TLV may incorrectly * The Value of an OTHER_NEIGHB Address Block TLV may incorrectly
indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop
neighbor. neighbor.
17.2. Authentication, Integrity and Confidentiality Suggestions 17.2. Authentication, Integrity and Confidentiality Suggestions
skipping to change at page 55, line 18 skipping to change at page 56, line 27
For the registries where an Expert Review is required, the designated For the registries where an Expert Review is required, the designated
expert SHOULD take the same general recommendations into expert SHOULD take the same general recommendations into
consideration as are specified by [RFC5444]. consideration as are specified by [RFC5444].
18.2. Message Types 18.2. Message Types
This specification defines one Message Type, to be allocated from the This specification defines one Message Type, to be allocated from the
0-223 range of the "Message Types" namespace defined in [RFC5444], as 0-223 range of the "Message Types" namespace defined in [RFC5444], as
specified in Table 3. specified in Table 3.
+-------+------+-----------------+ +------+-------------------------+
| Name | Type | Description | | Type | Description |
+-------+------+-----------------+ +------+-------------------------+
| HELLO | TBD1 | Local signaling | | TBD1 | HELLO : Local signaling |
+-------+------+-----------------+ +------+-------------------------+
Table 3: Message Type assignment Table 3: Message Type assignment
18.3. Message-Type-specific TLV Type Registries 18.3. Message-Type-Specific TLV Type Registries
IANA is requested to create a registry for Message-Type-specific IANA is requested to create a registry for Message-Type-specific
Message TLVs for HELLO messages, in accordance with Section 6.2.1 of Message TLVs for HELLO messages, in accordance with Section 6.2.1 of
[RFC5444], and with initial assignments and allocation policies as [RFC5444], and with initial assignments and allocation policies as
specified in Table 4. specified in Table 4.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review | | 128-223 | Unassigned | Expert Review |
skipping to change at page 56, line 17 skipping to change at page 57, line 24
18.4. Address Block TLV Types 18.4. Address Block TLV Types
This specification defines three Address Block TLV Types, which must This specification defines three Address Block TLV Types, which must
be allocated from the "Address Block TLV Types" namespace defined in be allocated from the "Address Block TLV Types" namespace defined in
[RFC5444]. IANA are requested to make allocations in the 0-127 range [RFC5444]. IANA are requested to make allocations in the 0-127 range
for these types. This will create three new type extension for these types. This will create three new type extension
registries with assignments as specified in Table 6, Table 7 and registries with assignments as specified in Table 6, Table 7 and
Table 8. Specifications of these Address Block TLVs are in Table 8. Specifications of these Address Block TLVs are in
Section 10.1.1, with Value Constants defined in Section 18.5. Section 10.1.1, with Value Constants defined in Section 18.5.
+------------+------+-----------+-----------------------------------+ +----------+------+-----------+------------------------+------------+
| Name | Type | Type | Description | | Name | Type | Type | Description | Allocation |
| | | extension | | | | | extension | | policy |
+------------+------+-----------+-----------------------------------+ +----------+------+-----------+------------------------+------------+
| LOCAL_IF | TBD2 | 0 | Specifies that the network | | LOCAL_IF | TBD2 | 0 | Specifies that the | |
| | | | address is associated with a | | | | | network address is | |
| | | | local interface of the sending | | | | | associated with this | |
| | | | router | | | | | local interface of the | |
| Unassigned | TBD2 | 1-255 | Expert Review | | | | | sending router | |
+------------+------+-----------+-----------------------------------+ | | | | (THIS_IF = 0) or | |
| | | | another local | |
| | | | interface of the | |
| | | | sending router | |
| | | | (OTHER_IF = 1) | |
| LOCAL_IF | TBD2 | 1-255 | Unassigned | Expert |
| | | | | Review |
+----------+------+-----------+------------------------+------------+
Table 6: Address Block TLV Type assignment: LOCAL_IF Table 6: Address Block TLV Type assignment: LOCAL_IF
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | | Name | Type | Type | Description | Allocation |
| | | extension | | | | | extension | | policy |
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+---------------------+------------+
| LINK_STATUS | TBD3 | 0 | Specifies the status of the link | | LINK_STATUS | TBD3 | 0 | Specifies the | |
| | | | from the indicated network | | | | | status of the link | |
| | | | address (LOST, SYMMETRIC or | | | | | from the indicated | |
| | | | HEARD) | | | | | network address | |
| Unassigned | TBD3 | 1-255 | Expert Review | | | | | (LOST = 0, | |
+-------------+------+-----------+----------------------------------+ | | | | SYMMETRIC = 1, or | |
| | | | HEARD = 2) | |
| LINK_STATUS | TBD3 | 1-255 | Unassigned | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
Table 7: Address Block TLV Type assignment: LINK_STATUS Table 7: Address Block TLV Type assignment: LINK_STATUS
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | | Name | Type | Type | Description | Allocation |
| | | extension | | | | | extension | | policy |
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+--------------------+------------+
| OTHER_NEIGHB | TBD4 | 0 | Specifies that the network | | OTHER_NEIGHB | TBD4 | 0 | Specifies that the | |
| | | | address is (SYMMETRIC) or | | | | | network address is | |
| | | | recently was (LOST) of an | | | | | (SYMMETRIC = 1) or | |
| | | | interface of a symmetric 1-hop | | | | | recently was (LOST | |
| | | | neighbor of the router | | | | | = 0) of an | |
| | | | transmitting the message | | | | | interface of a | |
| Unassigned | TBD4 | 1-255 | Expert Review | | | | | symmetric 1-hop | |
+--------------+------+-----------+---------------------------------+ | | | | neighbor of the | |
| | | | router | |
| | | | transmitting the | |
| | | | message | |
| OTHER_NEIGHB | TBD4 | 1-255 | Unassigned | Expert |
| | | | | Review |
+--------------+------+-----------+--------------------+------------+
Table 8: Address Block TLV Type assignment: OTHER_NEIGHB Table 8: Address Block TLV Type assignment: OTHER_NEIGHB
18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values 18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values
Note: This section does not require any IANA action, as the required
information is included in the descriptions of the Address Block TLVs
allocated in Section 18.4. This information is recorded here for
clarity, and for use elsewhere in this specification.
The Values which the LOCAL_IF Address Block TLV can use are the The Values which the LOCAL_IF Address Block TLV can use are the
following: following:
o THIS_IF := 0 o THIS_IF := 0
o OTHER_IF := 1 o OTHER_IF := 1
The Values which the LINK_STATUS Address Block TLV can use are the The Values which the LINK_STATUS Address Block TLV can use are the
following: following:
skipping to change at page 58, line 15 skipping to change at page 59, line 43
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org> o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil> o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems ATC, UK, o Christopher Dearlove, BAE Systems ATC, UK,
<chris.dearlove@baesystems.com> <chris.dearlove@baesystems.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
20. Acknowledgements 20. Acknowledgments
The authors would like to acknowledge the team behind OLSRv1, The authors would like to acknowledge the team behind OLSRv1,
specified in RFC3626 for their contributions. specified in RFC3626 for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components (listed alphabetically): Alan Cullen specification and its components (listed alphabetically): Alan Cullen
(BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe
Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA), Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA),
and the entire IETF MANET working group. and the entire IETF MANET working group.
skipping to change at page 60, line 45 skipping to change at page 62, line 6
o I_local_iface_addr_list MUST NOT be empty. o I_local_iface_addr_list MUST NOT be empty.
o I_local_iface_addr_list MUST NOT contain any duplicated network o I_local_iface_addr_list MUST NOT contain any duplicated network
addresses. addresses.
o If I_manet = true, then I_local_iface_addr_list MUST NOT contain o If I_manet = true, then I_local_iface_addr_list MUST NOT contain
any network address which overlaps any network address in the any network address which overlaps any network address in the
I_local_iface_addr_list of any other Local Interface Tuple with I_local_iface_addr_list of any other Local Interface Tuple with
I_manet = true, unless it is known that the corresponding MANET I_manet = true, unless it is known that the corresponding MANET
interfaces will ALWAYS communicate with separate sets of MANET interfaces will always communicate with separate sets of MANET
interfaces on other routers. interfaces on other routers.
In each Removed Interface Address Tuple: In each Removed Interface Address Tuple:
o IR_local_iface_addr MUST NOT contain any network address which is o IR_local_iface_addr MUST NOT contain any network address which is
in the I_local_iface_addr_list of any Local Interface Tuple. in the I_local_iface_addr_list of any Local Interface Tuple.
o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
other Removed Interface Address Tuple. other Removed Interface Address Tuple.
skipping to change at page 63, line 7 skipping to change at page 64, line 18
o N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple o N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple
in the same 2-Hop Set and with the same in the same 2-Hop Set and with the same
N2_neighbor_iface_addr_list. N2_neighbor_iface_addr_list.
o N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the o N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the
same 2-Hop Tuple. same 2-Hop Tuple.
Appendix C. HELLO Message Example Appendix C. HELLO Message Example
An example HELLO message, transmitted by an originating router with a HELLO messages are instances of [RFC5444] messages, and this protocol
single MANET interface, is as follows. supports any combination of message header options and address
encodings, enabled by [RFC5444] that convey the required information.
As a consequence, there is no single way to represent how all HELLO
messages look. This appendix illustrates two HELLO message with
similar content, the exact values included are explained in the
following text.
The message has Message Header containing hop-limit, hop-count and The message has Message Header containing hop-limit, hop-count and
message sequence number (four bit Flags field value is 14). Its four message sequence number (four bit Flags field value is 14). Its four
bit Message Address Length field has value 3 and hence addresses in bit Message Address Length field has value 3 and hence addresses in
the message have length four octets, here being IPv4 addresses. The the message have length four octets, here being IPv4 addresses. The
message is as transmitted with a hop limit of 1 and a hop count of 0. message is as transmitted with a hop limit of 1 and a hop count of 0.
The overall message length is 45 octets. 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
skipping to change at page 63, line 34 skipping to change at page 64, line 50
default value of constant C (1/1024 second). 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, Flags octet value 128 indicates an address Head but no address Tail,
and no address prefixes. The Head Length of 3 octets indicates and no address prefixes. The Head Length of 3 octets indicates
address Mid sections of one octet each (Mid 0 to Mid 4). 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 which (with Flags octet value 80) indicates that a single
address, with index 0 (i.e. Head:Mid 0) is the single local address, with index 0 (i.e., Head:Mid 0) is the single local
interface address of this router (the 1 octet Value THIS_IF indicates interface address of this router (the 1 octet Value THIS_IF indicates
that this address is of this interface). The second is a LINK_STATUS that this address is of this interface). The second is a LINK_STATUS
Address Block TLV which (with Flags octet value 48) specifies the Address Block TLV which (with Flags octet value 48) specifies the
link status values of all reported neighbors in a single multivalue link status values of all reported neighbors in a single multivalue
Address Block TLV which covers the addresses with indexes 1 to 4. Address Block TLV which covers the addresses with indexes 1 to 4.
The Address Block TLV Value Length of 4 octets indicates one octet The Address Block TLV Value Length of 4 octets indicates one octet
per Value per address. The last four addresses have associated link per Value per address. The last four addresses have associated link
status, the first and second HEARD, the third SYMMETRIC, and the status, the first and second HEARD, the third SYMMETRIC, and the
fourth LOST. 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 1 0 0 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number | |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0| |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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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| |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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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| |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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head | |0 0 0 0 0 0 1 1| Head |
skipping to change at page 68, line 15 skipping to change at page 69, line 15
router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO
message emission rate. Hence, for each HELLO message transmission, a message emission rate. Hence, for each HELLO message transmission, a
router must wait at least HELLO_MIN_INTERVAL before the next HELLO router must wait at least HELLO_MIN_INTERVAL before the next HELLO
message transmission. Similarly, the maximum interval between two message transmission. Similarly, the maximum interval between two
successive HELLO message transmissions is HELLO_INTERVAL, setting a successive HELLO message transmissions is HELLO_INTERVAL, setting a
lower bound on the message transmission rate. Hence, for each HELLO lower bound on the message transmission rate. Hence, for each HELLO
message transmission, the router must ensure that the next HELLO message transmission, the router must ensure that the next HELLO
message transmission must not wait more than HELLO_INTERVAL. message transmission must not wait more than HELLO_INTERVAL.
Figure 3 illustrates a message schedule similar to Figure 1, but with Figure 3 illustrates a message schedule similar to Figure 1, but with
HELLO messages responding to events at maximum rate, i.e. with HELLO HELLO messages responding to events at maximum rate, i.e., with HELLO
messages being sent each HELLO_MIN_INTERVAL. Note that when a HELLO messages being sent each HELLO_MIN_INTERVAL. Note that when a HELLO
message is sent, it is assumed that the following messages may all be message is sent, it is assumed that the following messages may all be
scheduled at an interval of HELLO_INTERVAL, and hence each HELLO scheduled at an interval of HELLO_INTERVAL, and hence each HELLO
message contains all 1-hop neighbor network addresses. In each HELLO message contains all 1-hop neighbor network addresses. In each HELLO
message in this example, a new 1-hop neighbor network address is message in this example, a new 1-hop neighbor network address is
added, reflecting the changes occurring since the last HELLO message added, reflecting the changes occurring since the last HELLO message
was sent. HELLO messages are sent at the maximum allowed rate in was sent. HELLO messages are sent at the maximum allowed rate in
order to signal these changes as rapidly as possible. order to signal these changes as rapidly as possible.
H_HOLD_TIME: |-----------------------------| ... H_HOLD_TIME: |-----------------------------| ...
skipping to change at page 71, line 20 skipping to change at page 72, line 20
REFRESH_INTERVAL: |----------------| REFRESH_INTERVAL: |----------------|
HELLO_INTERVAL: |----------| HELLO_INTERVAL: |----------|
HELLO_MIN_INTERVAL: |---| HELLO_MIN_INTERVAL: |---|
Time: -----------------------------------------------> Time: ----------------------------------------------->
^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | |
| | | | Time until which | | | | Time up to which
HELLO message | | | received HELLO HELLO message | | | received HELLO
transmission | | | message content transmission | | | message content
| | | is valid. | | | is valid.
| | | | | |
| | Time before which all | | Time before which all
| | neighbor information must | | neighbor information must
| | be transmitted in HELLO | | be transmitted in HELLO
| | messages (one or more) | | messages (one or more)
| | | |
| Latest time for next HELLO message | Latest time for next HELLO message
skipping to change at page 72, line 17 skipping to change at page 73, line 17
Figure 6 illustrates the Link Set timers when receiving a HELLO Figure 6 illustrates the Link Set timers when receiving a HELLO
message not including the network address of the receiving MANET message not including the network address of the receiving MANET
interface. interface.
VALIDITY_TIME: |--------------------------| VALIDITY_TIME: |--------------------------|
L_time: |--------------------------| L_time: |--------------------------|
L_HEARD_time: |--------------------------| L_HEARD_time: |--------------------------|
L_SYM_time: *-| (i.e. expired) L_SYM_time: *-| (i.e., expired)
Time: ---*--------------------------------> Time: ---*-------------------------------->
^ ^
| |
HELLO () received HELLO () received
Figure 6: HELLO message processing: network address not present Figure 6: HELLO message processing: network address not present
Figure 7 illustrates the Link Set timers when, following the received Figure 7 illustrates the Link Set timers when, following the received
HELLO message illustrated in Figure 6, a router receives a HELLO HELLO message illustrated in Figure 6, a router receives a HELLO
skipping to change at page 72, line 40 skipping to change at page 73, line 40
VALIDITY_TIME: |--------------------------| VALIDITY_TIME: |--------------------------|
|--------------------------| |--------------------------|
L_time: |--------------------------| L_time: |--------------------------|
|--------------------------| |--------------------------|
L_HEARD_time: |--------------------------| L_HEARD_time: |--------------------------|
|--------------------------| |--------------------------|
L_SYM_time: *-| (i.e. expired) L_SYM_time: *-| (i.e., expired)
L_SYM_time: |--------------------------| L_SYM_time: |--------------------------|
Time: -*-----*---------------------------------> Time: -*-----*--------------------------------->
^ ^ ^ ^
| | | |
HELLO () received | HELLO () received |
| |
HELLO (a:HEARD) received HELLO (a:HEARD) received
Figure 7: HELLO message processing: network address present Figure 7: HELLO message processing: network address present
skipping to change at page 73, line 20 skipping to change at page 74, line 20
|--------------------------| |--------------------------|
L_time: |--------------------------| L_time: |--------------------------|
|--------------------------| |--------------------------|
|--------------------------| |--------------------------|
L_HEARD_time: |--------------------------| L_HEARD_time: |--------------------------|
|--------------------------| |--------------------------|
|--------------------------| |--------------------------|
L_SYM_time: *-| (i.e. expired) L_SYM_time: *-| (i.e., expired)
|--------------------------| |--------------------------|
*-| (i.e. expired) *-| (i.e., expired)
Time: -*-----*-----*---------------------------------> Time: -*-----*-----*--------------------------------->
^ ^ ^ ^ ^ ^
| | | | | |
HELLO () received | | HELLO () received | |
| | | |
HELLO (a:HEARD) received | HELLO (a:HEARD) received |
| |
HELLO (a:LOST) received HELLO (a:LOST) received
skipping to change at page 74, line 14 skipping to change at page 75, line 14
L_HOLD_TIME: |----------------------------| L_HOLD_TIME: |----------------------------|
Time: ---*----------------------------------> Time: ---*---------------------------------->
^ ^ ^ ^
| | | |
Formerly symmetric 1-hop neighbor | Formerly symmetric 1-hop neighbor |
ceases to be symmetric on this | ceases to be symmetric on this |
MANET interface | MANET interface |
| |
Time until which network addresses of Time up to which network addresses of
this neighbor connected using this MANET this neighbor connected using this MANET
interface are advertised in HELLO interface are advertised in HELLO
messages on this MANET interface messages on this MANET interface
using a LINK_STATUS TLV, Value = LOST using a LINK_STATUS TLV, Value = LOST
Figure 9: HELLO message generation: advertisement of formerly Figure 9: HELLO message generation: advertisement of formerly
symmetric 1-hop neighbor on this MANET interface as lost symmetric 1-hop neighbor on this MANET interface as lost
Figure 10 illustrates the time, with duration N_HOLD_TIME, during Figure 10 illustrates the time, with duration N_HOLD_TIME, during
which all network addresses of a formerly, but no longer, symmetric which all network addresses of a formerly, but no longer, symmetric
skipping to change at page 74, line 38 skipping to change at page 75, line 38
update their 2-Hop Sets accordingly. update their 2-Hop Sets accordingly.
L_HOLD_TIME: |----------------------------| L_HOLD_TIME: |----------------------------|
Time: ---*----------------------------------> Time: ---*---------------------------------->
^ ^ ^ ^
| | | |
Formerly symmetric 1-hop neighbor | Formerly symmetric 1-hop neighbor |
ceases to be symmetric | ceases to be symmetric |
| |
Time until which network addresses of Time up to which network addresses of
this neighbor are advertised in HELLO this neighbor are advertised in HELLO
messages on all MANET interfaces messages on all MANET interfaces
using an OTHER_NEIGHB TLV, using an OTHER_NEIGHB TLV,
Value = LOST Value = LOST
Figure 10: HELLO message generation: advertisement of formerly Figure 10: HELLO message generation: advertisement of formerly
symmetric 1-hop neighbor on any MANET interface as lost symmetric 1-hop neighbor on any MANET interface as lost
Figure 11 illustrates the time, with duration I_HOLD_TIME, during Figure 11 illustrates the time, with duration I_HOLD_TIME, during
which a formerly, but no longer, used local interface network address which a formerly, but no longer, used local interface network address
skipping to change at page 75, line 14 skipping to change at page 76, line 14
I_HOLD_TIME: |----------------------------| I_HOLD_TIME: |----------------------------|
Time: ---*-----------------------------------> Time: ---*----------------------------------->
^ ^ ^ ^
| | | |
Formerly used local interface | Formerly used local interface |
network address ceases to be | network address ceases to be |
assigned to a local interface | assigned to a local interface |
| |
Time until which this network Time up to which this network
address is excluded from being address is excluded from being
included in this router's 2-Hop Set included in this router's 2-Hop Set
Figure 11: Local interface removed network address Figure 11: Local interface removed network address
Appendix F. Topology Pictures Appendix F. Topology Pictures
This appendix illustrates various examples of physical topologies, as This appendix illustrates various examples of physical topologies, as
well as how these are logically recorded by NHDP from the point of well as how these are logically recorded by NHDP from the point of
view of the router A. This representation is a composite of view of the router A. This representation is a composite of
skipping to change at page 76, line 33 skipping to change at page 77, line 33
Link Tuple has an L_neighbor_iface_addr_list containing {2}; this Link Tuple has an L_neighbor_iface_addr_list containing {2}; this
corresponds to the dashed line from {1} to {2} to the right in corresponds to the dashed line from {1} to {2} to the right in
Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with
N2_neighbor_iface_addr_list being {2} and N2_hop_addr being {3}; this N2_neighbor_iface_addr_list being {2} and N2_hop_addr being {3}; this
corresponds to the dashed line from {2} to {3} to the right in corresponds to the dashed line from {2} to {3} to the right in
Figure 12. Figure 12.
The descriptions of the following examples in this appendix will be The descriptions of the following examples in this appendix will be
derived similarly, and use the same notational conventions. derived similarly, and use the same notational conventions.
F.2. Example 2: Dual Addressed Interface on One Hop Neighbor F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor
In Figure 13, the network is identical to that in Example 1, except In Figure 13, the network is identical to that in Example 1, except
that the middle router, B, has two IP addresses on its single that the middle router, B, has two IP addresses on its single
interface. interface.
__________ __________ __________ __________
| | | | | |
{1} {2,4} {3} {1} {2,4} {3}
| | | {1}-------{2,4}-------{3} | | | {1}-------{2,4}-------{3}
+--'--+ +--'--+ +--'--+ +--'--+ +--'--+ +--'--+
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 13: Single interfaces, with 1-hop neighbor B having two Figure 13: Single interfaces, with 1-hop neighbor B having two
addresses (left), and corresponding NHDP representation (right) addresses (left), and corresponding NHDP representation (right)
The content of the Interface Information Base is in this case The content of the Interface Information Base is in this case
identical to Example 1, except that L_neighbor_iface_addr_list is identical to Example 1, except that L_neighbor_iface_addr_list is
{2,4} and N2_neighbor_iface_addr_list is {2,4}. {2,4} and N2_neighbor_iface_addr_list is {2,4}.
F.3. Example 3: Dual Addressed Interface on Two Hop Neighbor F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor
In Figure 14, the network is identical to that in Example 1, except In Figure 14, the network is identical to that in Example 1, except
that the rightmost router, C, has two IP addresses on its interface. that the rightmost router, C, has two IP addresses on its interface.
__________ __________ __________ __________
| | | | | |
{1} {2} {3,4} _.---{3} {1} {2} {3,4} +----{3}
| | | {1}--------{2}--<_ | | | {1}--------{2}---+
+--'--+ +--'--+ +--'--+ '---{4} +--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 14: Single interfaces, with 2-hop neighbor C having two Figure 14: Single interfaces, with 2-hop neighbor C having two
addresses (left), and corresponding NHDP representation (right) addresses (left), and corresponding NHDP representation (right)
The content of the Interface Information Base is in this case The content of the Interface Information Base is in this case
identical to than in Example 1, except that the 2-Hop Set contains an identical to than in Example 1, except that the 2-Hop Set contains an
extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
N2_hop_addr being {4}. These two 2-Hop Tuples are illustrated by the N2_hop_addr being {4}. These two 2-Hop Tuples are illustrated by the
skipping to change at page 77, line 37 skipping to change at page 78, line 37
F.4. Example 4: Dual Addressed Interfaces F.4. Example 4: Dual Addressed Interfaces
In Figure 15, the network is identical to that in Example 1, except In Figure 15, the network is identical to that in Example 1, except
that all routers have two IP addresses on their interface. The Local that all routers have two IP addresses on their interface. The Local
Information Base in router A is the same as in Example 1, except that Information Base in router A is the same as in Example 1, except that
I_local_iface_addr_list is {1,5}. I_local_iface_addr_list is {1,5}.
__________ __________ __________ __________
| | | | | |
{1,5} {2,6} {3,4} _.---{3} {1,5} {2,6} {3,4} +----{3}
| | | {1,5}------{2,6}-<_ | | | {1,5}------{2,6}--+
+--'--+ +--'--+ +--'--+ '---{4} +--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 15: Single interfaces, all routers having two addresses Figure 15: Single interfaces, all routers having two addresses
(left), and corresponding NHDP representation (right) (left), and corresponding NHDP representation (right)
The content of the Interface Information Base is in this case a The content of the Interface Information Base is in this case a
combination of the Interface Information Bases from Example 1, combination of the Interface Information Bases from Example 1,
Example 2 and Example 3. Example 2 and Example 3.
F.5. Example 5: Dual Interface on Two Hop Neighbor F.5. Example 5: Dual Interface on 2-Hop Neighbor
In Figure 16, all routers have a single IP address on each interface, In Figure 16, all routers have a single IP address on each interface,
and with the 2-hop neighbor having two interfaces. and with the 2-hop neighbor having two interfaces.
__________ __________ __________ __________
| | | | | |
{1} {2} {3} _.---{3} {1} {2} {3} +----{3}
| | | {1}--------{2}--<_ | | | {1}--------{2}---+
+--'--+ +--'--+ +-----+ '---{4} +--'--+ +--'--+ +-----+ +----{4}
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| |
{4} {4}
Figure 16: Single addresses, with 2-hop neighbor C having two Figure 16: Single addresses, with 2-hop neighbor C having two
interfaces (left), and corresponding NHDP representation (right) interfaces (left), and corresponding NHDP representation (right)
The Interface Information Base is identical to that in Example 3; The Interface Information Base is identical to that in Example 3;
NHDP does not distinguish topologically between this example and NHDP does not distinguish topologically between this example and
Example 3. Example 3.
F.6. Example 6: Dual interface on One Hop Neighbor F.6. Example 6: Dual interface on 1-Hop Neighbor
In Figure 17, all routers have a single IP address on each interface, In Figure 17, all routers have a single IP address on each interface,
and with the 1-hop neighbor having two interfaces. and with the 1-hop neighbor having two interfaces.
__________ __________
| | | |
{1} {2} ,-. {1} {2} +-----+
| | {1}-------/{2}\-------{4} | | {1}-------| {2} |------{4}
+--'--+ +--'--+ +-----+ \{5}/ +--'--+ +--'--+ +-----+ | {5} |
| A | | B | | C | `-' | A | | B | | C | +-----+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | |
{5} {4} {5} {4}
|__________| |__________|
Figure 17: Single addresses, with 1-hop neighbor B having two Figure 17: Single addresses, with 1-hop neighbor B having two
interfaces (left), and corresponding NHDP representation (right) interfaces (left), and corresponding NHDP representation (right)
The Local Information Base is identical to that in Example 1. The Local Information Base is identical to that in Example 1.
The Interface Information Base has only one Link Set containing one The Interface Information Base has only one Link Set containing one
Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set
contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being
{2} and N2_hop_addr being {4}. {2} and N2_hop_addr being {4}.
The Neighbor Information Base contains a Neighbor Set containing a The Neighbor Information Base contains a Neighbor Set containing a
single Neighbor Tuple, which represents router B, with single Neighbor Tuple, which represents router B, with
N_neighbor_addr_list being {2,5}. This entry is represented on the N_neighbor_addr_list being {2,5}. This entry is represented on the
right of Figure 17 by circling {2} with {5}. right of Figure 17 by boxing {2} with {5}.
Note that router A does not have information indicating which of Note that router A does not have information indicating which of
router B's interfaces is connected to router C. However, router A router B's interfaces is connected to router C. However, router A
knows that the address {4} (and thus router C) is reachable by using knows that the address {4} (and thus router C) is reachable by using
{2} as next hop. {2} as next hop.
F.7. Example 7: Dual Interface on One and Two Hop Neighbors F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors
In Figure 18, all routers have a single IP address on each interface, In Figure 18, all routers have a single IP address on each interface,
and both the 1-hop and 2-hop neighbors have two interfaces. and both the 1-hop and 2-hop neighbors have two interfaces.
Furthermore, there are now two physical links between routers B and Furthermore, there are now two physical links between routers B and
C, over distinct interface pairs. C, over distinct interface pairs.
__________ __________ __________ __________
| | | | | |
{1} {2} {3} ,-. _.---{3} {1} {2} {3} +-----+ +----{3}
| | | {1}-------/{2}\--<_ | | | {1}-------| {2} |---+
+--'--+ +--'--+ +-----+ \{5}/ '---{4} +--'--+ +--'--+ +-----+ | {5} | +----{4}
| A | | B | | C | `-' | A | | B | | C | +-----+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | |
{5} {4} {5} {4}
|__________| |__________|
Figure 18: Single addresses, with 1-hop and 2-hop neighbors B and C Figure 18: Single addresses, with 1-hop and 2-hop neighbors B and C
having two interfaces (left), and corresponding NHDP representation having two interfaces (left), and corresponding NHDP representation
(right) (right)
The Local Information Base is identical to that in Example 1. The Local Information Base is identical to that in Example 1.
skipping to change at page 80, line 5 skipping to change at page 81, line 5
The Link Set is identical to that in Example 6, and the 2-Hop Set The Link Set is identical to that in Example 6, and the 2-Hop Set
contains, as in Example 5 (and similarly to Examples 3 and 4), two contains, as in Example 5 (and similarly to Examples 3 and 4), two
2-Hop Tuples representing the two links between routers B and C 2-Hop Tuples representing the two links between routers B and C
Note that router A does not have information describing which of Note that router A does not have information describing which of
router B's interfaces is connected to which interfaces of router C, router B's interfaces is connected to which interfaces of router C,
or even that the interfaces with addresses {3} and {4} are interfaces or even that the interfaces with addresses {3} and {4} are interfaces
of the same router. However, router A knows that the addresses {3} of the same router. However, router A knows that the addresses {3}
and {4} (and thus router C) are reachable using {2} as next hop. and {4} (and thus router C) are reachable using {2} as next hop.
F.8. Example 8: Dual Interface Locally and on One Hop Neighbor F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor
In Figure 19, all routers have a single IP address on each interface, In Figure 19, all routers have a single IP address on each interface,
and both A and its the 1-hop neighbor B have two interfaces. and both A and its the 1-hop neighbor B have two interfaces.
Furthermore, there are now two physical links between routers A and Furthermore, there are now two physical links between routers A and
B, over distinct interface pairs. B, over distinct interface pairs.
__________ __________ __________ __________
| | | ,-. | | | +-----+
{1} {2} {3} {1}-------/{2}\--------{3} {1} {2} {3} {1}-------| {2} |--------{3}
| | | \{5}/ | | | | {5} |
+--'--+ +--'--+ +-----+ `-' +--'--+ +--'--+ +-----+ +-----+
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ ,-. +-----+ +-----+ +-----+ +-----+
| | /{2}\ | | | {2} |
{6} {5} {6}-------\{5}/--------{3} {6} {5} {6}-------| {5} |--------{3}
|__________| `-' |__________| +-----+
Figure 19: Single addresses, with both A and 1-hop neighbor B having Figure 19: Single addresses, with both A and 1-hop neighbor B having
two interfaces (left), and corresponding NHDP representation (right) two interfaces (left), and corresponding NHDP representation (right)
The Local Information Set contains two Local Interface Tuples, with The Local Information Set contains two Local Interface Tuples, with
I_local_iface_addr_list of {1} and {6}, respectively. I_local_iface_addr_list of {1} and {6}, respectively.
Each Interface Information Base's Link Set contains one Link Tuple, Each Interface Information Base's Link Set contains one Link Tuple,
representing the links between {1} and {2}, and between {6} and {5}, representing the links between {1} and {2}, and between {6} and {5},
respectively. The 2-Hop Set for interface {1} contains a single respectively. The 2-Hop Set for interface {1} contains a single
2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and
N2_hop_addr being {3}. The 2-Hop Set for interface {6} contains a N2_hop_addr being {3}. The 2-Hop Set for interface {6} contains a
single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and
N2_hop_addr being {3}. N2_hop_addr being {3}.
The Neighbor Information Base contains a Neighbor Set containing a The Neighbor Information Base contains a Neighbor Set containing a
single Neighbor Tuple, which represents router B, with single Neighbor Tuple, which represents router B, with
N_neighbor_addr_list being {2,5}. This entry is denoted by circling N_neighbor_addr_list being {2,5}. This entry is denoted by boxing
{2} with {5}. {2} with {5}.
F.9. Example 9: Dual Interface on All Routers F.9. Example 9: Dual Interface on All Routers
In Figure 20, all routers have a single IP address on each interface, In Figure 20, all routers have a single IP address on each interface,
and all routers have two interfaces. Furthermore, there are now two and all routers have two interfaces. Furthermore, there are now two
physical links between A and B, over distinct interface pairs, and physical links between A and B, over distinct interface pairs, and
two physical links between B and C, also over distinct interface two physical links between B and C, also over distinct interface
pairs. pairs.
__________ __________ __________ __________
| | | ,-. _.---{3} | | | +-----+ +----{3}
{1} {2} {3} {1}-------/{2}\--<_ {1} {2} {3} {1}-------| {2} |---+
| | | \{5}/ '---{4} | | | | {5} | +----{4}
+--'--+ +--'--+ +-----+ `-' +--'--+ +--'--+ +-----+ +-----+
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ ,-. +-----+ +-----+ +-----+ +-----+
| | | /{2}\ _.---{3} | | | | {2} | +----{3}
{6} {5} {4} {6}-------\{5}/--<_ {6} {5} {4} {6}-------| {5} |---+
|__________|__________| `-' '---{4} |__________|__________| +-----+ +----{4}
Figure 20: Single addresses, with all routers having two interfaces Figure 20: Single addresses, with all routers having two interfaces
(left), and corresponding NHDP representation (right) (left), and corresponding NHDP representation (right)
The Local Information Set is identical to that in Example 8. The The Local Information Set is identical to that in Example 8. The
Interface Information Base for each interface in A is also identical Interface Information Base for each interface in A is also identical
to that in Example 8, except that an additional 2-Hop Tuple is to that in Example 8, except that an additional 2-Hop Tuple is
present in each 2-Hop Set, each representing the link between router present in each 2-Hop Set, each representing the link between router
B and the interface of router C with address {4}. B and the interface of router C with address {4}.
skipping to change at page 82, line 5 skipping to change at page 83, line 5
via which of its local interfaces) as next hop. via which of its local interfaces) as next hop.
F.10. Example 10: Dual Addressed Dual Interfaces on All Routers F.10. Example 10: Dual Addressed Dual Interfaces on All Routers
In Figure 21, all routers have two IP addresses on each interface, In Figure 21, all routers have two IP addresses on each interface,
and all routers have two interfaces. Furthermore, there are now two and all routers have two interfaces. Furthermore, there are now two
physical links between A and B, over distinct interface pairs, and physical links between A and B, over distinct interface pairs, and
two physical links between B and C, also over distinct interface two physical links between B and C, also over distinct interface
pairs. pairs.
__________ __________ _ _.--{9} +--{9}
| | | ,' `. _.-<__-{10} __________ __________ +------|
{1,2} {5,6} {9,10} {1,2}--|{5,6}|-<_ __ | | | +-----+ | +--{10}
| | | |{7,8}| '-<_ -{11} {1,2} {5,6} {9,10} {1,2}--|{5,6}|---+
+--'--+ +--'--+ +-----+ `._,' '-{12} | | | |{7,8}| | +--{11}
| A | | B | | C | _ +--'--+ +--'--+ +-----+ +-----+ +------|
+-----+ +-----+ +-----+ ,' `. _.--{9} | A | | B | | C | +--{12}
| | | |{5,6}| _.-<__-{10} +-----+ +-----+ +-----+
{3,4} {7,8} {11,12} {3,4}--|{7,8}|-<_ __ | | | +--{9}
|__________|__________| `._,' '-<_ -{11} | | | +-----+ +------|
'-{12} | | | |{5,6}| | +--{10}
{3,4} {7,8} {11,12} {3,4}--|{7,8}|---+
|__________|__________| +-----+ | +--{11}
+------|
+--{12}
Figure 21: Dual addresses, with all routers having two interfaces Figure 21: Dual addresses, with all routers having two interfaces
(left) and corresponding NHDP representation (right) (left) and corresponding NHDP representation (right)
This example is the combination of all the preceding examples in this This example is the combination of all the preceding examples in this
appendix. The Local Information Set in A contains Local Information appendix. The Local Information Set in A contains Local Information
Tuples for each of its interfaces, and each Interface Information Tuples for each of its interfaces, and each Interface Information
Base contains in its Link Set a representation of links {1,2}-{5,6} Base contains in its Link Set a representation of links {1,2}-{5,6}
or {3,4}-{7,8}, respectively. The Neighbor Set (in the Neighbor or {3,4}-{7,8}, respectively. The Neighbor Set (in the Neighbor
Information Base) records the existence of router B and all of its Information Base) records the existence of router B and all of its
addresses on all its interfaces, i.e. {5,6,7,8}. addresses on all its interfaces, i.e., {5,6,7,8}.
As in Example 9, each interface address of router C is represented in As in Example 9, each interface address of router C is represented in
the 2-Hop Set of each Interface Information Base as a link from the 2-Hop Set of each Interface Information Base as a link from
router B to each of these addresses. Router A does not have router B to each of these addresses. Router A does not have
information describing which of router B's interfaces is connected to information describing which of router B's interfaces is connected to
which interface of C, nor that the addresses {9}, {10}, {11}, and which interface of C, nor that the addresses {9}, {10}, {11}, and
{12} are addresses of the same router (or that some of these, such as {12} are addresses of the same router (or that some of these, such as
{9} and {10}, are addresses on the same interface of the router). {9} and {10}, are addresses on the same interface of the router).
F.11. Example 11: Single Addressed Dual Interface Locally F.11. Example 11: Single Addressed Dual Interface Locally
 End of changes. 172 change blocks. 
367 lines changed or deleted 442 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/