draft-ietf-manet-nhdp-09.txt   draft-ietf-manet-nhdp-10.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: September 27, 2009 BAE Systems ATC Expires: January 14, 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
March 26, 2009 July 13, 2009
MANET Neighborhood Discovery Protocol (NHDP) MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-09 draft-ietf-manet-nhdp-10
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 27, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
This document describes a 1-hop and symmetric 2-hop neighborhood This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs). discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 9 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11 4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11
4.2. Information Base Overview . . . . . . . . . . . . . . . . 11 4.2. Information Base Overview . . . . . . . . . . . . . . . . 11
4.2.1. Local Information Base . . . . . . . . . . . . . . . . 11 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 12
4.2.2. Interface Information Bases . . . . . . . . . . . . . 12 4.2.2. Interface Information Bases . . . . . . . . . . . . . 12
4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 13 4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 13
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 13 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 14 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 14
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 14 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 15
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 15 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 15
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 16
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 16 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 16
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 16 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 16
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 16 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 16
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 16 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 16
5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 16 5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 17
5.3.2. Information Validity Times . . . . . . . . . . . . . . 18 5.3.2. Information Validity Times . . . . . . . . . . . . . . 18
5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 18 5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 19
5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 19 5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 20
5.4.1. Information Validity Time . . . . . . . . . . . . . . 19 5.4.1. Information Validity Time . . . . . . . . . . . . . . 20
5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 20 5.5. Parameter Change Constraints . . . . . . . . . . . . . . . 20
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Local Information Base . . . . . . . . . . . . . . . . . . . . 21 6. Local Information Base . . . . . . . . . . . . . . . . . . . . 21
6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 21 6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 22
6.2. Removed Interface Address Set . . . . . . . . . . . . . . 22 6.2. Removed Interface Address Set . . . . . . . . . . . . . . 22
7. Interface Information Base . . . . . . . . . . . . . . . . . . 22 7. Interface Information Base . . . . . . . . . . . . . . . . . . 23
7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 24 8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 25
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 25 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 25
9. Local Information Base Changes . . . . . . . . . . . . . . . . 25 9. Local Information Base Changes . . . . . . . . . . . . . . . . 26
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 25 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 26
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 26 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 26
9.3. Adding an Address to an Interface . . . . . . . . . . . . 27 9.3. Adding an Address to an Interface . . . . . . . . . . . . 27
9.4. Removing an Address from an Interface . . . . . . . . . . 27 9.4. Removing an Address from an Interface . . . . . . . . . . 28
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 28 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 28
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 29 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 29
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 29 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 29
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 30 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 31
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 31 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 31
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 33 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 33
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 33 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 33
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 33 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 34
12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 34 12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 34
12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 35 12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 35
12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 36 12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 36
12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 37 12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 37
12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 37 12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 37
12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 39 12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 39
13. Other Information Base Changes . . . . . . . . . . . . . . . . 40 13. Other Information Base Changes . . . . . . . . . . . . . . . . 40
13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 41 13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 41
13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 41 13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 42
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 42 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 43
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 43 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 43 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 43
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 43 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 44
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 44 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 45
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 45 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 45
15. Proposed Values for Parameters and Constants . . . . . . . . . 46 15. Proposed Values for Parameters and Constants . . . . . . . . . 46
15.1. Message Interval Interface Parameters . . . . . . . . . . 46 15.1. Message Interval Interface Parameters . . . . . . . . . . 46
15.2. Information Validity Time Interface Parameters . . . . . . 46 15.2. Information Validity Time Interface Parameters . . . . . . 46
15.3. Information Validity Time Router Parameters . . . . . . . 46 15.3. Information Validity Time Router Parameters . . . . . . . 46
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 46 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 46
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 46 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 47
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 47 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 47
16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 47 16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 47
17. Security Considerations . . . . . . . . . . . . . . . . . . . 48 17. Security Considerations . . . . . . . . . . . . . . . . . . . 48
17.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48 17.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 49
17.2. Authentication, Integrity and Confidentiality 17.2. Authentication, Integrity and Confidentiality
Suggestions . . . . . . . . . . . . . . . . . . . . . . . 49 Suggestions . . . . . . . . . . . . . . . . . . . . . . . 50
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 50 18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 51
18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 50 18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 51
18.3. Message-Type-specific TLV Type Registries . . . . . . . . 50 18.3. Message-Type-specific TLV Type Registries . . . . . . . . 51
18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 51 18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 52
18.5. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 52 18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 53
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
21.1. Normative References . . . . . . . . . . . . . . . . . . . 53 21.1. Normative References . . . . . . . . . . . . . . . . . . . 54
21.2. Informative References . . . . . . . . . . . . . . . . . . 54 21.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 54 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 55
Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 55 Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 56
Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 58 Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 58
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 60 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 61
Appendix E. Interval and Timer Illustrations . . . . . . . . . . 62
E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 62
E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 68
E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 69
Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 71
F.1. Example 1: Standard Single Interface Topology . . . . . . 71
F.2. Example 2: Dual Addressed Interface on One Hop Neighbor . 72
F.3. Example 3: Dual Addressed Interface on Two Hop Neighbor . 73
F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 73
F.5. Example 5: Dual Interface on Two Hop Neighbor . . . . . . 74
F.6. Example 6: Dual interface on One Hop Neighbor . . . . . . 74
F.7. Example 7: Dual Interface on One and Two Hop Neighbors . . 75
F.8. Example 8: Dual Interface Locally and on One Hop
Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . 76
F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 76
F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers . . . . . . . . . . . . . . . . . . . . . . . . . 77
F.11. Example 11: Single Addressed Dual Interface Locally . . . 78
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 according to the symmetric 2-hop neighbors. Messages are defined and sent in packets
specification [RFC5444]. according to the specification [RFC5444].
1-hop and symmetric 2-hop neighborhood information is recorded in the 1-hop and symmetric 2-hop neighborhood information is recorded in the
form of Information Bases. These are available for use by other form of Information Bases. These are available for use by other
protocols, such as MANET routing protocols, which require information protocols, such as MANET routing protocols, which require information
regarding the local network connectivity. This protocol is designed regarding the local network connectivity. This protocol is designed
to maintain the information in these Information Bases even in the to maintain the information in these Information Bases even in the
presence of a dynamic network topology and wireless communication presence of a dynamic network topology and wireless communication
channel characteristics. channel characteristics.
This protocol makes no assumptions about the underlying link layer, This protocol makes no assumptions about the underlying link layer,
other than support of local broadcast or multicast. Link layer other than support of local broadcast or multicast for communication
information may be used if available and applicable. to 1-hop neighbor routers. Link layer information may be used if
available and applicable.
This protocol is based on the neighborhood discovery process This protocol is based on the neighborhood discovery process
contained in the Optimized Link State Routing Protocol (OLSR) contained in the Optimized Link State Routing Protocol (OLSR)
[RFC3626]. [RFC3626].
1.1. Motivation 1.1. Motivation
MANETs differ from more traditional wired and infrastructure based MANETs differ from more traditional wired and infrastructure based
wireless networks, due to their envisioned applicability also over wireless networks, due to their envisioned applicability also over
more challenging communication channels (e.g., wireless, lossy, more challenging communication channels (e.g., wireless, lossy,
skipping to change at page 6, line 4 skipping to change at page 6, line 6
router A is able to receive packets from router B, the converse is router A is able to receive packets from router B, the converse is
not guaranteed to be true. Furthermore, because of the localized not guaranteed to be true. Furthermore, because of the localized
nature of wireless broadcast communication, neighboring routers nature of wireless broadcast communication, neighboring routers
within the same communications channel may have different sets of within the same communications channel may have different sets of
neighbors. That is, when using the same communication channel, even neighbors. That is, when using the same communication channel, even
if router A is able to exchange packets with router B and router B is if router A is able to exchange packets with router B and router B is
able to exchange packets with router C, then this does not guarantee able to exchange packets with router C, then this does not guarantee
that router A and router C can exchange packets directly. that router A and router C can exchange packets directly.
Each router in a MANET may use more than one communication channel. Each router in a MANET may use more than one communication channel.
In particular, between the same pair of routers, more than one In particular, between the same pair of routers, more than one
distinct communication channel may exist, each with different distinct communication channel may exist, each with different
properties. properties.
For use by MANET routing protocols, as well as establishing a For use by MANET routing protocols, as well as for establishing a
router's neighbors, a router may also need to determine whether each router's neighbors, a router may also need to determine whether each
communication channel with that neighbor is bidirectional. communication channel with that neighbor is bidirectional.
The set of neighbor routers of a given MANET router may be The set of neighbor routers of a given MANET router may be
continuously changing, often due to router mobility or a changing continuously changing, often due to router mobility or a changing
physical environment in which the MANET is located. There is physical environment in which the MANET is located. There is
typically no information from lower layers which would enable an IP typically no information from lower layers which would enable an IP
routing protocol to detect and, as appropriate, react to such routing protocol to detect and, as appropriate, react to such
changes. Such changes can often take place on a short timescale, changes. Such changes can often take place on a short timescale,
such as of the order of seconds, requiring MANET routing protocols to such as of the order of seconds, requiring MANET routing protocols to
skipping to change at page 7, line 14 skipping to change at page 7, line 17
Interface - A network device, configured and assigned one or more Interface - A network device, configured and assigned one or more
addresses. addresses.
Address - An IPv4 or IPv6 address, as assigned to an interface. It Address - An IPv4 or IPv6 address, as assigned to an interface. It
corresponds to an address as specified in [RFC5444], and may be corresponds to an address as specified in [RFC5444], and may be
either an address or an address prefix. An address without a either an address or an address prefix. An address without a
prefix length is considered to have a prefix length equal to its prefix length is considered to have a prefix length equal to its
length (in bits). length (in bits).
Origionator address - An address identifying a router, as specified
in [RFC5444]; it is a simple address without a prefix length.
MANET interface - An interface participating in a MANET and using MANET interface - An interface participating in a MANET and using
this neighborhood discovery protocol. A router may have several this neighborhood discovery protocol. A router may have several
MANET interfaces. MANET interfaces.
Heard - A MANET interface of router X is considered heard on a MANET Heard - A MANET interface of router X is considered heard on a MANET
interface of a router Y if the latter can receive traffic from the interface of a router Y if the latter can receive traffic from the
former. former.
Link - A link between two MANET interfaces exists if either can be Link - A link between two MANET interfaces exists if either can be
heard by the other. heard by the other.
skipping to change at page 9, line 37 skipping to change at page 9, line 37
interfaces. The set of a router's interfaces may change over interfaces. The set of a router's interfaces may change over
time. Each interface may have one or more interface addresses, time. Each interface may have one or more interface addresses,
and these may also be dynamically changing. and these may also be dynamically changing.
o Provides each router with current local topology information up to o Provides each router with current local topology information up to
two hops away, and makes this local topology information available two hops away, and makes this local topology information available
to MANET routing protocols in Information Bases. to MANET routing protocols in Information Bases.
o Uses the packet and message formats specified in [RFC5444]. This o Uses the packet and message formats specified in [RFC5444]. This
includes the definition of a HELLO Message Type, used for includes the definition of a HELLO Message Type, used for
signalling local topology information. signaling local topology information.
o Allows "external" and "internal" extensibility as enabled by
[RFC5444].
o May interact with, and be extended by, other protocols, such as o May interact with, and be extended by, other protocols, such as
MANET routing protocols, see Section 16. MANET routing protocols, see Section 16.
o Can use relevant link layer information if it is available. o Can use relevant link layer information if it is available.
o Is designed to work in a completely distributed manner, and does o Is designed to work in a completely distributed manner, and does
not depend on any central entity. not depend on any central entity.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The objective of this protocol is, for each router: The objective of this protocol is, for each router:
o To identify 1-hop neighbors and symmetric 1-hop neighbors of this o To identify 1-hop neighbors and symmetric 1-hop neighbors of this
router. router.
o To find the interface addresses of the router's symmetric 2-hop o To find the interface addresses of the router's symmetric 2-hop
neighbors. neighbors.
o To record this information in Information Bases that can be used o To record this information in Information Bases that can be used
by other protocols, of which this neighborhood discovery protocol by other protocols, which extend this neighborhood discovery
may be a part. protocol.
These objectives are achieved using local (1-hop) signaling that: These objectives are achieved using local (1-hop) signaling that:
o Advertises the presence of a router and its interface addresses. o Advertises the presence of a router and its interface addresses.
o Discovers links from neighboring routers. o Discovers links from neighboring routers.
o Performs bidirectionality checks on the discovered links. o Performs bidirectionality checks on the discovered links.
o Advertises discovered links, and whether each is symmetric, to its o Advertises discovered links, and whether each is symmetric, to its
1-hop neighbors, and hence discovers symmetric 2-hop neighbors. 1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
This specification defines, in turn: This specification defines, in turn:
o Parameters and constants used by the protocol. Parameters used by o Parameters and constants used by the protocol. Parameters used by
this protocol may be, where appropriate, specific to a given MANET this protocol may, where appropriate, be specific to a given MANET
interface, or to a MANET router. This protocol allows all interface, or to a MANET router. This protocol allows all
parameters to be changed dynamically, and to be set independently parameters to be changed dynamically, and to be set independently
for each MANET router or MANET interface, as appropriate. for each MANET router or MANET interface, as appropriate.
o The Information Bases describing local interfaces, discovered o The Information Bases describing local interfaces, discovered
links and their status, current and former 1-hop neighbors, and links and their status, current and former 1-hop neighbors, and
symmetric 2-hop neighbors. symmetric 2-hop neighbors.
o The format of the HELLO message that is used for local signaling. o The format of the HELLO message that is used for local signaling.
skipping to change at page 11, line 12 skipping to change at page 11, line 12
o The response to other events, such as the expiration of o The response to other events, such as the expiration of
information in the Information Bases. information in the Information Bases.
4.1. Routers and Interfaces 4.1. Routers and Interfaces
In order for a router to participate in a MANET, it MUST have at In order for a router to participate in a MANET, it MUST have at
least one, and possibly more, MANET interfaces. Each MANET least one, and possibly more, MANET interfaces. Each MANET
interface: interface:
o Is configured with one or more addresses. These addresses MUST be o Is configured with one or more addresses. These addresses MUST be
unique within the router's 2-hop neighborhood. unique at least within the router's 2-hop neighborhood.
o Has a set of interface parameters, defining the behavior of this o Has a set of interface parameters, defining the behavior of this
MANET interface. Each MANET interface MAY be individually MANET interface. Each MANET interface MAY be individually
parameterized. parameterized.
o Has an Interface Information Base, recording information regarding o Has an Interface Information Base, recording information regarding
links to this MANET interface and symmetric 2-hop neighbors which links to this MANET interface and symmetric 2-hop neighbors which
can be reached through such links. can be reached through such links.
o Generates and processes HELLO messages. o Generates and processes HELLO messages.
skipping to change at page 11, line 45 skipping to change at page 11, line 45
Interfaces of both of these types are recorded in a router's Local Interfaces of both of these types are recorded in a router's Local
Information Base, which is used, but not updated, by the signaling of Information Base, which is used, but not updated, by the signaling of
this protocol. this protocol.
4.2. Information Base Overview 4.2. Information Base Overview
Each router maintains the Information Bases described in the Each router maintains the Information Bases described in the
following sections. These are used for describing the protocol in following sections. These are used for describing the protocol in
this document. An implementation of this protocol MAY maintain this this document. An implementation of this protocol MAY maintain this
information in the indicated form, or in any other organization which information in the indicated form, or in any other organization which
offers access to this information. In particular note that it is not offers access to this information. In particular, note that it is
necessary to remove Tuples from Sets at the exact time indicated, not necessary to remove Tuples from Sets at the exact time indicated,
only to behave as if the Tuples were removed at that time. only to behave as if the Tuples were removed at that time.
Information in the Local Information Base is defined locally, and
included in HELLO messages. Information in the Interface Information
Base and the Neighbor Information Base is determined from received
HELLO messages; some of this information may also be included in
transmitted HELLO messages. Such information has a limited duration
in which it is considered valid, this is determined from the
VALIDITY_TIME TLV in the HELLO message in which the information is
received, which in turn is set by the router which originated the
HELLO message, using its corresponding interface parameter
H_HOLD_TIME.
Appendix E illustrates the relationship between message reception,
included VALIDITY_TIME TLVs, and the duration for which information
received in a HELLO message is considered valid. Appendix F
illustrates some example two hop topologies and how they correspond
to information in the Information Bases.
4.2.1. Local Information Base 4.2.1. Local Information Base
Each router maintains a Local Information Base, which contains the Each router maintains a Local Information Base, which contains the
router's local configuration information, specifically: router's local configuration information, specifically:
o The Local Interface Set, which consists of Local Interface Tuples, o The Local Interface Set, which consists of Local Interface Tuples,
each of which represents an interface (MANET or non-MANET) of the each of which represents an interface (MANET or non-MANET) of the
router. router.
o The Removed Interface Address Set, which consists of Removed o The Removed Interface Address Set, which consists of Removed
skipping to change at page 14, line 9 skipping to change at page 14, line 29
Each HELLO message identifies the MANET interface for which it is Each HELLO message identifies the MANET interface for which it is
generated and transmitted; this allows recipients to identify that generated and transmitted; this allows recipients to identify that
MANET interface. Each HELLO message also reports the other MANET interface. Each HELLO message also reports the other
interfaces (MANET and non-MANET) of the router; this allows interfaces (MANET and non-MANET) of the router; this allows
recipients to associate a set of addresses with a single 1-hop recipients to associate a set of addresses with a single 1-hop
neighbor. Each HELLO message also includes 1-hop neighbor neighbor. Each HELLO message also includes 1-hop neighbor
information from the Information Bases; this allows detection of information from the Information Bases; this allows detection of
local symmetric links, and symmetric 2-hop neighbors. local symmetric links, and symmetric 2-hop neighbors.
HELLO message generation, and the validity of the information
recorded as a consequence of processing a HELLO message, is affected
by timers and validity information included in HELLO messages through
TLVs. The relationship between message timers and intervals is
illustrated in Appendix E.
4.3.1. HELLO Message Generation 4.3.1. HELLO Message Generation
HELLO messages are generated by a router for each of its MANET HELLO messages are generated by a router for each of its MANET
interfaces, and MAY be sent: interfaces, and MAY be sent:
o Proactively, at a regular interval, known as HELLO_INTERVAL. o Proactively, at a regular interval, known as HELLO_INTERVAL.
HELLO_INTERVAL may be fixed, or may be dynamic. For example HELLO_INTERVAL may be fixed, or may be dynamic. For example
HELLO_INTERVAL may be backed off due to congestion or network HELLO_INTERVAL may be backed off due to congestion or network
stability. stability.
skipping to change at page 18, line 21 skipping to change at page 18, line 45
The following interface parameters manage the validity time of link The following interface parameters manage the validity time of link
information: information:
L_HOLD_TIME - is the period of advertisement, on this MANET L_HOLD_TIME - is the period of advertisement, on this MANET
interface, of former 1-hop neighbor addresses as lost in HELLO interface, of former 1-hop neighbor addresses as lost in HELLO
messages, allowing recipients of these HELLO messages to messages, allowing recipients of these HELLO messages to
accelerate removal of this information from their Link Sets. accelerate removal of this information from their Link Sets.
L_HOLD_TIME MAY be set to zero, if accelerated information removal L_HOLD_TIME MAY be set to zero, if accelerated information removal
is not required. is not required.
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. included in all HELLO messages on this MANET interface. It is
then used by each router receiving such a HELLO message to
indicate the validity of the information taken from that HELLO
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
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.
skipping to change at page 24, line 20 skipping to change at page 24, line 42
5. otherwise, L_status := LOST. 5. otherwise, L_status := LOST.
7.2. 2-Hop Set 7.2. 2-Hop Set
A router's 2-Hop Set records addresses of symmetric 2-hop neighbors, A router's 2-Hop Set records addresses of symmetric 2-hop neighbors,
and the symmetric links to symmetric 1-hop neighbors through which and the symmetric links to symmetric 1-hop neighbors through which
these symmetric 2-hop neighbors can be reached. It consists of 2-Hop these symmetric 2-hop neighbors can be reached. It consists of 2-Hop
Tuples, each representing a single address of a symmetric 2-hop Tuples, each representing a single address of a symmetric 2-hop
neighbor, and a single MANET interface of a symmetric 1-hop neighbor. neighbor, and a single MANET interface of a symmetric 1-hop neighbor.
(N2_neighbor_iface_addr_list, N2_2hop_iface_addr, N2_time) (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)
where: where:
N2_neighbor_iface_addr_list is an unordered list of the addresses of N2_neighbor_iface_addr_list is an unordered list of the addresses of
the MANET interface of the symmetric 1-hop neighbor from which the MANET interface of the symmetric 1-hop neighbor from which
this information was received; this information was received;
N2_2hop_addr is an address of a symmetric 2-hop neighbor which has a
N2_2hop_iface_addr is an address of a symmetric 2-hop neighbor which symmetric link (using any MANET interface) to the indicated
has a symmetric link (using any MANET interface) to the indicated
symmetric 1-hop neighbor; symmetric 1-hop neighbor;
N2_time specifies when this Tuple expires and MUST be removed. N2_time specifies when this Tuple expires and MUST be removed.
8. Neighbor Information Base 8. Neighbor Information Base
Each router maintains a Neighbor Information Base that records Each router maintains a Neighbor Information Base that records
information about addresses of current and recently symmetric 1-hop information about addresses of current and recently symmetric 1-hop
neighbors. neighbors.
8.1. Neighbor Set 8.1. Neighbor Set
A router's Neighbor Set records all addresses of each 1-hop neighbor. A router's Neighbor Set records all addresses of each 1-hop neighbor.
It consists of Neighbor Tuples, each representing a single 1-hop It consists of Neighbor Tuples, each representing a single 1-hop
neighbor: neighbor:
(N_neighbor_iface_addr_list, N_symmetric) (N_neighbor_addr_list, N_symmetric)
where: where:
N_neighbor_iface_addr_list is an unordered list of the addresses of N_neighbor_addr_list is an unordered list of the addresses of a
a 1-hop neighbor; 1-hop neighbor;
N_symmetric is a boolean flag, describing if this is a symmetric N_symmetric is a boolean flag, describing if this is a symmetric
1-hop neighbor. 1-hop neighbor.
Neighbor Tuples are removed from the Neighbor Set only when Neighbor Tuples are removed from the Neighbor Set only when
corresponding Link Tuples expire from the routers' Link Set, i.e. corresponding Link Tuples expire from the routers' Link Set, i.e.
Neighbor Tuples are not directly subject to timer-based expiration. Neighbor Tuples are not directly subject to timer-based expiration.
8.2. Lost Neighbor Set 8.2. Lost Neighbor Set
A router's Lost Neighbor Set records addresses of routers which A router's Lost Neighbor Set records addresses of routers which
recently were symmetric 1-hop neighbors, but are now advertised as recently were symmetric 1-hop neighbors, but are now advertised as
lost. It consists of Lost Neighbor Tuples, each representing a lost. It consists of Lost Neighbor Tuples, each representing a
single such address: single such address:
(NL_neighbor_iface_addr, NL_time) (NL_neighbor_addr, NL_time)
where: where:
NL_neighbor_iface_addr is an address of a router which recently was NL_neighbor_addr is an address of a router which recently was a
a symmetric 1-hop neighbor of this router; symmetric 1-hop neighbor of this router;
NL_time specifies when this Tuple expires and MUST be removed. NL_time specifies when this Tuple expires and MUST be removed.
9. Local Information Base Changes 9. Local Information Base Changes
The Local Information Base MUST change to respond to changes in the The Local Information Base MUST change to respond to changes in the
router's local interface configuration. The router MUST update its router's local interface configuration. The router MUST update its
Interface Information Base and Neighbor Information Base in response Interface Information Base and Neighbor Information Base in response
to such changes. If any changes in the Interface Information Base or to such changes. If any changes in the Interface Information Base or
the Neighbor Information Base satisfy any of the conditions described the Neighbor Information Base satisfy any of the conditions described
in Section 13, then those changes must be applied immediately, unless in Section 13, then those changes must be applied immediately, unless
skipping to change at page 26, line 32 skipping to change at page 27, line 9
3. Remove that Local Interface Tuple from the Local Interface Set. 3. Remove that Local Interface Tuple from the Local Interface Set.
4. If the interface to be removed is a MANET interface (i.e. with 4. If the interface to be removed is a MANET interface (i.e. with
I_manet = true) then: I_manet = true) then:
1. Remove the Interface Information Base for that MANET 1. Remove the Interface Information Base for that MANET
interface; interface;
2. All Neighbor Tuples for which none of the addresses in its 2. All Neighbor Tuples for which none of the addresses in its
N_neighbor_iface_addr_list are contained in any N_neighbor_addr_list are contained in any
L_neighbor_iface_addr_list in any remaining Link Set, are L_neighbor_iface_addr_list in any remaining Link Set, are
removed. removed.
If a router removes the Local Interface Tuple that contains the
address which is used to define the router's originator address, as
defined in [RFC5444], then the router MAY change originator address.
If this address may now be used by another router (e.g., if the
address was taken from a prefix no longer delegated to this router,
or if the address was assigned with an expiration timer, and not
renewed before expiration) then this router MUST change its
originator address.
If the removed interface is the last MANET interface of the router, If the removed interface is the last MANET interface of the router,
then there will be no remaining Interface Information Bases, and the then there will be no remaining Interface Information Bases, and the
router will longer participate in this protocol. router will longer participate in this protocol.
After removing the interface and making these changes, a HELLO After removing the interface and making these changes, a HELLO
message MAY be sent on all remaining MANET interfaces. message MAY be sent on all remaining MANET interfaces.
9.3. Adding an Address to an Interface 9.3. Adding an Address to an Interface
If an address is added to an interface then this is indicated by the If an address is added to an interface then this is indicated by the
addition of an address to the appropriate I_local_iface_addr_list. addition of an address to the appropriate I_local_iface_addr_list.
The following changes MUST be made to the Information Bases: The following changes MUST be made to the Information Bases:
1. The Neighbor Tuples, if any, whose N_neighbor_iface_addr_list 1. The Neighbor Tuples, if any, whose N_neighbor_addr_list contains
contains the added address, are removed. the added address, are removed.
2. Any Link Tuples, in any Link Set, whose 2. Any Link Tuples, in any Link Set, whose
L_neighbor_iface_addr_list contains: L_neighbor_iface_addr_list contains:
* the added address; OR * the added address; OR
* any address in the N_neighbor_iface_addr_list of any removed * any address in the N_neighbor_addr_list of any removed
Neighbor Tuple Neighbor Tuple
are removed; apply Section 13.2, but not Section 13.3. are removed; apply Section 13.2, but not Section 13.3.
3. Any Lost Neighbor Tuples whose NL_neighbor_iface_addr = the added 3. Any Lost Neighbor Tuples whose NL_neighbor_addr = the added
address, are removed. address, are removed.
4. Any 2-Hop Tuples whose N2_2hop_iface_addr = the added address, 4. Any 2-Hop Tuples whose N2_2hop_addr = the added address, are
are removed. removed.
After adding the address and making these changes, a HELLO message After adding the address and making these changes, a HELLO message
MAY be sent on all MANET interfaces. MAY be sent on all MANET interfaces.
These changes, other than to the appropriate I_local_iface_addr_list, These changes, other than to the appropriate I_local_iface_addr_list,
are made in order to maintain consistency of the Information Bases. are made in order to maintain consistency of the Information Bases.
Specifically, these changes remove any record of any use of this Specifically, these changes remove any record of any use of this
address by routers in the 1-hop neighborhood or in the symmetric address by routers in the 1-hop neighborhood or in the symmetric
2-hop neighborhood of this router. 2-hop neighborhood of this router.
skipping to change at page 28, line 13 skipping to change at page 28, line 27
3. Otherwise: 3. Otherwise:
1. Remove the removed address from this I_local_iface_addr_list. 1. Remove the removed address from this I_local_iface_addr_list.
2. Create a Removed Interface Address Tuple with: 2. Create a Removed Interface Address Tuple with:
+ IR_local_iface_addr := removed address; + IR_local_iface_addr := removed address;
+ IR_time := current time + I_HOLD_TIME. + IR_time := current time + I_HOLD_TIME.
If a router removes the address that is used to define the router's
originator address, as defined in [RFC5444], then the router MAY
change originator address. If this address may now be used by
another router (e.g., if the address was taken from a prefix no
longer delegated to this router, or if the address was assigned with
an expiration timer, and not renewed before expiration) then this
router MUST change its originator address.
After removing the address and making these changes, a HELLO message After removing the address and making these changes, a HELLO message
MAY be sent on all MANET interfaces. MAY be sent on all MANET interfaces.
10. Packets and Messages 10. Packets and Messages
The packet and message format used by this protocol is defined in The packet and message format used by this protocol is defined in
[RFC5444], which is used with the following considerations: [RFC5444], which is used with the following considerations:
o This protocol specifies one Message Type, the HELLO message. o This protocol specifies one Message Type, the HELLO message.
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].
o HELLO messages MUST NOT be forwarded. o HELLO messages MUST NOT be forwarded.
o HELLO messages MAY be included in multi-message packets as o HELLO messages MAY be included in multi-message packets as
specified in [RFC5444]. specified in [RFC5444].
o Received HELLO messages MUST be parsed in accordance with o Received HELLO messages MUST be parsed in accordance with
[RFC5444]. A HELLO message which is not in conformance with [RFC5444]. A HELLO message which is not in conformance with
[RFC5444] MUST be discarded. A HELLO message may also be [RFC5444] MUST be discarded. A HELLO message may also be
discarded for other reasons, see Section 12.1. discarded for other reasons, see Section 12.1.
skipping to change at page 29, line 35 skipping to change at page 29, line 40
o One or more Address Blocks, each with an associated Address Block o One or more Address Blocks, each with an associated Address Block
TLV Block, which MAY contain other Address Block TLVs. TLV Block, which MAY contain other Address Block TLVs.
10.1.1. Address Blocks 10.1.1. Address Blocks
All addresses in a router's Local Interface Set (i.e. in any All addresses in a router's Local Interface Set (i.e. in any
I_local_iface_addr_list) MUST be included in the Address Blocks in I_local_iface_addr_list) MUST be included in the Address Blocks in
all generated HELLO messages with the following exception. If the all generated HELLO messages with the following exception. If the
MANET interface on which the HELLO message is to be sent has a single MANET interface on which the HELLO message is to be sent has a single
address with maximum prefix length, then that address MAY be omitted address with maximum prefix length (i.e. /32 for IPv4, /128 for
from being included in any Address Block, provided that this address IPv6), then that address MAY be omitted from being included in any
is included as the sending address of the IP datagram in which the Address Block, provided that this address is included as the sending
HELLO message is included. All addresses of the router's interfaces address of the IP datagram in which the HELLO message is included.
included in an Address Block MUST be associated with an Address Block All addresses of the router's interfaces included in an Address Block
TLV with Type = LOCAL_IF, as defined in Table 1. MUST be associated with an Address Block TLV with Type = LOCAL_IF, as
defined in Table 1.
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
| | Length | | | | Length | |
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
| LOCAL_IF | 1 octet | Specifies that the address is an address | | LOCAL_IF | 1 octet | Specifies that the address is an address |
| | | associated with the MANET interface on which | | | | associated with the MANET interface on which |
| | | the message was sent (THIS_IF) or another | | | | the message was sent (THIS_IF) or another |
| | | interface of the sending router (OTHER_IF). | | | | interface of the sending router (OTHER_IF). |
+----------+---------+----------------------------------------------+ +----------+---------+----------------------------------------------+
skipping to change at page 30, line 26 skipping to change at page 30, line 39
| | | (SYMMETRIC) or was (LOST) of an | | | | (SYMMETRIC) or was (LOST) of an |
| | | interface of a symmetric 1-hop neighbor | | | | interface of a symmetric 1-hop neighbor |
| | | of the router transmitting the HELLO | | | | of the router transmitting the HELLO |
| | | message. | | | | message. |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition Table 2: LINK_STATUS and OTHER_NEIGHB TLV definition
An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or
Value = LOST also performs the function of an Address Block TLV with Value = LOST also performs the function of an Address Block TLV with
Type = OTHER_NEIGHB and the same value. The latter SHOULD NOT also Type = OTHER_NEIGHB and the same Value. The latter SHOULD NOT also
be included associated with the same address. If an Address Block be included associated with the same address. If an Address Block
TLV with Type = LINK_STATUS and Value = SYMMETRIC is combined with an TLV with Type = LINK_STATUS and Value = SYMMETRIC is combined with an
Address Block TLV with Type = OTHER_NEIGHB and Value = LOST Address Block TLV with Type = OTHER_NEIGHB and Value = LOST
associated with the same address, then the latter MUST be ignored, associated with the same address, then the latter MUST be ignored,
and SHOULD NOT be included. See Appendix A. and SHOULD NOT be included. See Appendix A.
Other addresses MAY be included in Address Blocks, but MUST NOT be Other addresses MAY be included in Address Blocks, but MUST NOT be
associated with any of the Address Block TLVs specified in this associated with any of the Address Block TLVs specified in this
specification. specification.
skipping to change at page 31, line 14 skipping to change at page 31, line 30
least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1. least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.
11.1. HELLO Message Specification 11.1. HELLO Message Specification
HELLO messages are generated independently on each MANET interface. HELLO messages are generated independently on each MANET interface.
All addresses in any I_local_iface_addr_list MUST be included, except All addresses in any I_local_iface_addr_list MUST be included, except
that: that:
o If the interface on which the HELLO message is to be sent has a o If the interface on which the HELLO message is to be sent has a
single address with maximum prefix length then that address MAY be single address with maximum prefix length (i.e. /32 for IPv4, /128
omitted, provided that this address is included as the sending for IPv6) then that address MAY be omitted, provided that this
address of the IP datagram in which the HELLO message is included. address is included as the sending address of the IP datagram in
which the HELLO message is included.
All such included addresses MUST be associated with an Address Block All such included addresses MUST be associated with an Address Block
TLV with Type := LOCAL_IF and Value according to the following: TLV with Type := LOCAL_IF and Value according to the following:
o If the address is an address of the sending MANET interface, then o If the address is an address of the sending MANET interface, then
Value := THIS_IF. Value := THIS_IF.
o Otherwise, Value := OTHER_IF. o Otherwise, Value := OTHER_IF.
The following addresses of current or former 1-hop neighbors MAY be The following addresses of current or former 1-hop neighbors MAY be
included in any HELLO message, respecting the parameter included in any HELLO message, respecting the parameter
REFRESH_INTERVAL for each association for that MANET interface: REFRESH_INTERVAL for each association for that MANET interface:
o Addresses of MANET interfaces of 1-hop neighbors from the Link Set o Addresses of MANET interfaces of 1-hop neighbors from the Link Set
of the Interface Information Base for this MANET interface (i.e. of the Interface Information Base for this MANET interface (i.e.
from an L_neighbor_iface_addr_list), other than those from Link from an L_neighbor_iface_addr_list), other than those from Link
Tuples with L_status = PENDING. Tuples with L_status = PENDING.
o Other addresses of symmetric 1-hop neighbors from the Neighbor Set o Other addresses of symmetric 1-hop neighbors from the Neighbor Set
of this router's Neighbor Information Base (i.e. from an of this router's Neighbor Information Base (i.e. from an
N_neighbor_iface_addr_list). N_neighbor_addr_list).
o Addresses of MANET interfaces of previously symmetric or heard o Addresses of MANET interfaces of previously symmetric or heard
1-hop neighbors connected on this MANET interface from the Link 1-hop neighbors connected on this MANET interface from the Link
Set of the Interface Information Base for this MANET interface Set of the Interface Information Base for this MANET interface
(i.e. from an L_neighbor_iface_addr_list with L_status = LOST). (i.e. from an L_neighbor_iface_addr_list with L_status = LOST).
o Other addresses of previously symmetric 1-hop neighbors from the o Other addresses of previously symmetric 1-hop neighbors from the
Lost Neighbor Set of this router's Neighbor Information Base (i.e. Lost Neighbor Set of this router's Neighbor Information Base (i.e.
from an NL_neighbor_iface_addr). from an NL_neighbor_addr).
Each such address MUST be associated with one or more appropriate Each such address MUST be associated with one or more appropriate
Address Block TLVs. Specifically: Address Block TLVs. Specifically:
1. For each address (henceforth linked address) which is contained 1. For each address (henceforth linked address) which is contained
in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set
for this MANET interface, for which L_status != PENDING, include for this MANET interface, for which L_status != PENDING, include
the linked address with an associated Address Block TLV with: the linked address with an associated Address Block TLV with:
* Type := LINK_STATUS; AND * Type := LINK_STATUS; AND
* Value := L_status. * Value := L_status.
2. For each address (henceforth neighbor address) which is contained 2. For each address (henceforth neighbor address) which is contained
in an N_neighbor_iface_addr_list in a Neighbor Tuple with in an N_neighbor_addr_list in a Neighbor Tuple with N_symmetric =
N_symmetric = true, and which has not already been included with true, and which has not already been included with an associated
an associated Address Block TLV with Type = LINK_STATUS and Value Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC,
= SYMMETRIC, include the neighbor address with an associated include the neighbor address with an associated Address Block TLV
Address Block TLV with: with:
* Type := OTHER_NEIGHB; AND * Type := OTHER_NEIGHB; AND
* Value := SYMMETRIC. * Value := SYMMETRIC.
3. For each Lost Neighbor Tuple whose NL_neighbor_iface_addr 3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth
(henceforth lost address) has not already been included, include lost address) has not already been included, include the lost
the lost address with an associated Address Block TLV with: address with an associated Address Block TLV with:
* Type := OTHER_NEIGHB; AND * Type := OTHER_NEIGHB; AND
* Value := LOST. * Value := LOST.
If any such addresses have been added to these Information Bases If any such addresses have been added to these Information Bases
since the last HELLO message was sent on this MANET interface, or if since the last HELLO message was sent on this MANET interface, or if
their status (as indicated by these TLVs and the values they their status (as indicated by these TLVs and the Values they
associate with that address) have changed since that address was last associate with that address) have changed since that address was last
reported on this MANET interface, then that address, and the reported on this MANET interface, then that address, and the
indicated TLVs, MUST be included in the HELLO message. indicated TLVs, MUST be included in the HELLO message.
If an address of a 1-hop neighbor is specified with more than one If an address of a 1-hop neighbor is specified with more than one
associated Address Block TLV, then these Address Block TLVs MAY be associated Address Block TLV, then these Address Block TLVs MAY be
independently included or excluded from each HELLO message. Each independently included or excluded from each HELLO message. Each
such Address Block TLV MUST be included associated with that address such Address Block TLV MUST be included associated with that address
in a HELLO message sent on that MANET interface in every interval of in a HELLO message sent on that MANET interface in every interval of
length equal to that MANET interface's parameter REFRESH_INTERVAL. length equal to that MANET interface's parameter REFRESH_INTERVAL.
skipping to change at page 34, line 12 skipping to change at page 34, line 28
is invalid, considers only TLVs with Type Extension = 0. TLVs with is invalid, considers only TLVs with Type Extension = 0. TLVs with
any other type extension are ignored. All references to, for any other type extension are ignored. All references to, for
example, a TLV with Type = LINK_STATUS refer to a TLV with Type = example, a TLV with Type = LINK_STATUS refer to a TLV with Type =
LINK_STATUS and Type Extension = 0. LINK_STATUS and Type Extension = 0.
12.1. Invalid Message 12.1. Invalid Message
A received HELLO message is invalid for processing by this router if A received HELLO message is invalid for processing by this router if
any of the following conditions are true: any of the following conditions are true:
o The address length as specified in the the Message Header is not o The address length as specified in the Message Header is not equal
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 need not have a
<msg-hop-limit> field.) <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 need not have a
<msg-hop-count> field.) <msg-hop-count> field.)
o The message does not have a Message TLV with Type = VALIDITY_TIME o The message does not have a Message TLV with Type = VALIDITY_TIME
in its Message TLV Block. in its Message TLV Block.
o The message has more than one Message TLV with Type = o The message has more than one Message TLV with Type =
VALIDITY_TIME in its Message TLV Block. VALIDITY_TIME in its Message TLV Block.
o The message has more than one Message TLV with Type = o The message has more than one Message TLV with Type =
INTERVAL_TIME in its Message TLV Block. INTERVAL_TIME in its Message TLV Block.
o The message has any Address Block TLV(s) with Type = LOCAL_IF and o The message has any Address Block TLV(s) with Type = LOCAL_IF and
any single value v such that v != THIS_IF and v != OTHER_IF. any single Value v such that v != THIS_IF and v != OTHER_IF.
o Any address (including different copies of an address, in the same o Any address (including different copies of an address, in the same
or different Address Blocks) is associated with more than one or different Address Blocks) is associated with more than one
value by one or more Address Block TLV(s) with Type = LOCAL_IF. Value by one or more Address Block TLV(s) with Type = LOCAL_IF.
o Any address (henceforth the local address) associated with an o Any address (henceforth the local address) associated with an
Address Block TLV with Type = LOCAL_IF is one of the receiving Address Block TLV with Type = LOCAL_IF is one of the receiving
router's current or recently used addresses (i.e. the local router's current or recently used addresses (i.e. the local
address is contained in any I_local_iface_addr_list in the Local address is contained in any I_local_iface_addr_list in the Local
Interface Set or the local address = any IR_local_iface_addr in Interface Set or the local address = any IR_local_iface_addr in
the Removed Interface Address Set). the Removed Interface Address Set).
o The message has any Address Block TLV(s) with Type = LINK_STATUS o The message has any Address Block TLV(s) with Type = LINK_STATUS
with any single value v such that v != LOST, v != SYMMETRIC, and v with any single Value v such that v != LOST, v != SYMMETRIC, and v
!= HEARD. != HEARD.
o Any address (including different copies of an address, in the same o Any address (including different copies of an address, in the same
or different Address Blocks) is associated with more than one or different Address Blocks) is associated with more than one
value by one or more Address Block TLVs with Type = LINK_STATUS. Value by one or more Address Block TLVs with Type = LINK_STATUS.
o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB
with any single value v such that v != LOST and v != SYMMETRIC. with any single Value v such that v != LOST and v != SYMMETRIC.
o Any address (including different copies of an address, in the same o Any address (including different copies of an address, in the same
or different Address Blocks) is associated with more than one or different Address Blocks) is associated with more than one
value by one or more Address Block TLVs with Type = OTHER_NEIGHB. Value by one or more Address Block TLVs with Type = OTHER_NEIGHB.
A router MAY recognize additional reasons for identifying that a
message is badly formed and therefore invalid for processing.
An invalid message MUST be silently discarded, without updating the An invalid message MUST be silently discarded, without updating the
router's Information Bases. A router MAY recognize additional router's Information Bases.
reasons for identifying that a message is badly formed, and discard
such messages.
12.2. Definitions 12.2. Definitions
For the purpose of this section, note the following definitions: For the purpose of this section, note the following definitions:
o "validity time" is calculated from the Message TLV with Type = o "validity time" is calculated from the Message TLV with Type =
VALIDITY_TIME of the HELLO message as specified in [RFC5497]. VALIDITY_TIME of the HELLO message as specified in [RFC5497].
(Note that, as specified by Section 12.1, there must be exactly (Note that, as specified by Section 12.1, there must be exactly
one such Message TLV in the HELLO message.) All information in one such Message TLV in the HELLO message.) All information in
the HELLO message used by this specification has the same validity the HELLO message used by this specification has the same validity
time. time.
o "Receiving Address List" is the I_local_iface_addr_list o "Receiving Address List" is the I_local_iface_addr_list
corresponding to the MANET interface on which the HELLO message corresponding to the MANET interface on which the HELLO message
was received was received
o "Sending Address List" is the list of the addresses contained in o "Sending Address List" is the list of the addresses contained in
the HELLO message with an associated Address Block TLV with Type = the HELLO message with an associated Address Block TLV with Type =
LOCAL_IF and Value = THIS_IF. If the Sending Address List is LOCAL_IF and Value = THIS_IF. If the Sending Address List is
otherwise empty, then the Sending Address List contains a single otherwise empty, then the Sending Address List contains a single
address (with maximum prefix length) equal to the sending address address (with maximum prefix length, i.e. /32 for IPv64, /128 for
of the IP datagram in which the HELLO message was included. IPv6) equal to the sending address of the IP datagram in which the
HELLO message was included.
o "Neighbor Address List" is the Sending Address List, plus the o "Neighbor Address List" is the Sending Address List, plus the
addresses contained in the HELLO message with an associated addresses contained in the HELLO message with an associated
Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF. Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF.
o EXPIRED indicates that a timer is set to a value clearly preceding o EXPIRED indicates that a timer is set to a value clearly preceding
the current time (e.g., current time - 1). the current time (e.g., current time - 1).
o "Removed Address List" is a list of addresses created by this o "Removed Address List" is a list of addresses created by this
HELLO message processing which were formerly reported as local by HELLO message processing which were formerly reported as local by
skipping to change at page 36, line 17 skipping to change at page 36, line 34
This list is initialized as empty. This list is initialized as empty.
12.3. Updating the Neighbor Set 12.3. Updating the Neighbor Set
On receiving a HELLO message, the router MUST update its Neighbor Set On receiving a HELLO message, the router MUST update its Neighbor Set
and populate the Removed Address List and Lost Address List: and populate the Removed Address List and Lost Address List:
1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples) 1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples)
where: where:
* N_neighbor_iface_addr_list contains at least one address in * N_neighbor_addr_list contains at least one address in the
the Neighbor Address List. Neighbor Address List.
2. If there are no matching Neighbor Tuples, then: 2. If there are no matching Neighbor Tuples, then:
1. Create a new Neighbor Tuple with: 1. Create a new Neighbor Tuple with:
+ N_neighbor_iface_addr_list := Neighbor Address List; + N_neighbor_addr_list := Neighbor Address List;
+ N_symmetric := false. + N_symmetric := false.
3. If there is one matching Neighbor Tuple, then: 3. If there is one matching Neighbor Tuple, then:
1. If the matching Neighbor Tuple's N_neighbor_iface_addr_list 1. If the matching Neighbor Tuple's N_neighbor_addr_list !=
!= Neighbor Address List, then: Neighbor Address List, then:
1. For each address (henceforth removed address) which is 1. For each address (henceforth removed address) which is
contained in that N_neighbor_iface_addr_list, but is not contained in that N_neighbor_addr_list, but is not
contained in the Neighbor Address List: contained in the Neighbor Address List:
1. Add the removed address to the Removed Address List. 1. Add the removed address to the Removed Address List.
2. If N_symmetric = true, then add the removed address 2. If N_symmetric = true, then add the removed address
to the Lost Address List. to the Lost Address List.
2. Update the matching Neighbor Tuple by: 2. Update the matching Neighbor Tuple by:
- N_neighbor_iface_addr_list := Neighbor Address List. - N_neighbor_addr_list := Neighbor Address List.
4. If there are two or more matching Neighbor Tuples, then: 4. If there are two or more matching Neighbor Tuples, then:
1. For each address (henceforth removed address) which is 1. For each address (henceforth removed address) which is
contained in the N_neighbor_iface_addr_list of any of the contained in the N_neighbor_addr_list of any of the matching
matching Neighbor Tuples: Neighbor Tuples:
1. Add the removed address to the Removed Address List. 1. Add the removed address to the Removed Address List.
2. If N_symmetric = true, then add the removed address to 2. If N_symmetric = true, then add the removed address to
the Lost Address List. the Lost Address List.
2. Replace the matching Neighbor Tuples by a single Neighbor 2. Replace the matching Neighbor Tuples by a single Neighbor
Tuple with: Tuple with:
+ N_neighbor_iface_addr_list := Neighbor Address List; + N_neighbor_addr_list := Neighbor Address List;
+ N_symmetric := false + N_symmetric := false
12.4. Updating the Lost Neighbor Set 12.4. Updating the Lost Neighbor Set
On receiving a HELLO message, a router MUST update its Lost Neighbor On receiving a HELLO message, a router MUST update its Lost Neighbor
Set: Set:
1. For each address (henceforth lost address) which is contained in 1. For each address (henceforth lost address) which is contained in
the Lost Address List, if no Lost Neighbor Tuple with the Lost Address List, if no Lost Neighbor Tuple with
NL_neighbor_iface_addr = lost address exists, then add a Lost NL_neighbor_addr = lost address exists, then add a Lost Neighbor
Neighbor Tuple with: Tuple with:
* NL_neighbor_iface_addr := lost address; * NL_neighbor_addr := lost address;
* NL_time := current time + N_HOLD_TIME. * NL_time := current time + N_HOLD_TIME.
12.5. Updating the Link Set 12.5. Updating the Link Set
On receiving a HELLO message, a router MUST update its Link Set for On receiving a HELLO message, a router MUST update its Link Set for
the MANET interface on which the HELLO message is received: the MANET interface on which the HELLO message is received:
1. Remove all addresses in the Removed Address List from the 1. Remove all addresses in the Removed Address List from the
L_neighbor_iface_addr_list of all Link Tuples. L_neighbor_iface_addr_list of all Link Tuples.
skipping to change at page 39, line 47 skipping to change at page 40, line 16
- Type = LINK_STATUS and Value = SYMMETRIC; OR - Type = LINK_STATUS and Value = SYMMETRIC; OR
- Type = OTHER_NEIGHB and Value = SYMMETRIC, - Type = OTHER_NEIGHB and Value = SYMMETRIC,
then, if there is no 2-Hop Tuple such that: then, if there is no 2-Hop Tuple such that:
- N2_neighbor_iface_addr_list contains one or more - N2_neighbor_iface_addr_list contains one or more
addresses in the Sending Address List; AND addresses in the Sending Address List; AND
- N2_2hop_iface_addr = 2-hop address. - N2_2hop_addr = 2-hop address.
then create a 2-Hop Neighbor Tuple with: then create a 2-Hop Neighbor Tuple with:
- N2_2hop_iface_addr := 2-hop address. - N2_2hop_addr := 2-hop address.
This 2-Hop Tuple (existing or new) is then modified as This 2-Hop Tuple (existing or new) is then modified as
follows: follows:
- N2_neighbor_iface_addr_list := Sending Address List; - N2_neighbor_iface_addr_list := Sending Address List;
- N2_time := current time + validity time. - N2_time := current time + validity time.
5. Otherwise if the 2-hop address has an Address Block TLV 5. Otherwise if the 2-hop address has an Address Block TLV
with: with:
skipping to change at page 40, line 25 skipping to change at page 40, line 42
- Type = LINK_STATUS and Value = LOST or Value = HEARD; - Type = LINK_STATUS and Value = LOST or Value = HEARD;
OR OR
- Type = OTHER_NEIGHB and Value = LOST; - Type = OTHER_NEIGHB and Value = LOST;
then remove all 2-Hop Tuples with: then remove all 2-Hop Tuples with:
- N2_neighbor_iface_addr_list contains one or more - N2_neighbor_iface_addr_list contains one or more
addresses in the Sending Address List; AND addresses in the Sending Address List; AND
- N2_2hop_iface_addr = 2-hop address. - N2_2hop_addr = 2-hop address.
13. Other Information Base Changes 13. Other Information Base Changes
The Interface and Neighbor Information Bases MUST be changed when The Interface and Neighbor Information Bases MUST be changed when
certain events occur. These events may result from HELLO message certain events occur. These events may result from HELLO message
processing, or may be otherwise generated (e.g., expiry of timers or processing, or may be otherwise generated (e.g., expiry of timers or
link quality changes). link quality changes).
Events which cause changes in the Information Bases are: Events which cause changes in the Information Bases are:
skipping to change at page 41, line 5 skipping to change at page 41, line 23
In this case, the actions specified in Section 13.3 are performed. In this case, the actions specified in Section 13.3 are performed.
o Local interface address changes. In this case, the actions o Local interface address changes. In this case, the actions
specified in Section 9 are performed. specified in Section 9 are performed.
o Link quality changes. In this case, the actions specified in o Link quality changes. In this case, the actions specified in
Section 14 are performed. Section 14 are performed.
If a Link Tuple is removed, or if L_status changes from SYMMETRIC and If a Link Tuple is removed, or if L_status changes from SYMMETRIC and
L_HEARD_time expires, then the actions specified in Section 13.2 MUST L_HEARD_time expires, then the actions specified in Section 13.2 MUST
be performed before the actions specified in section Section 13.3 are be performed before the actions specified in Section 13.3 are
performed for that Link Tuple. performed for that Link Tuple.
A router MAY report updated information in response to any of these A router MAY report updated information in response to any of these
changes in HELLO message(s), subject to the constraints in changes in HELLO message(s), subject to the constraints in
Section 11. Section 11.
A router which transmits HELLO messages in response to such changes A router which transmits HELLO messages in response to such changes
SHOULD transmit a HELLO message: SHOULD transmit a HELLO message:
o On all MANET interfaces, if the Neighbor Set changes such as to o On all MANET interfaces, if the Neighbor Set changes such as to
skipping to change at page 41, line 33 skipping to change at page 41, line 51
13.1. Link Tuple Symmetric 13.1. Link Tuple Symmetric
If, for any Link Tuple which does not have L_status = SYMMETRIC: If, for any Link Tuple which does not have L_status = SYMMETRIC:
o L_status changes to SYMMETRIC; o L_status changes to SYMMETRIC;
(this includes a newly created Link Tuple which is immediately (this includes a newly created Link Tuple which is immediately
updated such that L_status = SYMMETRIC) then: updated such that L_status = SYMMETRIC) then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list, set: L_neighbor_iface_addr_list, set:
* N_symmetric := true. * N_symmetric := true.
2. Remove all Lost Neighbor Tuples whose NL_neighbor_iface_addr is 2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is
contained in that N_neighbor_iface_addr_list. contained in that N_neighbor_addr_list.
13.2. Link Tuple Not Symmetric 13.2. Link Tuple Not Symmetric
If for any Link Tuple with L_status = SYMMETRIC: If for any Link Tuple with L_status = SYMMETRIC:
o L_status changes to any other value; OR o L_status changes to any other value; OR
o the Link Tuple is removed; o the Link Tuple is removed;
then: then:
1. All 2-Hop Tuples for the same MANET interface with: 1. All 2-Hop Tuples for the same MANET interface with:
* N2_neighbor_iface_addr_list contains one or more addresses in * N2_neighbor_iface_addr_list contains one or more addresses in
L_neighbor_iface_addr_list; L_neighbor_iface_addr_list;
are removed. are removed.
2. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 2. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list: L_neighbor_iface_addr_list:
1. If there are no remaining Link Tuples for any MANET interface 1. If there are no remaining Link Tuples for any MANET interface
where: where:
+ L_neighbor_iface_addr_list is contained in + L_neighbor_iface_addr_list is contained in
N_neighbor_iface_addr_list; AND N_neighbor_addr_list; AND
+ L_status = SYMMETRIC; + L_status = SYMMETRIC;
then modify the Neighbor Tuple by: then modify the Neighbor Tuple by:
1. N_symmetric := false. 1. N_symmetric := false.
2. For each address (henceforth neighbor address) in 2. For each address (henceforth neighbor address) in
N_neighbor_iface_addr_list, add a Lost Neighbor Tuple N_neighbor_addr_list, add a Lost Neighbor Tuple with:
with:
- NL_neighbor_iface_addr := neighbor address; - NL_neighbor_addr := neighbor address;
- NL_time := current time + N_HOLD_TIME. - NL_time := current time + N_HOLD_TIME.
13.3. Link Tuple Heard Timeout 13.3. Link Tuple Heard Timeout
If, for any Link Tuple: If, for any Link Tuple:
o L_HEARD_time expires; OR o L_HEARD_time expires; OR
o the Link Tuple is removed; o the Link Tuple is removed;
then: then:
1. For the Neighbor Tuple whose N_neighbor_iface_addr_list contains 1. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list, if no Link Tuples for any MANET L_neighbor_iface_addr_list, if no Link Tuples for any MANET
interface remain where: interface remain where:
* L_neighbor_iface_addr_list is contained in * L_neighbor_iface_addr_list is contained in
N_neighbor_iface_addr_list; AND N_neighbor_addr_list; AND
* 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.
skipping to change at page 47, line 33 skipping to change at page 47, line 42
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, be
to allow a security protocol, as suggested in Section 17, to add a to allow a security protocol, as suggested in Section 17, to add a
TLV containing a cryptographic signature to the message, or be to TLV containing a cryptographic signature to the message, or be to
allow inserting relay selection information into a HELLO message allow inserting relay selection information into a HELLO message
by way of adding a TLV to an outgoing HELLO message prior to it by way of adding a TLV to an outgoing HELLO message prior to it
being transmitted. being transmitted.
o Through accessing an incoming HELLO message, and potentially o Through accessing an incoming HELLO message, and potentially
discard 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
selection information by way of inclusion of appropriate TLVs, selection information by way of inclusion of appropriate TLVs,
access to such information after appropriate updates have been access to such information after appropriate updates have been
recorded in the Information Bases in this protocol. recorded in the Information Bases in this protocol.
o Through requesting that a HELLO message be generated at a specific o Through requesting that a HELLO message be generated at a specific
time. In that case, HELLO message generation MUST still respect time. In that case, HELLO message generation MUST still respect
the constraints in Appendix B. the constraints in Appendix B.
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 message symmetric 2-hop neighborhood. This is acquired through HELLO message
exchange between neighboring routers. The 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. The 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
protocol sets through the defined processing that maintains the Information Bases through the specified processing, which maintains
constraints in Appendix B. The exact consequence of information the constraints in Appendix B. The exact consequence of information
inexactness depends on the use of these Information Bases, and should inexactness depends on the use of these Information Bases, and should
be reflected in the specification of protocols which use information be reflected in the specification of protocols which use information
provided by NHDP. provided by this neighborhood discovery protocol.
This section, therefore, only outlines the ways in which correctly This section, therefore, firstly outlines the ways in which correctly
formed, but still invalid, HELLO messages may appear, in formed, but still invalid, HELLO messages may appear, in
Section 17.1. In addition, in Section 17.2, the security suggestions Section 17.1.
in [RFC5444] are considered for applicability.
Injection of invalid HELLO messages into a network may be prevented
by different means. If, for example, a network is deployed in a site
to which access is strictly regulated, in order that physical access
and proximity to the network is prevented, then further security
mechanisms to protect against malicious routers injecting invalid
HELLO messages may not be required. Similarly, if the link layer
over which the network is formed provides appropriate
confidentiality, authentication, and integrity, then this may, for a
given deployment, suffice to appropriately protect against disclosure
of information to an eavesdropper, and against a malicious router
injecting invalid HELLO messages. In the latter case the link layer
would discard frames that fail the link layer checks, without
attempting to deliver such frames to IP. Finally, certain usage may
be of a nature where disruption of service is of no consequence, or
at least not of sufficient consequence to warrant deployment of
additional security mechanisms.
A further point to stress, and which follows from the discussions
above is, that it will not be the case that "one size security fits
all". Different deployments may have different requirements. For
example in a deployment of a low value sensor network, authentication
using a simple message authentication code and shared symmetric keys
may suffice, while anything beyond that may require too many
computational resources to be viable. Conversely, in, for example, a
community network, verifying not only that the originator of a HELLO
message "has the right key" but also the precise identity of the
originator may be required to be proved, and computational resources
may be available to make such a requirement feasible.
Section 17.2, therefore, does not specify a single "one-size-fits-
all" mechanism, but rather details how the security suggestions in
[RFC5444] are considered for applicability within the context of this
protocol, and with the purpose of aiding deployment-specific security
mechanisms to be developed.
17.1. Invalid HELLO messages 17.1. Invalid HELLO messages
A correctly formed, but still invalid, HELLO message may take any of A correctly formed, but still invalid, HELLO message may take any of
the following forms. Note that a present or absent address in an the following forms. Note that a present or absent address in an
Address Block, does not in and by itself cause a problem. It is the Address Block, does not in and by itself cause a problem. It is the
presence, absence, or incorrectness of associated LOCAL_IF, presence, absence, or incorrectness of associated LOCAL_IF,
LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems. LINK_STATUS and OTHER_NEIGHB Address Block TLVs that causes problems.
A router may provide false information about its own identity: A router may provide false information about its own identity:
skipping to change at page 49, line 7 skipping to change at page 49, line 47
LOCAL_IF Address Block TLV which do not correspond to addresses LOCAL_IF Address Block TLV which do not correspond to addresses
of interfaces of the router transmitting the HELLO message. of interfaces of the router transmitting the HELLO message.
* The HELLO message may omit addresses, or their associated * The HELLO message may omit addresses, or their associated
LOCAL_IF Address Block TLV, of interfaces of the router LOCAL_IF Address Block TLV, of interfaces of the router
transmitting the HELLO message (other than the allowed omission transmitting the HELLO message (other than the allowed omission
of the only local interface address of the MANET interface over of the only local interface address of the MANET interface over
which the HELLO message is transmitted, if that is the case). which the HELLO message is transmitted, if that is the case).
* The HELLO message may incorrectly specify the LOCAL_IF Address * The HELLO message may incorrectly specify the LOCAL_IF Address
Block TLV value associated with one or more local interface Block TLV Value associated with one or more local interface
addresses, indicating incorrectly whether they are associated addresses, indicating incorrectly whether they are associated
with the MANET interface over which the HELLO message is with the MANET interface over which the HELLO message is
transmitted. transmitted.
A router may provide false information about the identity of other A router may provide false information about the identity of other
routers: routers:
* A present LINK_STATUS Address Block TLV may, incorrectly, * A present LINK_STATUS Address Block TLV may, incorrectly,
identify an address as being of a MANET interface which is or identify an address as being of a MANET interface which is or
was heard on the MANET interface over which the HELLO message was heard on the MANET interface over which the HELLO message
skipping to change at page 49, line 34 skipping to change at page 50, line 27
* A present OTHER_NEIGHB Address Block TLV may, incorrectly, * A present OTHER_NEIGHB Address Block TLV may, incorrectly,
identify an address as being of a router which is or was in the identify an address as being of a router which is or was in the
sending router's symmetric 1-hop neighborhood; sending router's symmetric 1-hop neighborhood;
* A consistently absent OTHER_NEIGHB Address Block TLV may, * A consistently absent OTHER_NEIGHB Address Block TLV may,
incorrectly, fail to identify an address as being of a router incorrectly, fail to identify an address as being of a router
which is or was in the sending router's symmetric 1-hop 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
The security suggestions in [RFC5444] regarding inclusion of a The security suggestions in [RFC5444] regarding inclusion of a
cryptographic signature in a Message TLV or a Packet TLV can be cryptographic signature in a Message TLV or a Packet TLV can be
applied to this protocol. Failure to verify either form of applied to this protocol. Failure to verify either form of
cryptographic signature causes a HELLO message to be rejected without cryptographic signature should cause a HELLO message to be rejected
being processed. without being processed.
The following simplification of the suggestions for end-to-end The following simplification of the suggestions for end-to-end
authentication and integrity in [RFC5444] may be applied to HELLO authentication for integrity in [RFC5444] may be applied to HELLO
messages: messages:
o As the Message Header fields <msg-hop-count> and <msg-hop-limit> o As the Message Header fields <msg-hop-count> and <msg-hop-limit>
are either omitted or will always have the values 0 and 1, are either omitted or will always have the values 0 and 1,
respectively, an end to end cryptographic signature can be respectively, an end to end cryptographic signature can be
calculated based on the entire HELLO message, including its calculated based on the entire HELLO message, including its
unmodified Message Header. unmodified Message Header.
The security mechanisms suggested in [RFC5444] with respect to The security mechanisms suggested in [RFC5444] with respect to
confidentiality can be directly applied to this protocol. confidentiality can be directly applied to this protocol.
skipping to change at page 52, line 30 skipping to change at page 53, line 18
| OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is | | OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is |
| | | | (SYMMETRIC) or recently was | | | | | (SYMMETRIC) or recently was |
| | | | (LOST) of an interface of a | | | | | (LOST) of an interface of a |
| | | | symmetric 1-hop neighbor of the | | | | | symmetric 1-hop neighbor of the |
| | | | router transmitting the message | | | | | router transmitting the message |
| Unassigned | TBD4 | 1-255 | Expert Review | | Unassigned | TBD4 | 1-255 | Expert Review |
+--------------+------+-----------+---------------------------------+ +--------------+------+-----------+---------------------------------+
Table 8: Address Block TLV Type assignment: OTHER_NEIGHB Table 8: Address Block TLV Type assignment: OTHER_NEIGHB
18.5. LINK_STATUS and OTHER_NEIGHB Values 18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values
The values which the LOCAL_IF Address Block TLV can use are the The Values which the LOCAL_IF Address Block TLV can use are the
following: following:
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:
o LOST := 0 o LOST := 0
o SYMMETRIC := 1 o SYMMETRIC := 1
o HEARD := 2 o HEARD := 2
The values which the OTHER_NEIGHB Address Block TLV can use are the The Values which the OTHER_NEIGHB Address Block TLV can use are the
following: following:
o LOST := 0 o LOST := 0
o SYMMETRIC := 1 o SYMMETRIC := 1
19. Contributors 19. Contributors
This specification is the result of the joint efforts of the This specification is the result of the joint efforts of the
following contributors, listed alphabetically. following contributors, listed alphabetically.
skipping to change at page 54, line 30 skipping to change at page 55, line 16
[RFC5449] Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet, [RFC5449] Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet,
"OSPF Multipoint Relay (MPR) Extension for Ad Hoc "OSPF Multipoint Relay (MPR) Extension for Ad Hoc
Networks", RFC 5449, February 2009. Networks", RFC 5449, February 2009.
Appendix A. Address Block TLV Combinations Appendix A. Address Block TLV Combinations
The algorithm for generating HELLO messages in Section 11 specifies The algorithm for generating HELLO messages in Section 11 specifies
which 1-hop addresses may be included in the Address Blocks, and with which 1-hop addresses may be included in the Address Blocks, and with
which associated Address Block TLVs. These Address Block TLVs may which associated Address Block TLVs. These Address Block TLVs may
have Type = LINK_STATUS or Type = OTHER_NEIGHB, or both. Address have Type = LINK_STATUS or Type = OTHER_NEIGHB, or both. Address
Block TLVs with Type = LINK_STATUS may have three possible values Block TLVs with Type = LINK_STATUS may have three possible Values
(Value = HEARD, Value = SYMMETRIC or Value = LOST), and Address Block (Value = HEARD, Value = SYMMETRIC or Value = LOST), and Address Block
TLVs of TYPE = OTHER_NEIGHB may have two possible values (Value = TLVs of TYPE = OTHER_NEIGHB may have two possible Values (Value =
SYMMETRIC or Value = LOST). When both Address Block TLVs are SYMMETRIC or Value = LOST). When both Address Block TLVs are
associated with the same address only certain combinations of these associated with the same address only certain combinations of these
Address Block TLV values are necessary, and are the only combinations Address Block TLV Values are necessary, and are the only combinations
generated by the algorithm in Section 11. These combinations are generated by the algorithm in Section 11. These combinations are
indicated in Table 9. indicated in Table 9.
Cells labeled with "Yes" indicate the possible combinations which are Cells labeled with "Yes" indicate the possible combinations which are
generated by the algorithm in Section 11. Cells labeled with "No" generated by the algorithm in Section 11. Cells labeled with "No"
indicate combinations not generated by the algorithm in Section 11, indicate combinations not generated by the algorithm in Section 11,
but which are correctly parsed and interpreted by the algorithm in but which are correctly parsed and interpreted by the algorithm in
Section 12. The cell labeled with "No*" is actually inconsistent, it Section 12. The cell labeled with "No*" is actually inconsistent, it
is handled by ignoring the Address Block TLV with Type = is handled by ignoring the Address Block TLV with Type =
OTHER_NEIGHB. OTHER_NEIGHB.
skipping to change at page 56, line 19 skipping to change at page 57, line 19
IR_local_iface_addr of any Removed Interface Address Tuple. IR_local_iface_addr of any Removed Interface Address Tuple.
o L_neighbor_iface_addr_list MUST NOT contain any duplicated o L_neighbor_iface_addr_list MUST NOT contain any duplicated
addresses. addresses.
o L_neighbor_iface_addr_list MUST NOT contain any address which is o L_neighbor_iface_addr_list MUST NOT contain any address which is
in the L_neighbor_iface_addr_list of any other Link Tuple in the in the L_neighbor_iface_addr_list of any other Link Tuple in the
same Link Set. same Link Set.
o If L_HEARD_time has not expired then there MUST be a Neighbor o If L_HEARD_time has not expired then there MUST be a Neighbor
Tuple whose N_neighbor_iface_addr_list contains Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list. L_neighbor_iface_addr_list.
o L_HEARD_time MUST NOT be greater than L_time. o L_HEARD_time MUST NOT be greater than L_time.
o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are
expired). expired).
o L_quality MUST NOT be less than 0 or greater than 1. o L_quality MUST NOT be less than 0 or greater than 1.
o If L_quality >= HYST_ACCEPT then L_pending MUST be false. o If L_quality >= HYST_ACCEPT then L_pending MUST be false.
o If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST. o If L_quality < HYST_REJECT then L_status MUST be PENDING or LOST.
o L_pending MUST NOT be set to true if it is currently false. o L_pending MUST NOT be set to true if it is currently false.
In each Neighbor Tuple: In each Neighbor Tuple:
o N_neighbor_iface_addr_list MUST NOT contain any address which is o N_neighbor_addr_list MUST NOT contain any address which is in the
in the I_local_iface_addr_list of any Local Interface Tuple or the I_local_iface_addr_list of any Local Interface Tuple or the
IR_local_iface_addr of any Removed Interface Address Tuple. IR_local_iface_addr of any Removed Interface Address Tuple.
o N_neighbor_iface_addr_list MUST NOT contain any duplicated o N_neighbor_addr_list MUST NOT contain any duplicated addresses.
addresses.
o N_neighbor_iface_addr_list MUST NOT contain any address which is o N_neighbor_addr_list MUST NOT contain any address which is in the
in the N_neighbor_iface_addr_list of any other Neighbor Tuple. N_neighbor_addr_list of any other Neighbor Tuple.
o If N_symmetric is = true, then there MUST be one or more Link o If N_symmetric is = true, then there MUST be one or more Link
Tuples with: Tuples with:
* L_neighbor_iface_addr_list contained in * L_neighbor_iface_addr_list contained in N_neighbor_addr_list;
N_neighbor_iface_addr_list; AND AND
* L_status = SYMMETRIC. * L_status = SYMMETRIC.
o If N_symmetric is = false, then there MUST be one or more Link o If N_symmetric is = false, then there MUST be one or more Link
Tuples with: Tuples with:
* L_neighbor_iface_addr_list contained in * L_neighbor_iface_addr_list contained in N_neighbor_addr_list.
N_neighbor_iface_addr_list.
All such Link Tuples MUST NOT have L_status = SYMMETRIC. At least All such Link Tuples MUST NOT have L_status = SYMMETRIC. At least
one such Link Tuple MUST have L_HEARD_time not expired. one such Link Tuple MUST have L_HEARD_time not expired.
In each Lost Neighbor Tuple: In each Lost Neighbor Tuple:
o NL_neighbor_iface_addr MUST NOT be in the I_local_iface_addr_list o NL_neighbor_addr MUST NOT be in the I_local_iface_addr_list of any
of any Local Interface Tuple or the IR_local_iface_addr of any Local Interface Tuple or the IR_local_iface_addr of any Removed
Removed Interface Address Tuple. Interface Address Tuple.
o NL_neighbor_iface_addr MUST NOT equal the NL_neighbor_iface_addr o NL_neighbor_addr MUST NOT equal the NL_neighbor_addr of any other
of any other Lost Neighbor Tuple. Lost Neighbor Tuple.
o NL_neighbor_iface_addr MUST NOT be in the o NL_neighbor_addr MUST NOT be in the N_neighbor_addr_list of any
N_neighbor_iface_addr_list of any Neighbor Tuple with N_symmetric Neighbor Tuple with N_symmetric = true.
= true.
In each 2-Hop Tuple: In each 2-Hop Tuple:
o There MUST be a Link Tuple associated with the same MANET o There MUST be a Link Tuple associated with the same MANET
interface with: interface with:
* L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND * L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
* L_status = SYMMETRIC. * L_status = SYMMETRIC.
o N2_2hop_iface_addr MUST NOT be in the I_local_iface_addr_list of o N2_2hop_addr MUST NOT be in the I_local_iface_addr_list of any
any Local Interface Tuple or the IR_local_iface_addr of any Local Interface Tuple or the IR_local_iface_addr of any Removed
Removed Interface Address Tuple. Interface Address Tuple.
o N2_2hop_iface_addr MUST NOT be the N2_2hop_iface_addr of any other o N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple
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_iface_addr MUST NOT be in the N2_neighbor_iface_addr_list o N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the
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 originator router with a An example HELLO message, transmitted by an originating router with a
single MANET interface, is as follows. single MANET interface, is as follows.
The message has full Message Header (four bit flags field value is The message has Message Header containing hop-limit, hop-count and
15). Its four bit Message Address Length field has value 3 and hence message sequence number (four bit Flags field value is 14). Its four
addresses in the message have length four octets, here being IPv4 bit Message Address Length field has value 3 and hence addresses in
addresses. The message is as transmitted with a hop limit of 1 and a the message have length four octets, here being IPv4 addresses. The
hop count of 0. The overall message length is 49 octets. message is as transmitted with a hop limit of 1 and a hop count of 0.
The overall message length is 45 octets.
The message contains a Message TLV Block with content length 8 octets The message contains a Message TLV Block with content length 8 octets
containing two Message TLVs, of types VALIDITY_TIME and containing two Message TLVs, of types VALIDITY_TIME and
INTERVAL_TIME. Each uses a Message TLV with flags octet value 16, INTERVAL_TIME. Each uses a Message TLV with Flags octet value 16,
indicating that each has a value. Each has a value length of 1 indicating that each has a Value. Each has a Value Length of 1
octet; the values included (0x64 and 0x58) are time codes octet; the Values included (0x64 and 0x58) are time codes
representing the default values of parameters H_HOLD_TIME and representing the default values of parameters H_HOLD_TIME and
HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the
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 1 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 1 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 60, line 44 skipping to change at page 62, line 5
lower bound on the control traffic generated by each router in the lower bound on the control traffic generated by each router in the
network employing this protocol. network employing this protocol.
A router MUST ensure that two successive HELLO messages sent on the A router MUST ensure that two successive HELLO messages sent on the
same MANET interface are separated by at least HELLO_MIN_INTERVAL. same MANET interface are separated by at least HELLO_MIN_INTERVAL.
(If using jitter then this may be reduced to a mean minimum value of (If using jitter then this may be reduced to a mean minimum value of
HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound
on the control traffic generated by each router in the network on the control traffic generated by each router in the network
employing this protocol. employing this protocol.
Appendix E. Interval and Timer Illustrations
This informative appendix illustrates the relationship between
message timers and intervals. (The adjustments to this timing when
using timing jitter, as defined in [RFC5148], are not shown.)
E.1. HELLO Message Generation Timing
Figure 1 illustrates a basic HELLO message schedule for a router, on
a MANET interface, employing strictly periodic transmission of HELLO
messages. The router transmits a HELLO message each HELLO_INTERVAL.
Each HELLO message contains all neighbor addresses of the router that
are to be reported in any such HELLO message. (The parameter
REFRESH_INTERVAL, not shown, is in this example equal to the
parameter HELLO_INTERVAL.)
The router includes a VALIDITY_TIME TLV in each HELLO message,
encoding the parameter H_HOLD_TIME, the duration for which
information received in the HELLO message should be considered valid
by receiving routers. Receiving routers will, when recording the
information received in the HELLO message, each use this for setting
the L_HEARD_time, L_SYM_time and L_time elements of their
corresponding Link Tuple, and the N2_time in the corresponding 2-Hop
Tuple for each address. Only L_time is illustrated in Figure 1.
H_HOLD_TIME: |-----------------------------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
Time: ---*---------*---------*---------*------>
^ ^ ^ ^
| | | |
HELLO (a, b, c, d) | | |
| | |
HELLO (a, b, c, d) | | ...
| |
HELLO (a, b, c, d) |
|
HELLO (a, b, c, d)
L_time: |-----------------------------|
|-------------------- ...
|---------- ...
| ...
Figure 1: HELLO message generation: regular schedule
Figure 2 illustrates a message schedule similar to Figure 1, where
the router announces its own presence more frequently by sending
additional HELLO messages. HELLO messages are still sent regularly,
at a reduced interval defined by a new value of HELLO_INTERVAL.
However REFRESH_INTERVAL has not been reduced. Each neighbor address
included in these HELLO messages need be advertised only once within
each REFRESH_INTERVAL. Consequently the additional HELLO messages
due to the reduced value of HELLO_INTERVAL may therefore be empty.
(This is not the only allowed distribution of neighbor addresses,
they could, for example, be sent alternately a, b and c, d.)
H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |---------|---------|---------| ...
HELLO_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO (a, b, c, d) | | | | | |
| | | | | |
HELLO () | | | | |
| | | | |
HELLO (a, b, c, d) | | | |
| | | | ...
HELLO () | | |
| | |
HELLO (a, b, c, d) | |
| |
HELLO () |
|
HELLO (a, b, c, d)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 2: HELLO message generation: regular schedule with different
HELLO_INTERVAL and REFRESH_INTERVAL
HELLO messages may also be sent in response to events. The minimal
interval between two successive HELLO message transmissions by a
router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO
message emission rate. Hence, for each HELLO message transmission, a
router must wait at least HELLO_MIN_INTERVAL before the next HELLO
message transmission. Similarly, the maximum interval between two
successive HELLO message transmissions is HELLO_INTERVAL, setting a
lower bound on the message transmission rate. Hence, for each HELLO
message transmission, the router must ensure that the next HELLO
message transmission must not wait more than HELLO_INTERVAL.
Figure 3 illustrates a message schedule similar to Figure 1, but with
HELLO messages responding to events at maximum rate, i.e. with 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
scheduled at an interval of HELLO_INTERVAL, and hence each HELLO
message contains all neighbor addresses. In each HELLO message in
this example, a new neighbor address is added, reflecting the changes
occuring since the last HELLO message was sent. HELLO messages are
sent at the maximum allowed rate in order to signal these changes as
rapidly as possible.
H_HOLD_TIME: |-----------------------------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO () | | | | | |
| | | | | |
HELLO (a) | | | | |
| | | | |
HELLO (a, b) | | | |
| | | | ...
HELLO (a, b, c) | | |
| | |
HELLO (a, b, c, d) | |
| |
HELLO (a, b, c, d, e) |
|
HELLO (a, b, c, d, e, f)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 3: HELLO message generation: regular schedule with responsive
messages
Figure 4 shows the same example as Figure 3, but with an increased
REFRESH_INTERVAL, and showing partial HELLO messages which include
only the necessary addresses.
H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |-------------------|---------- ...
|-------------------|----- ...
|-------------------| ...
|--------------- ...
|---------- ...
|----- ...
| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO () | | | | | |
| | | | | |
HELLO (a) | | | | |
| | | | |
HELLO (b) | | | |
| | | | ...
HELLO (c) | | |
| | |
HELLO (a, d) | |
| |
HELLO (b, e) |
|
HELLO (c, f)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 4: HELLO message generation: regular schedule with responsive
messages and different HELLO_INTERVAL and REFRESH_INTERVAL
Figure 5 summarizes the overall relationship between the intervals
governing HELLO message transmissions by a router.
H_HOLD_TIME: |------------------------------------|
REFRESH_INTERVAL: |----------------|
HELLO_INTERVAL: |----------|
HELLO_MIN_INTERVAL: |---|
Time: ----------------------------------------------->
^ ^ ^ ^ ^
| | | | |
| | | | Time until which
HELLO message | | | received HELLO
transmission | | | message content
| | | is valid.
| | |
| | Time before which all
| | neighbor information must
| | be transmitted in HELLO
| | messages (one or more)
| |
| Latest time for next HELLO message
| transmission
|
Earliest time for next HELLO message
transmission
Figure 5: HELLO message generation intervals
E.2. HELLO Message Processing Timing
Figure 6 illustrates the Link Set timers when receiving a HELLO
message not including the address of the receiving MANET interface.
VALIDITY_TIME: |--------------------------|
L_time: |--------------------------|
L_HEARD_time: |--------------------------|
L_SYM_time: *-| (i.e. expired)
Time: ---*-------------------------------->
^
|
HELLO () received
Figure 6: HELLO message processing: address not present
Figure 7 illustrates the Link Set timers when, following the received
HELLO message illustrated in Figure 6, a router receives a HELLO
message including the address (a) of the receiving interface with
link status = HEARD (or SYM).
VALIDITY_TIME: |--------------------------|
|--------------------------|
L_time: |--------------------------|
|--------------------------|
L_HEARD_time: |--------------------------|
|--------------------------|
L_SYM_time: *-| (i.e. expired)
L_SYM_time: |--------------------------|
Time: -*-----*--------------------------------->
^ ^
| |
HELLO () received |
|
HELLO (a:HEARD) received
Figure 7: HELLO message processing: address present
Figure 8 illustrates the Link Set timers when, following the received
HELLO messages illustrated in Figure 7, a router receives a HELLO
message including the address (a) of the receiving interface with
link status = LOST.
VALIDITY_TIME: |--------------------------|
|--------------------------|
|--------------------------|
L_time: |--------------------------|
|--------------------------|
|--------------------------|
L_HEARD_time: |--------------------------|
|--------------------------|
|--------------------------|
L_SYM_time: *-| (i.e. expired)
|--------------------------|
*-| (i.e. expired)
Time: -*-----*-----*--------------------------------->
^ ^ ^
| | |
HELLO () received | |
| |
HELLO (a:HEARD) received |
|
HELLO (a:LOST) received
Figure 8: HELLO message processing: address lost
E.3. Other HELLO Message Timing
There are three other timing parameters which are used by a router to
control HELLO message generation and processing.
Figure 9 illustrates the time, with duration L_HOLD_TIME, during
which the appropriate addresses of a formerly, but no longer,
symmetric 1-hop neighbor, as connected by this MANET interface, are
advertised as LOST using a LINK_STATUS TLV in HELLO messages on this
MANET interface, thus allowing that 1-hop neighbor to update its Link
Set accordingly.
L_HOLD_TIME: |----------------------------|
Time: ---*---------------------------------->
^ ^
| |
Formerly symmetric 1-hop neighbor |
ceases to be symmetric on this |
MANET interface |
|
Time until which addresses of this
neighbor connected using this MANET
interface are advertised in HELLO
messages on this MANET interface
using a LINK_STATUS TLV, Value = LOST
Figure 9: HELLO message generation: advertisement of formerly
symmetric 1-hop neighbor on this MANET interface as lost
Figure 10 illustrates the time, with duration N_HOLD_TIME, during
which all addresses of a formerly, but no longer, symmetric 1-hop
neighbor, are advertised as LOST in HELLO messages on all MANET
interfaces using an OTHER_NEIGHB TLV (if not also reported using a
LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to
update their 2-Hop Sets accordingly.
L_HOLD_TIME: |----------------------------|
Time: ---*---------------------------------->
^ ^
| |
Formerly symmetric 1-hop neighbor |
ceases to be symmetric |
|
Time until which addresses of this
neighbor are advertised in HELLO
messages on all MANET interfaces
using an OTHER_NEIGHB TLV,
Value = LOST
Figure 10: HELLO message generation: advertisement of formerly
symmetric 1-hop neighbor on any MANET interface as lost
Figure 11 illustrates the time, with duration I_HOLD_TIME, during
which a formerly, but no longer, used local interface address is
excluded from being considered as a 2-hop neighbor address (in order
that a router is not recorded as its own 2-hop neighbor during that
period).
I_HOLD_TIME: |----------------------------|
Time: ---*----------------------------------->
^ ^
| |
Formerly used local interface |
address ceases to be assigned |
to a local interface |
|
Time until which this address
is excluded from being included
in this router's 2-Hop Set
Figure 11: Local interface removed address
Appendix F. Topology Pictures
This appendix illustrates various examples of physical topologies, as
well as how these are logically recorded by NHDP from the point of
view of the router A. This representation is a composite of
information which would be contained within A's various Information
Bases after NHDP has been running for sufficiently long time for the
state to converge.
Note that the examples given in this appendix are NOT exhaustive, but
are selected to be illustrative of NHDP neighborhood representations
of physical MANET topologies.
The example topologies presented contain 3 physical routers A, B and
C. Each of these routers has one or two distinct interfaces, denoted
"top" and "bottom". Each interface has one or two addresses, and
symmetric connectivity between a pair of interfaces is illustrated by
these being connected by a line.
In all examples, the topology is described as it is recorded by NHDP
in router A.
F.1. Example 1: Standard Single Interface Topology
In Figure 12, each router has a single interface, each with a single
IP address. This is the simplest possible network, and the resulting
representation is given to the right in Figure 12.
__________ __________
| | |
{1} {2} {3}
| | | {1}--------{2}--------{3}
+--'--+ +--'--+ +--'--+
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 12: Standard single interface topology (left), and
corresponding NHDP representation (right)
The Local Information Set in A contains a single Local Interface
Tuple which has an I_local_iface_addr_list of {1}. This value is
denoted with a {1} on the leftmost part of the resulting
representation.
The Interface Information Base has only one Link Set, which
represents the "top" interface of A, or {1}. This Link Set's only
Link Tuple has an L_neighbor_iface_addr_list containing {2}; this
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
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
Figure 12.
The descriptions of the following examples in this appendix will be
derived similarly, and use the same notational conventions.
F.2. Example 2: Dual Addressed Interface on One Hop Neighbor
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
interface.
__________ __________
| | |
{1} {2,4} {3}
| | | {1}-------{2,4}-------{3}
+--'--+ +--'--+ +--'--+
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 13: Single interfaces, with 1-hop neighbor B having two
addresses (left), and corresponding NHDP representation (right)
The content of the Interface Information Base is in this case
identical to Example 1, except that L_neighbor_iface_addr_list is
{2,4} and N2_neighbor_iface_addr_list is {2,4}.
F.3. Example 3: Dual Addressed Interface on Two Hop Neighbor
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.
__________ __________
| | |
{1} {2} {3,4} _.---{3}
| | | {1}--------{2}--<_
+--'--+ +--'--+ +--'--+ '---{4}
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 14: Single interfaces, with 2-hop neighbor C having two
addresses (left), and corresponding NHDP representation (right)
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
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
two lines from {2} to {3} and (2) to {4}, respectively.
F.4. Example 4: Dual Addressed Interfaces
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
Information Base in router A is the same as in Example 1, except that
I_local_iface_addr_list is {1,5}.
__________ __________
| | |
{1,5} {2,6} {3,4} _.---{3}
| | | {1,5}------{2,6}-<_
+--'--+ +--'--+ +--'--+ '---{4}
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 15: Single interfaces, all routers having two addresses
(left), and corresponding NHDP representation (right)
The content of the Interface Information Base is in this case a
combination of the Interface Information Bases from Example 1,
Example 2 and Example 3.
F.5. Example 5: Dual Interface on Two Hop Neighbor
In Figure 16, all routers have a single IP address on each interface,
and with the 2-hop neighbor having two interfaces.
__________ __________
| | |
{1} {2} {3} _.---{3}
| | | {1}--------{2}--<_
+--'--+ +--'--+ +-----+ '---{4}
| A | | B | | C |
+-----+ +-----+ +-----+
|
{4}
Figure 16: Single addresses, with 2-hop neighbor C having two
interfaces (left), and corresponding NHDP representation (right)
The Interface Information Base is identical to that in Example 3;
NHDP does not distinguish topologically between this example and
Example 3.
F.6. Example 6: Dual interface on One Hop Neighbor
In Figure 17, all routers have a single IP address on each interface,
and with the 1-hop neighbor having two interfaces.
__________
| |
{1} {2} ,-.
| | {1}-------/{2}\-------{4}
+--'--+ +--'--+ +-----+ \{5}/
| A | | B | | C | `-'
+-----+ +-----+ +-----+
| |
{5} {4}
|__________|
Figure 17: Single addresses, with 1-hop neighbor B having two
interfaces (left), and corresponding NHDP representation (right)
The Local Information Base is identical to that in Example 1.
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
contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being
{2} and N2_hop_addr being {4}.
The Neighbor Information Base contains a Neighbor Set containing a
single Neighbor Tuple, which represents router B, with
N_neighbor_addr_list being {2,5}. This entry is represented on the
right of Figure 17 by circling {2} with {5}.
Note that router A does not have information indicating which of
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
{2} as next hop.
F.7. Example 7: Dual Interface on One and Two Hop Neighbors
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.
Furthermore, there are now two physical links between routers B and
C, over distinct interface pairs.
__________ __________
| | |
{1} {2} {3} ,-. _.---{3}
| | | {1}-------/{2}\--<_
+--'--+ +--'--+ +-----+ \{5}/ '---{4}
| A | | B | | C | `-'
+-----+ +-----+ +-----+
| |
{5} {4}
|__________|
Figure 18: Single addresses, with 1-hop and 2-hop neighbors B and C
having two interfaces (left), and corresponding NHDP representation
(right)
The Local Information Base is identical to that in Example 1.
The Link Set is identical to that in Example 6, and the 2-Hop Set
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
Note that router A does not have information describing which of
router B's interfaces is connected to which interfaces of router C,
or even that the interfaces with addresses {3} and {4} are interfaces
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.
F.8. Example 8: Dual Interface Locally and on One Hop Neighbor
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.
Furthermore, there are now two physical links between routers A and
B, over distinct interface pairs.
__________ __________
| | | ,-.
{1} {2} {3} {1}-------/{2}\--------{3}
| | | \{5}/
+--'--+ +--'--+ +-----+ `-'
| A | | B | | C |
+-----+ +-----+ +-----+ ,-.
| | /{2}\
{6} {5} {6}-------\{5}/--------{3}
|__________| `-'
Figure 19: Single addresses, with both A and 1-hop neighbor B having
two interfaces (left), and corresponding NHDP representation (right)
The Local Information Set contains two Local Interface Tuples, with
I_local_iface_addr_list of {1} and {6}, respectively.
Each Interface Information Base's Link Set contains one Link Tuple,
representing the links between {1} and {2}, and between {6} and {5},
respectively. The 2-Hop Set for interface {1} contains a single
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
single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and
N2_hop_addr being {3}.
The Neighbor Information Base contains a Neighbor Set containing a
single Neighbor Tuple, which represents router B, with
N_neighbor_addr_list being {2,5}. This entry is denoted by circling
{2} with {5}.
F.9. Example 9: Dual Interface on All Routers
In Figure 20, all routers have a single IP address on each interface,
and all routers have two interfaces. Furthermore, there are now two
physical links between A and B, over distinct interface pairs, and
two physical links between B and C, also over distinct interface
pairs.
__________ __________
| | | ,-. _.---{3}
{1} {2} {3} {1}-------/{2}\--<_
| | | \{5}/ '---{4}
+--'--+ +--'--+ +-----+ `-'
| A | | B | | C |
+-----+ +-----+ +-----+ ,-.
| | | /{2}\ _.---{3}
{6} {5} {4} {6}-------\{5}/--<_
|__________|__________| `-' '---{4}
Figure 20: Single addresses, with all routers having two interfaces
(left), and corresponding NHDP representation (right)
The Local Information Set is identical to that in Example 8. The
Interface Information Base for each interface in A is also identical
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
B and the interface of router C with address {4}.
As in Example 7, router A does not have information describing which
of router B's interfaces is connected to which interface of C, or
even that the interfaces with addresses {3} and {4} are interfaces of
the same router. However, router A knows that the addresses {3} and
{4} (and router C) are reachable by using {2} or {5} (depending on
via which of its local interfaces) as next hop.
F.10. Example 10: Dual Addressed Dual Interfaces on All Routers
In Figure 21, all routers have two IP addresses on each interface,
and all routers have two interfaces. Furthermore, there are now two
physical links between A and B, over distinct interface pairs, and
two physical links between B and C, also over distinct interface
pairs.
__________ __________ _ _.--{9}
| | | ,' `. _.-<__-{10}
{1,2} {5,6} {9,10} {1,2}--|{5,6}|-<_ __
| | | |{7,8}| '-<_ -{11}
+--'--+ +--'--+ +-----+ `._,' '-{12}
| A | | B | | C | _
+-----+ +-----+ +-----+ ,' `. _.--{9}
| | | |{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
(left) and corresponding NHDP representation (right)
This example is the combination of all the preceding examples in this
appendix. The Local Information Set in A contains Local 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}
or {3,4}-{7,8}, respectively. The Neighbor Set (in the Neighbor
Information Base) records the existence of router B and all of its
addresses on all its interfaces, i.e. {5,6,7,8}.
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
router B to each of these addresses. Router A does not have
information describing which of router B's interfaces is connected to
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
{9} and {10}, are addresses on the same interface of the router).
F.11. Example 11: Single Addressed Dual Interface Locally
In Figure 22, all routers have a single interface, except for router
A which has two. Each of A's two interfaces has a link with the
single interface of router B. All interfaces have a single address.
__________ __________
| _____| |
{1} | {2} {3} {1}--------{2}---------{3}
| | | |
+--'--+ | +--'--+ +-----+
| A | | | B | | C |
+-----+ | +-----+ +-----+
| |
{6} | {6}--------{2}---------{3}
|____|
Figure 22: Single addresses, with A having two interfaces, both
linked to the single interface of B (left), and corresponding NHDP
representation (right)
This is similar to Example 8, except that the single address {2} also
replaces the address {5}. In particular both Link Tuples (one in
each Link Set, each in its corresponding Interface Information Base)
have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the
Neighbor Information Base) contains a single Neighbor Tuple with
N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each
2-Hop Set, each in its corresponding Interface Information Base) have
N2_neighbor_iface_list being {2} and N2_2hop_addr being {3}.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
Christopher Dearlove Christopher Dearlove
BAE Systems ATC BAE Systems ATC
Phone: +44 1245 242194 Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Justin W. Dean Justin W. Dean
Naval Research Laboratory Naval Research Laboratory
Phone: +1 202 767 3397 Phone: +1 202 767 3397
EMail: jdean@itd.nrl.navy.mil EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/ URI: http://pf.itd.nrl.navy.mil/
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
 End of changes. 135 change blocks. 
224 lines changed or deleted 1020 lines changed or added

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