draft-ietf-manet-nhdp-03.txt   draft-ietf-manet-nhdp-04.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: December 1, 2007 BAE Systems Advanced Technology Expires: December 31, 2007 BAE Systems Advanced Technology
Centre Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
May 30, 2007 June 29, 2007
MANET Neighborhood Discovery Protocol (NHDP) MANET Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-03 draft-ietf-manet-nhdp-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 December 1, 2007. This Internet-Draft will expire on December 31, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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).
skipping to change at page 2, line 46 skipping to change at page 2, line 46
8. Node Information Base . . . . . . . . . . . . . . . . . . . . 20 8. Node Information Base . . . . . . . . . . . . . . . . . . . . 20
8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 20 8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 20
9. Local Information Base Changes . . . . . . . . . . . . . . . . 21 9. Local Information Base Changes . . . . . . . . . . . . . . . . 21
9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 21 9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 21
9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 21 9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 21
9.3. Adding an Address to an Interface . . . . . . . . . . . . 22 9.3. Adding an Address to an Interface . . . . . . . . . . . . 22
9.4. Removing an Address from an Interface . . . . . . . . . . 22 9.4. Removing an Address from an Interface . . . . . . . . . . 22
10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 23 10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 23
10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 23 10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 23
10.1.1. Local Interface Block . . . . . . . . . . . . . . . . 23 10.1.1. Local Interface Block . . . . . . . . . . . . . . . . 24
10.1.2. Neighbor Address Blocks . . . . . . . . . . . . . . . 24 10.1.2. Neighbor Address Blocks . . . . . . . . . . . . . . . 24
11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 26 11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 26
11.1. HELLO Message Specification . . . . . . . . . . . . . . . 26 11.1. HELLO Message Specification . . . . . . . . . . . . . . . 26
11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 27 11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 27
11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 27 11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 27
12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 29 12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 29
12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 29 12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 29
12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 31 12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 31
12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 31 12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 31
12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 32 12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 32
skipping to change at page 3, line 28 skipping to change at page 3, line 28
15. Proposed Values for Parameters and Constants . . . . . . . . . 40 15. Proposed Values for Parameters and Constants . . . . . . . . . 40
15.1. Message Interval Interface Parameters . . . . . . . . . . 40 15.1. Message Interval Interface Parameters . . . . . . . . . . 40
15.2. Information Validity Time Interface Parameters . . . . . . 40 15.2. Information Validity Time Interface Parameters . . . . . . 40
15.3. Information Validity Time Node Parameters . . . . . . . . 40 15.3. Information Validity Time Node Parameters . . . . . . . . 40
15.4. Link Quality Interface Parameters . . . . . . . . . . . . 40 15.4. Link Quality Interface Parameters . . . . . . . . . . . . 40
15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 40 15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 40
15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 40 15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 40
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
16.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 41 16.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 41
16.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 41 16.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 41
16.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 41 16.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 42
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
17.1. Normative References . . . . . . . . . . . . . . . . . . . 43 17.1. Normative References . . . . . . . . . . . . . . . . . . . 43
17.2. Informative References . . . . . . . . . . . . . . . . . . 43 17.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Address Block TLV Combinations . . . . . . . . . . . 44 Appendix A. Address Block TLV Combinations . . . . . . . . . . . 44
Appendix B. HELLO Message Example . . . . . . . . . . . . . . . 45 Appendix B. HELLO Message Example . . . . . . . . . . . . . . . 45
Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . 47 Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . 47
Appendix D. Security Considerations . . . . . . . . . . . . . . 49 Appendix D. Security Considerations . . . . . . . . . . . . . . 49
Appendix D.1. Invalid HELLO messages . . . . . . . . . . . . . . . 49 Appendix D.1. Invalid HELLO messages . . . . . . . . . . . . . . . 49
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 51 Appendix E. Flow and Congestion Control . . . . . . . . . . . . 51
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 52 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 52
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 53 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 55 Intellectual Property and Copyright Statements . . . . . . . . . . 55
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) [7]. This protocol uses an exchange a mobile ad hoc network (MANET) [8]. This protocol uses an exchange
of HELLO messages in order that each node can determine the presence of HELLO messages in order that each node can determine the presence
and status of its 1-hop and symmetric 2-hop neighbors. This protocol and status of its 1-hop and symmetric 2-hop neighbors. This protocol
is designed to maintain this information in the presence of a dynamic is designed to maintain this information in the presence of a dynamic
network topology. network topology.
The information maintained by this protocol may be used by other The information maintained by this protocol may be used by other
protocols, such as MANET routing protocols, for determining local protocols, such as MANET routing protocols, for determining local
connectivity and node configuration. connectivity and node configuration.
This specification describes both the HELLO message exchange, the This specification describes both the HELLO message exchange, the
messages being defined as instances of the specification [1], and the messages being defined as instances of the specification [1], and the
information storage required for neighborhood discovery. information storage required for neighborhood discovery.
This protocol makes no assumptions about the underlying link layer, This protocol makes no assumptions about the underlying link layer,
other than support of link local multicast. Link layer information other than support of link local multicast. Link layer information
may be used if available and applicable. 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) [6]. contained in the Optimized Link State Routing Protocol (OLSR) [7].
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5]. document are to be interpreted as described in RFC2119 [5].
The terms "packet", "message", "address", "address block", "TLV", and The terms "packet", "message", "address", "address block", "TLV", and
"TLV block" in this document are to be interpreted as described in "TLV block" in this document are to be interpreted as described in
[1]. [1].
skipping to change at page 7, line 8 skipping to change at page 7, line 8
each node. A node MAY change interface parameter values at any each node. A node MAY change interface parameter values at any
time, subject to some constraints. time, subject to some constraints.
Node parameter - A node parameter is a boolean or numerical value, Node parameter - A node parameter is a boolean or numerical value,
specified for each node. A node MAY change node parameter values specified for each node. A node MAY change node parameter values
at any time, subject to some constraints. at any time, subject to some constraints.
3. Applicability Statement 3. Applicability Statement
This neighborhood discovery protocol supports nodes which each have This neighborhood discovery protocol supports nodes which each have
one or more interfaces participating in the MANET [7]. It provides one or more interfaces participating in the MANET [8]. It provides
each node with local topology information up to two hops away. This each node with local topology information up to two hops away. This
information is made available to other protocols through Interface information is made available to other protocols through Interface
Information Bases and a Node Information Base, described in Section 7 Information Bases and a Node Information Base, described in Section 7
and Section 8. and Section 8.
The protocol is designed to work in networks with a dynamic topology, The protocol is designed to work in networks with a dynamic topology,
and where messages may be lost, such as due to collisions in wireless and where messages may be lost, such as due to collisions in wireless
networks. If relevant link layer information is available then it networks. If relevant link layer information is available then it
may be used by this protocol. may be used by this protocol.
This protocol is designed to work in a completely distributed manner, This protocol is designed to work in a completely distributed manner,
and does not depend on any central entity. It does not require any and does not depend on any central entity. It does not require any
changes to the format of IP packets, thus any existing IP protocol changes to the format of IP packets, thus any existing IP protocol
stack can be used as is. It can use the link local multicast address stack can be used as is. It can use the link local multicast address
and MANET UDP port specified in [2]. and MANET UDP port specified in [2].
This protocol uses the packet and message formats specified in [1]. This protocol uses the packet and message formats specified in [1].
HELLO messages specified by this protocol may be extended using the HELLO messages specified by this protocol may be extended using the
TLV mechanisms described in [1]. For example, if multipoint relays TLV mechanisms described in [1]. For example, if multipoint relays
(MPRs) are to be calculated similarly to as in OLSR [6] and signaled (MPRs) are to be calculated similarly to as in OLSR [7] and signaled
to neighbors, then this information may be added to HELLO messages to neighbors, then this information may be added to HELLO messages
using an address block TLV. HELLO messages can also be transmitted using an address block TLV. HELLO messages can also be transmitted
in packets with messages from other protocols that also use [1]. in packets with messages from other protocols that also use [1].
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
This protocol specifies local (one hop) signaling that: This protocol specifies local (one hop) signaling that:
o Advertises the presence of a node and its interfaces. o Advertises the presence of a node and its interfaces.
skipping to change at page 23, line 23 skipping to change at page 23, line 23
protocol which uses this neighborhood discovery protocol. protocol which uses this neighborhood discovery protocol.
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 [1]. specified in [1].
o Packet header options MAY be used as specified by a protocol which o Packet header options MAY be used as specified by a protocol which
uses this neighborhood discovery protocol. uses this neighborhood discovery protocol.
o This protocol specifies three address block TLVs. It also uses
two message TLVs defined in [3] and one address block TLV defined
in [1]. These six TLV types are all defined only with Subtype ==
0. TLVs of other types, and of these types but without Subtype ==
0, are ignored by this protocol. All references in this protocol
to, for example, a TLV with Type == LINK_STATUS, are to be
considered as referring to a TLV with Type == LINK_STATUS and
Subtype == 0.
10.1. HELLO Messages 10.1. HELLO Messages
A HELLO message MUST contain: A HELLO message MUST contain:
o A VALIDITY_TIME message TLV as specified in [3], representing o A VALIDITY_TIME message TLV as specified in [3], representing
H_HOLD_TIME for the transmitting MANET interface. H_HOLD_TIME for the transmitting MANET interface.
o An address block, with an associated TLV block, known as the Local o An address block, with an associated TLV block, known as the Local
Interface Block, as specified in Section 10.1.1. Interface Block, as specified in Section 10.1.1.
skipping to change at page 24, line 17 skipping to change at page 24, line 26
to interfaces other than the MANET interface for which the HELLO to interfaces other than the MANET interface for which the HELLO
message is transmitted MUST be associated with a corresponding TLV message is transmitted MUST be associated with a corresponding TLV
with Type == OTHER_IF as specified in Table 1. Addresses of the with Type == OTHER_IF as specified in Table 1. Addresses of the
MANET interface on which the HELLO message is transmitted MUST NOT be MANET interface on which the HELLO message is transmitted MUST NOT be
associated with such a TLV. associated with such a TLV.
Note that a Local Interface Block MAY include more than one address Note that a Local Interface Block MAY include more than one address
for each MANET interface, and hence a HELLO message MAY contain more for each MANET interface, and hence a HELLO message MAY contain more
than one address without an OTHER_IF TLV. than one address without an OTHER_IF TLV.
+--------------+-----------------+----------------------------------+ +----------+--------+-----------------------------------------------+
| Name | Value Length | Description | | Name | Value | Description |
+--------------+-----------------+----------------------------------+ | | Length | |
| OTHER_IF | 0 bits | Specifies that the address, in | +----------+--------+-----------------------------------------------+
| | | the Local Interface Block of the | | OTHER_IF | 0 bits | Specifies that the address, in the Local |
| | | message, is an address | | | | Interface Block of the message, is an address |
| | | associated with an interface | | | | associated with an interface other than the |
| | | other than the MANET interface | | | | MANET interface on which the message is |
| | | on which the message is |
| | | transmitted | | | | transmitted |
+--------------+-----------------+----------------------------------+ +----------+--------+-----------------------------------------------+
Table 1 Table 1
10.1.2. Neighbor Address Blocks 10.1.2. Neighbor Address Blocks
Address blocks, each with a following TLV block, in a HELLO message, Address blocks, each with a following TLV block, in a HELLO message,
after the Local Interface Block, are known as Neighbor Address after the Local Interface Block, are known as Neighbor Address
Blocks. These Neighbor Address Blocks are not distinguished in any Blocks. These Neighbor Address Blocks are not distinguished in any
way other than by not being the first address block in the HELLO way other than by not being the first address block in the HELLO
message. A HELLO message MAY contain no Neighbor Address Blocks. message. A HELLO message MAY contain no Neighbor Address Blocks.
A Neighbor Address Block contains current or recently lost 1-hop A Neighbor Address Block contains current or recently lost 1-hop
neighbors' interface addresses, each of which is associated with neighbors' interface addresses, each of which is associated with
address block TLVs as described in Table 2. Other addresses MAY be address block TLVs as described in Table 2. Other addresses MAY be
included in Neighbor Address Blocks, but MUST NOT be associated with included in Neighbor Address Blocks, but MUST NOT be associated with
any of the TLVs specified in Table 2. any of the TLVs specified in Table 2.
+--------------+-----------------+----------------------------------+ +--------------+--------+-------------------------------------------+
| Name | Value Length | Description | | Name | Value | Description |
+--------------+-----------------+----------------------------------+ | | Length | |
| LINK_STATUS | 8 bits | Specifies the status of the link | +--------------+--------+-------------------------------------------+
| | | from the indicated address | | LINK_STATUS | 8 bits | Specifies the status of the link from the |
| | | (LOST, SYMMETRIC or HEARD) | | | | indicated address (LOST, SYMMETRIC or |
| | | HEARD) |
| | | | | | | |
| OTHER_NEIGHB | 8 bits | Specifies that the address is | | OTHER_NEIGHB | 8 bits | Specifies that the address is (SYMMETRIC) |
| | | (SYMMETRIC) or was (LOST) of an | | | | or was (LOST) of an interface of a |
| | | interface of a symmetric 1-hop | | | | symmetric 1-hop neighbor of the node |
| | | neighbor of the node |
| | | transmitting the HELLO message | | | | transmitting the HELLO message |
+--------------+-----------------+----------------------------------+ +--------------+--------+-------------------------------------------+
Table 2 Table 2
A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value == A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value ==
LOST) also performs the function of a TLV with Type == OTHER_IF and LOST) also performs the function of a TLV with Type == OTHER_IF and
the same value. The latter SHOULD NOT also be included. If a TLV the same value. The latter SHOULD NOT also be included. If a TLV
with Type == LINK_STATUS and Value == SYMMETRIC is combined with a with Type == LINK_STATUS and Value == SYMMETRIC is combined with a
TLV with Type == OTHER_IF and Value == LOST then the latter MUST be TLV with Type == OTHER_IF and Value == LOST then the latter MUST be
ignored, and SHOULD NOT be included. See Appendix A. ignored, and SHOULD NOT be included. See Appendix A.
skipping to change at page 41, line 10 skipping to change at page 41, line 10
15.6. Constants 15.6. Constants
o C = 0.0625 second (1/16 second) o C = 0.0625 second (1/16 second)
16. IANA Considerations 16. IANA Considerations
16.1. Message Types 16.1. Message Types
This specification defines one message type, which must be allocated This specification defines one message type, which must be allocated
from the "Assigned Message Types" repository of [1]. from the "Assigned Message Types" repository of [1] with assignment
as specified in Table 3.
+--------------+------+--------------------------------------+ +-------+------+-----------------+
| Name | Type | Description | | Name | Type | Description |
+--------------+------+--------------------------------------+ +-------+------+-----------------+
| HELLO | TBD | Local signaling | | HELLO | TBD | Local signaling |
+--------------+------+--------------------------------------+ +-------+------+-----------------+
Table 3
16.2. TLV Types 16.2. TLV Types
This specification defines three Address Block TLV types, which must This specification defines three address block TLV types, which must
be allocated from the "Assigned Address Block TLV Types" repository be allocated from the "Assigned Address Block TLV Types" repository
of [1]. of [1] with assignments as specified in Table 4.
+--------------+------+---------------------------------------------+ +--------------+------+---------+-----------------------------------+
| Name | Type | Description | | Name | Type | Subtype | Description |
+--------------+------+---------------------------------------------+ +--------------+------+---------+-----------------------------------+
| OTHER_IF | TBD | Specifies that the address, in the Local | | OTHER_IF | TBD | 0 | Specifies that the address is |
| | | Interface Block, is an address associated | | | | | associated with an interface |
| | | with an interface other than the MANET | | | | | other than the MANET interface on |
| | | interface on which the message is | | | | | which the message is transmitted |
| | | transmitted | | | | | |
| | | | | | | 1-255 | RESERVED |
| LINK_STATUS | TBD | Specifies the status of the link from the | | | | | |
| | | indicated address (LOST, SYMMETRIC or | | LINK_STATUS | TBD | 0 | Specifies the status of the link |
| | | HEARD) | | | | | from the indicated address (LOST, |
| | | | | | | | SYMMETRIC or HEARD) |
| OTHER_NEIGHB | TBD | Specifies that the address is (SYMMETRIC) | | | | | |
| | | or recently was (LOST) of an interface of a | | | | 1-255 | RESERVED |
| | | symmetric 1-hop neighbor of the node | | | | | |
| | | transmitting the message | | OTHER_NEIGHB | TBD | 0 | Specifies that the address is |
+--------------+------+---------------------------------------------+ | | | | (SYMMETRIC) or recently was |
| | | | (LOST) of an interface of a |
| | | | symmetric 1-hop neighbor of the |
| | | | node transmitting the message |
| | | | |
| | | 1-255 | RESERVED |
+--------------+------+---------+-----------------------------------+
Table 4
Subtypes indicated as RESERVED may be allocated by standards action,
as specified in [6].
16.3. LINK_STATUS and OTHER_NEIGHB Values 16.3. LINK_STATUS and OTHER_NEIGHB Values
The values which the LINK_STATUS TLV can use are the following: The values which the LINK_STATUS TLV can use are the following:
o LOST = 0 o LOST = 0
o SYMMETRIC = 1 o SYMMETRIC = 1
o HEARD = 2 o HEARD = 2
skipping to change at page 43, line 11 skipping to change at page 43, line 11
o LOST = 0 o LOST = 0
o SYMMETRIC = 1 o SYMMETRIC = 1
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized [1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized
MANET Packet/Message Format", Work In MANET Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-04.txt, January 2007. Progress draft-ietf-manet-packetbb-07.txt, June 2007.
[2] Chakeres, I., "Internet Assigned Numbers Authority (IANA) [2] Chakeres, I., "Internet Assigned Numbers Authority (IANA)
Allocations for the Mobile Ad hoc Networks (MANET) Working Allocations for the Mobile Ad hoc Networks (MANET) Working
Group", Work In Progress draft-ietf-manet-iana-04.txt, May 2007. Group", Work In Progress draft-ietf-manet-iana-05.txt,
June 2007.
[3] Clausen, T. and C. Dearlove, "Representing multi-value time in [3] Clausen, T. and C. Dearlove, "Representing multi-value time in
MANETs", Work In Progress draft-ietf-manet-timetlv-00.txt, MANETs", Work In Progress draft-ietf-manet-timetlv-01.txt,
April 2007. June 2007.
[4] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [4] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", Work In considerations in MANETs", Work In
Progress draft-ietf-manet-jitter-00.txt, April 2007. Progress draft-ietf-manet-jitter-01.txt, June 2007.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998.
17.2. Informative References 17.2. Informative References
[6] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [7] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
[7] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): [8] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET):
Routing Protocol Performance Issues and Evaluation Routing Protocol Performance Issues and Evaluation
Considerations", RFC 2501, January 1999. Considerations", RFC 2501, January 1999.
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 addresses may be included in the address blocks after the Local which addresses may be included in the address blocks after the Local
Interface Block, and with which associated TLVs. These TLVs may have Interface Block, and with which associated TLVs. These TLVs may have
Type == LINK_STATUS or Type == OTHER_NEIGHB, or both. TLVs with Type Type == LINK_STATUS or Type == OTHER_NEIGHB, or both. TLVs with Type
== LINK_STATUS may have three possible values (Value == HEARD, Value == LINK_STATUS may have three possible values (Value == HEARD, Value
skipping to change at page 45, line 16 skipping to change at page 45, line 16
An example HELLO message, transmitted by an originator node with a An example HELLO message, transmitted by an originator node with a
single MANET interface, is as follows. The message uses IPv4 (four single MANET interface, is as follows. The message uses IPv4 (four
octet) addresses without prefix TLVs. The message is transmitted octet) addresses without prefix TLVs. The message is transmitted
with a full message header (message semantics octet is 0) with a hop with a full message header (message semantics octet is 0) with a hop
limit of 1 and a hop count of 0. The overall message length is 50 limit of 1 and a hop count of 0. The overall message length is 50
octets. 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 TLV with semantics value 4, indicating INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating
that no start and stop indexes are included, and each has a value that no start and stop indexes are included, and each has a value
length of 1 octet. The values included (0x68 and 0x50) are time length of 1 octet. The values included (0x68 and 0x50) are time
codes representing the default values of parameters H_HOLD_TIME and codes representing the default values of parameters H_HOLD_TIME and
HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming a HELLO_INTERVAL, respectively (6 seconds and 2 seconds) assuming the
default value of constant C (0.0625 second). default value of constant C (0.0625 second).
The first address block contains 1 local interface address. The The first address block contains 1 local interface address. The
semantics octet value 2 indicates no address tail, and the head semantics octet value 2 indicates no address tail, and the head
length of 4 octets indicates no address mid sections. This address length of 4 octets indicates no address mid sections. This address
block has no TLVs (TLV block content length 0 octets). block has no TLVs (TLV block content length 0 octets).
The second, and last, address block contains 4 neighbor interface The second, and last, address block contains 4 neighbor interface
addresses. The semantics octet value 2 indicates no address tail, addresses. The semantics octet value 2 indicates no address tail,
the head length of 3 octets indicates address mid sections of one the head length of 3 octets indicates address mid sections of one
octet each. The following TLV block (content length 7 octets) octet each. The following TLV block (content length 7 octets)
includes one LINK_STATUS TLV which reports the link status values of includes one LINK_STATUS TLV which reports the link status values of
all reported neighbors in a single multivalue TLV: the first two all reported neighbors in a single multivalue TLV: the first two
addresses are HEARD, the third address is SYMMETRIC and the fourth addresses are HEARD, the third address is SYMMETRIC and the fourth
address is LOST. The TLV semantics value of 20 indicates, in address is LOST. The TLV semantics value of 40 indicates, in
addition to that this is a multivalue TLV, that no start and stop addition to that this is a multivalue TLV, that no start and stop
indexes are included, since values for all addresses are included. indexes are included, since values for all addresses are included.
The TLV value length of 4 octets indicates one octet per value per The TLV value length of 4 octets indicates one octet per value per
address. address.
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 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0| | HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | 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 0 0 1 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 0 1 0 0| |0 0 0 0 0 0 0 1|0 1 1 0 1 0 0 0| INTERVAL_TIME |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0| |0 0 0 0 0 0 0 1|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Head | |0 0 0 0 0 1 0 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0| | Head (cont) |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head | |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid | Mid | | Head (cont) | Mid | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS | | Mid |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD | |0 0 1 0 1 0 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYMMETRIC | LOST | | SYMMETRIC | LOST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix C. Constraints Appendix C. Constraints
Any process which updates the Local Information Base or the Any process which updates the Local Information Base or the
Neighborhood Information Base MUST ensure that all constraints Neighborhood Information Base MUST ensure that all constraints
specified in this appendix are maintained. specified in this appendix are maintained.
skipping to change at page 54, line 14 skipping to change at page 54, line 14
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
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 M. Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
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
 End of changes. 37 change blocks. 
69 lines changed or deleted 94 lines changed or added

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