draft-ietf-manet-nhdp-14.txt   draft-ietf-manet-nhdp-15.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: January 13, 2011 BAE Systems ATC Expires: June 22, 2011 BAE Systems ATC
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
July 12, 2010 December 19, 2010
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-14 draft-ietf-manet-nhdp-15
Abstract Abstract
This document describes a 1-hop and symmetric 2-hop neighborhood This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs). discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on June 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11 4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 11
4.2. Information Base Overview . . . . . . . . . . . . . . . . 12 4.2. Information Base Overview . . . . . . . . . . . . . . . . 12
4.2.1. Local Information Base . . . . . . . . . . . . . . . . 12 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 13
4.2.2. Interface Information Bases . . . . . . . . . . . . . 13 4.2.2. Interface Information Bases . . . . . . . . . . . . . 13
4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 14 4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 14
4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 14
4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 15 4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 15
4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 15 4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 16
4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 17 4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 17
4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 18 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 18
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 18 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 18
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 18 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 18
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 18 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . . 18
5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 19 5.3.1. Message Intervals . . . . . . . . . . . . . . . . . . 19
5.3.2. Information Validity Times . . . . . . . . . . . . . . 21 5.3.2. Information Validity Times . . . . . . . . . . . . . . 21
5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 21 5.3.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 21
5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 3, line 16 skipping to change at page 3, line 16
8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 28 8. Neighbor Information Base . . . . . . . . . . . . . . . . . . 28
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 28 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 28
9. Local Information Base Changes . . . . . . . . . . . . . . . . 29 9. Local Information Base Changes . . . . . . . . . . . . . . . . 29
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 29 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 29
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 29 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 29
9.3. Adding a Network Address to an Interface . . . . . . . . . 30 9.3. Adding a Network Address to an Interface . . . . . . . . . 30
9.4. Removing a Network Address from an Interface . . . . . . . 31 9.4. Removing a Network Address from an Interface . . . . . . . 31
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 32 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 32
10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 32 10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 33
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 34 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 34
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 34 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 35
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 37 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 37
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 37 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 37
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 37 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 38
12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 38 12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 38
12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 39 12.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 40 12.3. Updating the Neighbor Set . . . . . . . . . . . . . . . . 41
12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 41 12.4. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 42
12.5. Updating the Link Set . . . . . . . . . . . . . . . . . . 42 12.5. Updating the Link Sets . . . . . . . . . . . . . . . . . . 42
12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 43 12.6. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 44
13. Other Information Base Changes . . . . . . . . . . . . . . . . 45 13. Other Information Base Changes . . . . . . . . . . . . . . . . 45
13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 46 13.1. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 46
13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 46 13.2. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 46
13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 47 13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 47
14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 47 14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. Deployment Without Link Quality . . . . . . . . . . . . . 48 14.1. Deployment Without Link Quality . . . . . . . . . . . . . 48
14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 48 14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 48
14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 49 14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 49
14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 50 14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 50
15. Proposed Values for Parameters and Constants . . . . . . . . . 50 15. Proposed Values for Parameters and Constants . . . . . . . . . 51
15.1. Message Interval Interface Parameters . . . . . . . . . . 50 15.1. Message Interval Interface Parameters . . . . . . . . . . 51
15.2. Information Validity Time Interface Parameters . . . . . . 51 15.2. Information Validity Time Interface Parameters . . . . . . 51
15.3. Information Validity Time Router Parameters . . . . . . . 51 15.3. Information Validity Time Router Parameters . . . . . . . 51
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 51 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 51
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 51 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 51
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 51 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 52
16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 51 16. Usage with Other Protocols . . . . . . . . . . . . . . . . . . 52
17. Security Considerations . . . . . . . . . . . . . . . . . . . 54 17. Security Considerations . . . . . . . . . . . . . . . . . . . 54
17.1. Invalid HELLO Messages . . . . . . . . . . . . . . . . . . 55 17.1. Invalid HELLO Messages . . . . . . . . . . . . . . . . . . 55
17.2. Authentication, Integrity and Confidentiality 17.2. Authentication, Integrity and Confidentiality
Suggestions . . . . . . . . . . . . . . . . . . . . . . . 56 Suggestions . . . . . . . . . . . . . . . . . . . . . . . 56
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 57 18.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 57
18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 57 18.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 57
18.3. Message-Type-Specific TLV Type Registries . . . . . . . . 57 18.3. Message-Type-Specific TLV Type Registries . . . . . . . . 57
18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 58 18.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 58
18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 59 18.5. LOCAL_IF, LINK_STATUS and OTHER_NEIGHB Values . . . . . . 60
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 60 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 61
20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
21.1. Normative References . . . . . . . . . . . . . . . . . . . 61 21.1. Normative References . . . . . . . . . . . . . . . . . . . 61
21.2. Informative References . . . . . . . . . . . . . . . . . . 61 21.2. Informative References . . . . . . . . . . . . . . . . . . 62
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 61 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 62
Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 62 Appendix B. Constraints . . . . . . . . . . . . . . . . . . . . . 63
Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 65 Appendix C. HELLO Message Example . . . . . . . . . . . . . . . . 66
Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 67 Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 68
Appendix E. Interval and Timer Illustrations . . . . . . . . . . 68 Appendix E. Interval and Timer Illustrations . . . . . . . . . . 69
E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 68 E.1. HELLO Message Generation Timing . . . . . . . . . . . . . 69
E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 74 E.2. HELLO Message Processing Timing . . . . . . . . . . . . . 75
E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 75 E.3. Other HELLO Message Timing . . . . . . . . . . . . . . . . 76
Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 77 Appendix F. Topology Pictures . . . . . . . . . . . . . . . . . . 78
F.1. Example 1: Standard Single Interface Topology . . . . . . 77 F.1. Example 1: Standard Single Interface Topology . . . . . . 78
F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor . . 78 F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor . . 79
F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor . . 79 F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor . . 80
F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 79 F.4. Example 4: Dual Addressed Interfaces . . . . . . . . . . . 80
F.5. Example 5: Dual Interface on 2-Hop Neighbor . . . . . . . 80 F.5. Example 5: Dual Interface on 2-Hop Neighbor . . . . . . . 81
F.6. Example 6: Dual interface on 1-Hop Neighbor . . . . . . . 80 F.6. Example 6: Dual interface on 1-Hop Neighbor . . . . . . . 81
F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors . . 81 F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors . . 82
F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor . 82 F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor . 83
F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 82 F.9. Example 9: Dual Interface on All Routers . . . . . . . . . 83
F.10. Example 10: Dual Addressed Dual Interfaces on All F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers . . . . . . . . . . . . . . . . . . . . . . . . . 83 Routers . . . . . . . . . . . . . . . . . . . . . . . . . 84
F.11. Example 11: Single Addressed Dual Interface Locally . . . 84 F.11. Example 11: Single Addressed Dual Interface Locally . . . 85
1. Introduction 1. Introduction
This document describes a neighborhood discovery protocol (NHDP) for This document describes a neighborhood discovery protocol (NHDP) for
a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a
local exchange of HELLO messages in order that each router can local exchange of HELLO messages in order that each router can
determine the presence of, and connectivity to, its 1-hop and determine the presence of, and connectivity to, its 1-hop and
symmetric 2-hop neighbors. Messages are defined and sent in packets symmetric 2-hop neighbors. Messages are defined and sent in packets
according to the specification [RFC5444]. according to the specification [RFC5444].
skipping to change at page 7, line 19 skipping to change at page 7, line 19
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Network Address - An address plus an associated prefix length. This Network Address - An address plus an associated prefix length. This
may be an address with an associated maximum prefix length, or an may be an address with an associated maximum prefix length, or an
address prefix including a prefix length. A Network Address thus address prefix including a prefix length. A Network Address thus
represents a range of addresses. represents a range of addresses.
Router - A MANET router which implements this neighborhood discovery Router - A MANET router which implements this neighborhood discovery
protocol. protocol.
Interface - A network device, configured and assigned one or more Interface - A router's attachment to a communications medium. An
addresses. interface is assigned one or more addresses.
MANET interface - An interface participating in a MANET and using MANET interface - An interface participating in a MANET and using
this neighborhood discovery protocol. A router may have several this neighborhood discovery protocol. A router may have several
MANET interfaces. MANET interfaces.
Heard - A MANET interface of router X is considered heard on a MANET Heard - A MANET interface of router X is considered heard on a MANET
interface of a router Y if the latter can receive control interface of a router Y if the latter can receive control
messages, according to this specification, from the former. messages, according to this specification, from the former.
Link - A link between two MANET interfaces exists if either can be Link - A link between two MANET interfaces exists if either can be
skipping to change at page 11, line 29 skipping to change at page 11, line 29
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. least one, and possibly more, MANET interfaces.
Each MANET interface: Each MANET interface:
o Is configured with one or more network addresses. All addresses o Is configured with one or more network addresses. Each address in
represented by these network addresses MUST be unique to this the range of addresses represented by that network address MUST
router. All such addresses MUST be unique to this MANET satisfy the following properties:
interface, except that an address can be used by more than one
MANET interface on the same router if those MANET interfaces are o It MUST be unique to this router, i.e., it MUST NOT be assigned
"isolated" from each other (no MANET interface on another router to any interface of any other router.
can communicate to, from, or one to and one from, two MANET
interfaces using overlapping network addresses). o If assigned to other MANET interfaces, on the same router,
these MANET interfaces MUST be isolated, i.e., addresses may
only be assigned to different interfaces on the same router if
no MANET interface on another router can communicate with both.
For example interfaces using distinct radio "channels" MAY be
assigned the same address.
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 12, line 19 skipping to change at page 12, line 24
o A Neighbor Information Base, recording information regarding o A Neighbor Information Base, recording information regarding
current and recently lost 1-hop neighbors of this router. current and recently lost 1-hop neighbors of this router.
A router may have both MANET interfaces and non-MANET interfaces. A router may have both MANET interfaces and non-MANET interfaces.
Interfaces of both of these types are recorded in a router's Local Interfaces of both of these types are recorded in a router's Local
Information Base, which is used, but not updated, by the signaling of Information Base, which is used, but not updated, by the signaling of
this protocol. this protocol.
4.2. Information Base Overview 4.2. Information Base Overview
Each router maintains the Information Bases described in the Each router maintains protocol state using Information Bases,
following sections. These are used for describing the protocol in described in the following sections. Each Information Base consists
this document. An implementation of this protocol MAY maintain this of a number of Protocol Sets. Each Protocol Set contains a number of
information in the indicated form, or in any other organization which Protocol Tuples.
offers access to this information. In particular, note that it is
not necessary to remove Tuples from Sets at the exact time indicated, An implementation of this protocol MAY maintain this information in
only to behave as if the Tuples were removed at that time. the indicated form, or in any other organization which offers access
to this information. In particular, note that it is not necessary to
remove Protocol Tuples from Protocol Sets at the exact time
indicated, only to behave as if the Protocol Tuples were removed at
that time.
Information in the Local Information Base is defined locally, and Information in the Local Information Base is defined locally, and
included in HELLO messages. Information in the Interface Information included in HELLO messages. Information in the Interface Information
Base and the Neighbor Information Base is determined from received Base and the Neighbor Information Base is determined from received
HELLO messages; some of this information may also be included in HELLO messages; some of this information may also be included in
transmitted HELLO messages. Such information has a limited duration transmitted HELLO messages. Such information has a limited duration
in which it is considered valid. This duration is determined from in which it is considered valid. This duration is determined from
the VALIDITY_TIME TLV in the HELLO message in which the information the VALIDITY_TIME TLV in the HELLO message in which the information
is received, which in turn is set by the router that originated the is received, which in turn is set by the router that originated the
HELLO message, using its corresponding interface parameter HELLO message, using its corresponding interface parameter
skipping to change at page 32, line 32 skipping to change at page 32, line 40
10.1. HELLO Messages 10.1. HELLO Messages
A HELLO message MUST contain: A HELLO message MUST contain:
o Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497], o Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497],
representing H_HOLD_TIME for the transmitting MANET interface. representing H_HOLD_TIME for the transmitting MANET interface.
The options included in [RFC5497] for representing zero and The options included in [RFC5497] for representing zero and
infinite times MUST NOT be used. infinite times MUST NOT be used.
A HELLO message which is transmitted periodically SHOULD contain, and A HELLO message transmitted due to a periodic timer SHOULD contain,
otherwise MAY contain: and otherwise (i.e., transmitted for any other reason, in particular
in response to any Information Base changes) MAY contain:
o Exactly one INTERVAL_TIME Message TLV as specified in [RFC5497], o Exactly one INTERVAL_TIME Message TLV as specified in [RFC5497],
representing HELLO_INTERVAL for the transmitting MANET interface. representing HELLO_INTERVAL for the transmitting MANET interface.
The options included in [RFC5497] for representing zero and The options included in [RFC5497] for representing zero and
infinite times MUST NOT be used. infinite times MUST NOT be used.
A HELLO message MAY contain: A HELLO message MAY contain:
o Other Message TLVs. o Other Message TLVs.
skipping to change at page 40, line 12 skipping to change at page 40, line 30
corresponding to the MANET interface on which the HELLO message corresponding to the MANET interface on which the HELLO message
was received was received
o "Sending Address List" is an unordered list of network addresses o "Sending Address List" is an unordered list of network addresses
of the MANET interface over which the HELLO message was sent, of the MANET interface over which the HELLO message was sent,
i.e., is an unordered list of the network addresses represented by i.e., is an unordered list of the network addresses represented by
address objects contained in the HELLO message with an associated address objects contained in the HELLO message with an associated
Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If
the Sending Address List is otherwise empty, then the Sending the Sending Address List is otherwise empty, then the Sending
Address List contains a single network address with maximum prefix Address List contains a single network address with maximum prefix
length (i.e., /32 for IPv64, /128 for IPv6) with address equal to length (i.e., /32 for IPv4, /128 for IPv6) with address equal to
the sending address of the IP datagram in which the HELLO message the sending address of the IP datagram in which the HELLO message
was included. was included.
o "Neighbor Address List" is an unordered list of all the network o "Neighbor Address List" is an unordered list of all the network
addresses of all the interfaces of the router which generated the addresses of all the interfaces of the router which generated the
HELLO message, i.e., is the Sending Address List, plus the network HELLO message, i.e., is the Sending Address List, plus the network
addresses represented by address objects contained in the HELLO addresses represented by address objects contained in the HELLO
message with an associated Address Block TLV with Type = LOCAL_IF message with an associated Address Block TLV with Type = LOCAL_IF
and Value = OTHER_IF. and Value = OTHER_IF.
skipping to change at page 42, line 9 skipping to change at page 42, line 26
1. For each network address (henceforth lost address) which is 1. For each network address (henceforth lost address) which is
contained in the Lost Address List, if no Lost Neighbor Tuple contained in the Lost Address List, if no Lost Neighbor Tuple
with NL_neighbor_addr = lost address exists, then add a Lost with NL_neighbor_addr = lost address exists, then add a Lost
Neighbor Tuple with: Neighbor Tuple with:
o NL_neighbor_addr := lost address; o NL_neighbor_addr := lost address;
o NL_time := current time + N_HOLD_TIME. o NL_time := current time + N_HOLD_TIME.
12.5. Updating the Link Set 12.5. Updating the Link Sets
On receiving a HELLO message, a router MUST update its Link Set for On receiving a HELLO message, a router MUST update its Link Sets:
the MANET interface on which the HELLO message is received:
1. Remove all network addresses in the Removed Address List from the 1. Remove all network addresses in the Removed Address List from the
L_neighbor_iface_addr_list of all Link Tuples. L_neighbor_iface_addr_list of all Link Tuples.
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now 2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now
empty; apply Section 13.2, but not Section 13.3. empty; apply Section 13.2, but not Section 13.3.
3. Find all Link Tuples (henceforth matching Link Tuples) where: The router MUST then update its Link Set for the MANET interface on
which the HELLO message is received:
1. Find all Link Tuples (henceforth matching Link Tuples) where:
o L_neighbor_iface_addr_list contains one or more network o L_neighbor_iface_addr_list contains one or more network
addresses in the Sending Address List. addresses in the Sending Address List.
4. If there is more than one matching Link Tuple, then remove them 2. If there is more than one matching Link Tuple, then remove them
all; apply Section 13.2, but not Section 13.3. all; apply Section 13.2, but not Section 13.3.
5. If no matching Link Tuples remain, then create a new matching 3. If no matching Link Tuples remain, then create a new matching
Link Tuple with: Link Tuple with:
o L_neighbor_iface_addr_list := empty; o L_neighbor_iface_addr_list := empty;
o L_HEARD_time := EXPIRED; o L_HEARD_time := EXPIRED;
o L_SYM_time := EXPIRED; o L_SYM_time := EXPIRED;
o L_quality := INITIAL_QUALITY; o L_quality := INITIAL_QUALITY;
o L_pending := INITIAL_PENDING; o L_pending := INITIAL_PENDING;
o L_lost := false; o L_lost := false;
skipping to change at page 42, line 45 skipping to change at page 43, line 16
o L_SYM_time := EXPIRED; o L_SYM_time := EXPIRED;
o L_quality := INITIAL_QUALITY; o L_quality := INITIAL_QUALITY;
o L_pending := INITIAL_PENDING; o L_pending := INITIAL_PENDING;
o L_lost := false; o L_lost := false;
o L_time := current time + validity time. o L_time := current time + validity time.
6. The matching Link Tuple, existing or new, is then modified as 4. The matching Link Tuple, existing or new, is then modified as
follows: follows:
1. If the router finds any network address (henceforth receiving 1. If the router finds any network address (henceforth receiving
address) in the Receiving Address List in an Address Block in address) in the Receiving Address List in an Address Block in
the HELLO message, then the Link Tuple is modified as the HELLO message, then the Link Tuple is modified as
follows: follows:
1. If any receiving address in the HELLO message is 1. If any receiving address in the HELLO message is
associated with an Address Block TLV with Type = associated with an Address Block TLV with Type =
LINK_STATUS and with Value = HEARD or Value = SYMMETRIC LINK_STATUS and with Value = HEARD or Value = SYMMETRIC
skipping to change at page 57, line 11 skipping to change at page 57, line 21
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.
18. IANA Considerations 18. IANA Considerations
This specification defines one Message Type, which must be allocated This specification defines one Message Type, which must be allocated
from the "Message Types" repository of [RFC5444], and three Address from the "Message Types" registry of [RFC5444], and three Address
Block TLV Types, which must be allocated from the "Address Block TLV Block TLV Types, which must be allocated from the "Address Block TLV
Types" repository of [RFC5444]. Types" registry of [RFC5444].
18.1. Expert Review: Evaluation Guidelines 18.1. Expert Review: Evaluation Guidelines
For the registries where an Expert Review is required, the designated For the registries where an Expert Review is required, the designated
expert SHOULD take the same general recommendations into expert SHOULD take the same general recommendations into
consideration as are specified by [RFC5444]. consideration as are specified by [RFC5444].
18.2. Message Types 18.2. Message Types
This specification defines one Message Type, to be allocated from the This specification defines one Message Type, to be allocated from the
skipping to change at page 78, line 26 skipping to change at page 79, line 26
The Local Information Set in A contains a single Local Interface 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 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 denoted with a {1} on the leftmost part of the resulting
representation. representation.
The Interface Information Base has only one Link Set, which The Interface Information Base has only one Link Set, which
represents the "top" interface of A, or {1}. This Link Set's only 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 Link Tuple has an L_neighbor_iface_addr_list containing {2}; this
corresponds to the dashed line from {1} to {2} to the right in corresponds to the dashed line from {1} to {2} to the right in
Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with
N2_neighbor_iface_addr_list being {2} and N2_hop_addr being {3}; this N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3};
corresponds to the dashed line from {2} to {3} to the right in this corresponds to the dashed line from {2} to {3} to the right in
Figure 12. Figure 12.
The descriptions of the following examples in this appendix will be The descriptions of the following examples in this appendix will be
derived similarly, and use the same notational conventions. derived similarly, and use the same notational conventions.
F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor
In Figure 13, the network is identical to that in Example 1, except In Figure 13, the network is identical to that in Example 1, except
that the middle router, B, has two IP addresses on its single that the middle router, B, has two IP addresses on its single
interface. interface.
skipping to change at page 79, line 25 skipping to change at page 80, line 25
+--'--+ +--'--+ +--'--+ +----{4} +--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C | | A | | B | | C |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 14: Single interfaces, with 2-hop neighbor C having two Figure 14: Single interfaces, with 2-hop neighbor C having two
addresses (left), and corresponding NHDP representation (right) addresses (left), and corresponding NHDP representation (right)
The content of the Interface Information Base is in this case The content of the Interface Information Base is in this case
identical to than in Example 1, except that the 2-Hop Set contains an identical to than in Example 1, except that the 2-Hop Set contains an
extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
N2_hop_addr being {4}. These two 2-Hop Tuples are illustrated by the N2_2hop_addr being {4}. These two 2-Hop Tuples are illustrated by
two lines from {2} to {3} and (2) to {4}, respectively. the two lines from {2} to {3} and (2) to {4}, respectively.
F.4. Example 4: Dual Addressed Interfaces F.4. Example 4: Dual Addressed Interfaces
In Figure 15, the network is identical to that in Example 1, except In Figure 15, the network is identical to that in Example 1, except
that all routers have two IP addresses on their interface. The Local that all routers have two IP addresses on their interface. The Local
Information Base in router A is the same as in Example 1, except that Information Base in router A is the same as in Example 1, except that
I_local_iface_addr_list is {1,5}. I_local_iface_addr_list is {1,5}.
__________ __________ __________ __________
| | | | | |
skipping to change at page 81, line 5 skipping to change at page 82, line 5
|__________| |__________|
Figure 17: Single addresses, with 1-hop neighbor B having two Figure 17: Single addresses, with 1-hop neighbor B having two
interfaces (left), and corresponding NHDP representation (right) interfaces (left), and corresponding NHDP representation (right)
The Local Information Base is identical to that in Example 1. The Local Information Base is identical to that in Example 1.
The Interface Information Base has only one Link Set containing one The Interface Information Base has only one Link Set containing one
Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set
contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being
{2} and N2_hop_addr being {4}. {2} and N2_2hop_addr being {4}.
The Neighbor Information Base contains a Neighbor Set containing a The Neighbor Information Base contains a Neighbor Set containing a
single Neighbor Tuple, which represents router B, with single Neighbor Tuple, which represents router B, with
N_neighbor_addr_list being {2,5}. This entry is represented on the N_neighbor_addr_list being {2,5}. This entry is represented on the
right of Figure 17 by boxing {2} with {5}. right of Figure 17 by boxing {2} with {5}.
Note that router A does not have information indicating which of Note that router A does not have information indicating which of
router B's interfaces is connected to router C. However, router A router B's interfaces is connected to router C. However, router A
knows that the address {4} (and thus router C) is reachable by using knows that the address {4} (and thus router C) is reachable by using
{2} as next hop. {2} as next hop.
skipping to change at page 82, line 33 skipping to change at page 83, line 33
Figure 19: Single addresses, with both A and 1-hop neighbor B having Figure 19: Single addresses, with both A and 1-hop neighbor B having
two interfaces (left), and corresponding NHDP representation (right) two interfaces (left), and corresponding NHDP representation (right)
The Local Information Set contains two Local Interface Tuples, with The Local Information Set contains two Local Interface Tuples, with
I_local_iface_addr_list of {1} and {6}, respectively. I_local_iface_addr_list of {1} and {6}, respectively.
Each Interface Information Base's Link Set contains one Link Tuple, Each Interface Information Base's Link Set contains one Link Tuple,
representing the links between {1} and {2}, and between {6} and {5}, representing the links between {1} and {2}, and between {6} and {5},
respectively. The 2-Hop Set for interface {1} contains a single respectively. The 2-Hop Set for interface {1} contains a single
2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and
N2_hop_addr being {3}. The 2-Hop Set for interface {6} contains a N2_2hop_addr being {3}. The 2-Hop Set for interface {6} contains a
single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and
N2_hop_addr being {3}. N2_2hop_addr being {3}.
The Neighbor Information Base contains a Neighbor Set containing a The Neighbor Information Base contains a Neighbor Set containing a
single Neighbor Tuple, which represents router B, with single Neighbor Tuple, which represents router B, with
N_neighbor_addr_list being {2,5}. This entry is denoted by boxing N_neighbor_addr_list being {2,5}. This entry is denoted by boxing
{2} with {5}. {2} with {5}.
F.9. Example 9: Dual Interface on All Routers F.9. Example 9: Dual Interface on All Routers
In Figure 20, all routers have a single IP address on each interface, In Figure 20, all routers have a single IP address on each interface,
and all routers have two interfaces. Furthermore, there are now two and all routers have two interfaces. Furthermore, there are now two
skipping to change at page 85, line 27 skipping to change at page 86, line 27
linked to the single interface of B (left), and corresponding NHDP linked to the single interface of B (left), and corresponding NHDP
representation (right) representation (right)
This is similar to Example 8, except that the single address {2} also This is similar to Example 8, except that the single address {2} also
replaces the address {5}. In particular both Link Tuples (one in replaces the address {5}. In particular both Link Tuples (one in
each Link Set, each in its corresponding Interface Information Base) each Link Set, each in its corresponding Interface Information Base)
have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the
Neighbor Information Base) contains a single Neighbor Tuple with Neighbor Information Base) contains a single Neighbor Tuple with
N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each 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 2-Hop Set, each in its corresponding Interface Information Base) have
N2_neighbor_iface_list being {2} and N2_2hop_addr being {3}. N2_neighbor_iface_addr_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/
 End of changes. 36 change blocks. 
81 lines changed or deleted 92 lines changed or added

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