draft-ietf-manet-timetlv-08.txt   rfc5497.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Network Working Group T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Request for Comments: 5497 LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Category: Standards Track C. Dearlove
Expires: March 30, 2009 BAE Systems Advanced Technology BAE Systems ATC
Centre Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)
September 26, 2008
Representing multi-value time in MANETs
draft-ietf-manet-timetlv-08
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This document specifies an Internet standards track protocol for the
applicable patent or other IPR claims of which he or she is aware Internet community, and requests discussion and suggestions for
have been or will be disclosed, and any of which he or she becomes improvements. Please refer to the current edition of the "Internet
aware will be disclosed, in accordance with Section 6 of BCP 79. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/ietf/1id-abstracts.txt. document authors. All rights reserved.
The list of Internet-Draft Shadow Directories can be accessed at This document is subject to BCP 78 and the IETF Trust's Legal
http://www.ietf.org/shadow.html. Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This Internet-Draft will expire on March 30, 2009. This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
This document describes a general and flexible TLV (type-length-value This document describes a general and flexible TLV (type-length-value
structure) for representing time-values, such as an interval or a structure) for representing time-values, such as an interval or a
duration, using the generalized MANET packet/message format. It duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/
defines two message and two address block TLVs for representing message format. It defines two Message TLVs and two Address Block
validity and interval times for MANET routing protocols. TLVs for representing validity and interval times for MANET routing
protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3 1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 6 5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 6
6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 7 6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 7
6.1. Single-value Time TLVs . . . . . . . . . . . . . . . . . . 8 6.1. Single-Value Time TLVs . . . . . . . . . . . . . . . . . . 8
6.2. Multi-value Time TLVs . . . . . . . . . . . . . . . . . . 9 6.2. Multi-Value Time TLVs . . . . . . . . . . . . . . . . . . 9
7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10 8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10
8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11 8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 11 9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 11
9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 12 9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 12
9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 12 9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The generalized packet/message format [packetbb] specifies a The generalized packet/message format [RFC5444] specifies a signaling
signaling format which MANET routing protocols can employ for format that MANET routing protocols can employ for exchanging
exchanging protocol information. This format presents the ability to protocol information. This format presents the ability to express
express and associate attributes to packets, messages or addresses, and associate attributes to packets, messages, or addresses, by way
by way of a general TLV (type-length-value) mechanism. of a general TLV (type-length-value) mechanism.
This document specifies a general Time TLV structure, which can be This document specifies a general Time TLV structure, which can be
used by any MANET routing protocol that needs to express either used by any MANET routing protocol that needs to express either
single time-values or a set of time-values with each time-value single time-values or a set of time-values with each time-value
associated with a range of hop counts, as provided by the message associated with a range of hop counts, as provided by the Message
header of [packetbb]. This allows a receiving node to determine a Header of [RFC5444]. This allows a receiving node to determine a
single time-value if either it knows its hop count from the single time-value if either it knows its hop count from the
originator node, or the Time TLV specifies a single time-value. originator node or the Time TLV specifies a single time-value.
A time-value is, in this context, not an "absolute point in time", A time-value is, in this context, not an "absolute point in time",
but rather an interval or a duration. An instance of a Time TLV can, but rather an interval or a duration. An instance of a Time TLV can,
therefore, express an interval or a duration such as "10 seconds". therefore, express an interval or a duration such as "10 seconds".
This document also specifies two message TLV types, which use the TLV This document also specifies two Message TLV Types, which use the TLV
structure proposed. These TLV types are INTERVAL_TIME and structure proposed. These TLV Types are INTERVAL_TIME and
VALIDITY_TIME, specifying respectively the maximum time before VALIDITY_TIME, specifying, respectively, the maximum time before
another message of the same type as this message from the same another message of the same type as this message from the same
originator should be received, and the duration for which the originator should be received, and the duration for which the
information in this message is valid after receipt. Note that, if information in this message is valid after receipt. Note that, if
both are present, then the latter will usually be greater than the both are present, then the latter will usually be greater than the
former in order to allow for possible message loss. former in order to allow for possible message loss.
This document also specifies two address block TLV types, which use This document also specifies two Address Block TLV Types, which use
the TLV structure proposed. These TLV types are INTERVAL_TIME and the TLV structure proposed. These TLV Types are INTERVAL_TIME and
VALIDITY_TIME, defined equivalently to the two message TLVs with the VALIDITY_TIME, defined equivalently to the two Message TLVs with the
same names. same names.
1.1. Motivation and Rationale 1.1. Motivation and Rationale
The Time TLV structure, specified in this document, is intended to be The Time TLV structure, specified in this document, is intended to be
used as a component in a MANET routing protocol, e.g. to indicate the used as a component in a MANET routing protocol, e.g., to indicate
expected spacing between successive transmissions of a given message the expected spacing between successive transmissions of a given
type, by including a Time TLV in transmitted messages. Message Type, by including a Time TLV in transmitted messages.
Some MANET routing protocols may employ very short spacing for some Some MANET routing protocols may employ very short spacing for some
messages and very long spacing for others, or may change the message messages and very long spacing for others, or may change the message
transmission rate according to observed behavior. For example, if a transmission rate according to observed behavior. For example, if a
network is observed at some point in time to exhibit a highly dynamic network is observed at some point in time to exhibit a highly dynamic
topology, a very short (sub-second) message spacing could be topology, a very short (sub-second) message spacing could be
appropriate, whereas if the network later is observed to stabilize, appropriate, whereas if the network later is observed to stabilize,
multi-hour message spacing may become appropriate. Different MANET multi-hour message spacing may become appropriate. Different MANET
routing protocols and different deployments of MANET routing routing protocols and different deployments of MANET routing
protocols may have different granularity requirement and bounds on protocols may have different granularity requirements and bounds on
shortest and longest spacing between successive message shortest and longest spacing between successive message
transmissions. transmissions.
In addition, MANET routing protocol deployments typically use In addition, MANET routing protocol deployments typically use
bandwidth limited wireless network interfaces, and therefore prefer bandwidth-limited wireless network interfaces, and therefore prefer
to trade off computational complexity for a saving in the number of to trade off computational complexity for a saving in the number of
bits transmitted. This is practical in this case, because the bits transmitted. This is practical in this case, because the
intended usages of Time TLVs, including the specified examples of intended usages of Time TLVs, including the specified examples of
message interval time and information validity time, do not require message interval time and information validity time, do not require
high precision values of time. high-precision values of time.
The Time TLV structure, specified in this document, caters to these The Time TLV structure, specified in this document, caters to these
characteristics by: characteristics by:
o encoding time-values, such as an interval or a duration, in an 8 o encoding time-values, such as an interval or a duration, in an
bit field; while 8-bit field; while
o allowing these time-values to range from "very small" (e.g. 1/1024 o allowing these time-values to range from "very small" (e.g.,
second) to "very long" (e.g. 45 days); and 1/1024 second) to "very long" (e.g., 45 days); and
o allowing a MANET routing protocol, or a deployment, to parametrize o allowing a MANET routing protocol, or a deployment, to
this (e.g. to attain finer granularity at the expense of a lower parameterize this (e.g., to attain finer granularity at the
upper bound) through a single parameter, C. expense of a lower upper bound) through a single parameter, C.
The parameter C must be the same for all MANET routers in the same The parameter C must be the same for all MANET routers in the same
deployment. deployment.
The TLV mechanism as specified in [packetbb] allows associating a The TLV mechanism as specified in [RFC5444] allows associating a
"value" to either a packet, a message or to addresses. The data "value" to either a packet, a message, or to addresses. The data
structure for doing so - the TLV - is identical in each of the three structure for doing so -- the TLV -- is identical in each of the
cases, however the TLV's position in a received packet allows three cases; however, the TLV's position in a received packet allows
determining if that TLV is a "packet TLV" (it appears in the packet determining if that TLV is a "Packet TLV" (it appears in the Packet
header, before any messages), a "message TLV" (it appears in the TLV Header, before any messages), a "Message TLV" (it appears in the TLV
block immediately following a message header) or an "address block Block immediately following a Message Header), or an "Address Block
TLV" (it appears in the TLV block immediately following an address TLV" (it appears in the TLV Block immediately following an Address
block). Block).
While TLVs may be structurally identical, that which they express may While TLVs may be structurally identical, that which they express may
be different. This is determined from the kind (packet, message or be different. This is determined from the kind (packet, message, or
address block) and type of the TLV. For example one TLV might Address Block) and type of the TLV. For example, one TLV might
associate a lifetime to an address, another a content sequence number associate a lifetime to an address, another a content sequence number
to a message, and another a cryptographic signature to a packet. For to a message, and another a cryptographic signature to a packet. For
this reason, [packetbb] specifies separate registries for packet, this reason, [RFC5444] specifies separate registries for Packet TLV
message and address block TLV types, and does not specify any Types, Message TLV Types, and Address Block TLV Types, and it does
structure in the TLV value field. not specify any structure in the TLV Value field.
The TLVs defined in this document express, essentially, that "this The TLVs defined in this document express, essentially, that "this
information will be refreshed within X seconds" and that "this information will be refreshed within X seconds" and that "this
information is valid for X seconds after being received", each information is valid for X seconds after being received", each
allowing the "X seconds" to be specified as a function of the number allowing the "X seconds" to be specified as a function of the number
of hops from the originator of the information. This document of hops from the originator of the information. This document
specifies a general format allowing expressing and encoding this as specifies a general format allowing expressing and encoding this as
the value field of a TLV. This representation uses a compact (8 bit) the value field of a TLV. This representation uses a compact (8-bit)
representation of time, as message size is an issue in many MANETs, representation of time, as message size is an issue in many MANETs,
and the offered precision and range is appropriate for MANET routing and the offered precision and range is appropriate for MANET routing
protocols. protocols.
A TLV of this format may be used for packets, messages or addresses. A TLV of this format may be used for packets, messages, or addresses.
For example, a proactive MANET routing protocol periodically For example, a proactive MANET routing protocol periodically
reporting link state information could include a TLV of this format reporting link-state information could include a TLV of this format
as a message TLV. This may indicate a different periodicity in as a Message TLV. This may indicate a different periodicity in
different scopes (possibly frequently up to a few hops, less different scopes (possibly frequently up to a few hops, less
frequently beyond that) because some messages may be sent with frequently beyond that) because some messages may be sent with
limited scope, as specified in [packetbb]. A reactive MANET routing limited scope, as specified in [RFC5444]. A reactive MANET routing
protocol could include a TLV of this format as an address block TLV protocol could include a TLV of this format as an Address Block TLV
for reporting the lifetime of routes to individual addresses. for reporting the lifetime of routes to individual addresses.
In addition to defining the general format as outlined above, this In addition to defining the general format as outlined above, this
document requests IANA assignments for INTERVAL_TIME and document requests IANA assignments for INTERVAL_TIME and
VALIDITY_TIME TLVs. These IANA assignments are requested in this VALIDITY_TIME TLVs. These IANA assignments are requested in this
document in order to avoid interdependencies between otherwise document in order to avoid interdependencies between otherwise
unrelated MANET protocols and in order to not exhaust the TLV type unrelated MANET protocols and in order to not exhaust the TLV Type
spaces by having different protocols request types for essentially spaces by having different protocols request types for essentially
identical data structures. Only message and address block TLVs are identical data structures. Only Message TLVs and Address Block TLVs
requested, as these are those for which a need has been demonstrated. are requested, as these are those for which a need has been
demonstrated.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses terminology from [packetbb], and Additionally, this document uses terminology from [RFC5444], and
introduces the following terminology: introduces the following terminology:
hop count - the number of hops from the message originator to the hop count - the number of hops from the message originator to the
message recipient. This is defined to equal the <msg-hop-count> message recipient. This is defined to equal the <msg-hop-count>
field in the <msg-header> element defined in [packetbb], if field in the <msg-header> element defined in [RFC5444], if
present, after it is incremented on reception. If the <msg-hop- present, after it is incremented on reception. If the <msg-hop-
count> field is not present, or in a packet TLV, then hop count is count> field is not present, or in a Packet TLV, then hop count is
defined to equal 255. defined to equal 255.
time-value - a time, measured in seconds. time-value - a time, measured in seconds.
time-code - an 8 bit field, representing a time-value. time-code - an 8-bit field, representing a time-value.
3. Applicability Statement 3. Applicability Statement
The TLV structure described in this document is applicable whenever a The TLV structure described in this document is applicable whenever a
single time-value, or a time-value that varies with the number of single time-value, or a time-value that varies with the number of
hops from the originator of a message, is required in a protocol hops from the originator of a message, is required in a protocol
using the generalized MANET packet/message format [packetbb]. using the generalized MANET packet/message format [RFC5444].
Examples of time-values that may be included in a protocol message Examples of time-values that may be included in a protocol message
are: are:
o The maximum time interval until the next message of the same type o The maximum time interval until the next message of the same type
is to be generated by the message's originator node. is to be generated by the message's originator node.
o The validity time of the information with which the time-value is o The validity time of the information with which the time-value is
associated. associated.
Either of these may vary with the hop count between the originating Either of these may vary with the hop count between the originating
and receiving nodes, e.g. if messages of the same type are sent with and receiving nodes, e.g., if messages of the same type are sent with
different hop limits as defined in [packetbb]. different hop limits as defined in [RFC5444].
Parts of this document have been generalized from material in the Parts of this document have been generalized from material in the
proactive MANET routing protocol OLSR (The Optimized Link State proactive MANET routing protocol OLSR (Optimized Link State Routing
Routing Protocol) [RFC3626]. Protocol) [RFC3626].
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
This document does not specify a protocol nor does it mandate This document does not specify a protocol nor does it mandate
specific node or protocol behavior. Rather, it outlines mechanisms specific node or protocol behavior. Rather, it outlines mechanisms
for encoding time-values using the TLV mechanism of [packetbb]. for encoding time-values using the TLV mechanism of [RFC5444].
5. Representing Time 5. Representing Time
This document specifies a TLV structure in which time-values are each This document specifies a TLV structure in which time-values are each
represented in an 8 bit time-code, one or more of which may be used represented in an 8-bit time-code, one or more of which may be used
in a TLV's <value> field. Of these 8 bits, the least significant 3 in a TLV's <value> field. Of these 8 bits, the least significant 3
bits represent the mantissa (a), and the most significant 5 bits bits represent the mantissa (a), and the most significant 5 bits
represent the exponent (b), so that: represent the exponent (b), so that:
o time-value = (1 + a/8) * 2^b * C o time-value := (1 + a/8) * 2^b * C
o time-code = 8 * b + a
o time-code := 8 * b + a
All nodes in the MANET MUST use the same value of the constant C, All nodes in the MANET MUST use the same value of the constant C,
which will be specified in seconds, hence so will be all time-values. which will be specified in seconds, hence so will be all time-values.
C MUST be greater than 0 seconds. Note that ascending values of the C MUST be greater than 0 seconds. Note that ascending values of the
time-code represent ascending time-values, time-values may thus be time-code represent ascending time-values; time-values may thus be
compared by comparison of time-codes. compared by comparison of time-codes.
An algorithm for computing the time-code representing the smallest An algorithm for computing the time-code representing the smallest
representable time-value not less than the time-value t is: representable time-value not less than the time-value t is:
1. find the largest integer b such that t/C >= 2^b; 1. find the largest integer b such that t/C >= 2^b;
2. set a = 8 * (t / (C * 2^b) - 1), rounded up to the nearest 2. set a := 8 * (t / (C * 2^b) - 1), rounded up to the nearest
integer; integer;
3. if a == 8 then set b = b + 1 and set a = 0; 3. if a = 8, then set b := b + 1 and set a := 0;
4. if 0 <= a <= 7, and 0 <= b <= 31, then the required time-value 4. if 0 <= a <= 7, and 0 <= b <= 31, then the required time-value
can be represented by the time-code 8 * b + a, otherwise it can can be represented by the time-code 8 * b + a, otherwise it
not. cannot.
The minimum time-value that can be represented in this manner is C. The minimum time-value that can be represented in this manner is C.
The maximum time-value that can be represented in this manner is 15 * The maximum time-value that can be represented in this manner is 15 *
2^28 * C, or about 4.0 * 10^9 * C. If, for example, C = 1/1024 2^28 * C, or about 4.0 * 10^9 * C. If, for example, C = 1/1024
second, then this is about 45 days. second, then this is about 45 days.
A protocol using this time representation MUST define the value of C. A protocol using this time representation MUST define the value of C.
A protocol using this specification MAY specify that the all bits A protocol using this specification MAY specify that the all-bits
zero time-value (0) represents a time-value of zero and/or that the zero time-value (0) represents a time-value of zero and/or that the
all bits one time-value (255) represents an indefinitely large time- all-bits one time-value (255) represents an indefinitely large time-
value. value.
6. General Time TLV Structure 6. General Time TLV Structure
The following data structure allows the representation of a single The following data structure allows the representation of a single
time-value, or of a default time-value plus pairs of (time-values, time-value, or of a default time-value plus pairs of (time-values,
hop counts) for when hop count dependent time-values are required. hop counts) for when hop-count-dependent time-values are required.
The time-values are represented as time-codes as defined in The time-values are represented as time-codes as defined in
Section 5. This <time-data> data structure is specified, using the Section 5. This <time-data> data structure is specified, using the
regular expression syntax of [packetbb], by: regular expression syntax of [RFC5444], by:
<time-data> = (<time-code><hop-count>)*<time-code> <time-data> = (<time-code><hop-count>)*<time-code>
where: where:
<time-code> is an 8 bit unsigned integer field containing a time- <time-code> is an 8-bit unsigned integer field containing a time-
code as defined in Section 5. code as defined in Section 5.
<hop-count> is an 8 bit unsigned integer field specifying a hop <hop-count> is an 8-bit unsigned integer field specifying a hop
count from the message originator. count from the message originator.
A <time-data> structure thus consists of an odd number of octets; A <time-data> structure thus consists of an odd number of octets;
with a repetition factor of n for the (time, hop count) pairs in the with a repetition factor of n for the (time, hop count) pairs in the
regular expression syntax, it contains 2n+1 octets. On reception, n regular expression syntax, it contains 2n+1 octets. On reception, n
is determined from the length. is determined from the length.
A <time-data> field may be thus represented by: A <time-data> field may be thus represented by:
<t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default> <t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default>
skipping to change at page 8, line 27 skipping to change at page 8, line 27
<d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence, <d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence,
with <d_n> < 255. Then, at the receiving node's hop count from the with <d_n> < 255. Then, at the receiving node's hop count from the
originator node, the time-value indicated is that represented by the originator node, the time-value indicated is that represented by the
time-code: time-code:
o <t_1>, if n > 0 and hop count <= <d_1>; o <t_1>, if n > 0 and hop count <= <d_1>;
o <t_i+1>, if n > 1 and <d_i> < hop count <= <d_i+1> for some i such o <t_i+1>, if n > 1 and <d_i> < hop count <= <d_i+1> for some i such
that 1 <= i < n; that 1 <= i < n;
o <t_default> otherwise, i.e. if n == 0 or hop count > <d_n>. o <t_default> otherwise, i.e. if n = 0 or hop count > <d_n>.
If included in a message without a <msg-hop-count> field in its If included in a message without a <msg-hop-count> field in its
message header, or in a packet TLV, then the form of this data Message Header, or in a Packet TLV, then the form of this data
structure with a single time-code in <time-data> (i.e. n == 0) SHOULD structure with a single time-code in <time-data> (i.e., n = 0) SHOULD
be used. be used.
6.1. Single-value Time TLVs 6.1. Single-Value Time TLVs
The purpose of a single value Time TLV is to allow a single time- The purpose of a single value Time TLV is to allow a single time-
value to be determined by a node receiving an entity containing the value to be determined by a node receiving an entity containing the
Time TLV, based on its hop count from the entity's originator. The Time TLV, based on its hop count from the entity's originator. The
Time TLV may contain information that allows that time-value to be a Time TLV may contain information that allows that time-value to be a
function of the hop count, and thus different receiving nodes may function of the hop count; thus, different receiving nodes may
determine different time-values. determine different time-values.
A single-value Time TLV may be a packet TLVs, a message TLV or an A single-value Time TLV may be a Packet TLV, a Message TLV, or an
address block TLV. Address Block TLV.
A Time TLV which has the tismultivalue flag cleared ('0') in its A Time TLV that has the tismultivalue flag cleared ('0') in its <tlv-
<tlv-flags> field, as defined in [packetbb], contains a single <time- flags> field, as defined in [RFC5444], contains a single <time-data>,
data>, as defined above, in its <value> field. For such a Time TLV: as defined above, in its <value> field. For such a Time TLV:
o The <length> field in the TLV MUST contain the value 2n+1, with n o The <length> field in the TLV MUST contain the value 2n+1, with n
being the number of (time-value, hop count) pairs in the Time TLV. being the number of (time-value, hop count) pairs in the Time TLV.
o The number of (time-value, hop count) pairs MUST be identified by o The number of (time-value, hop count) pairs MUST be identified by
inspecting the <length> field in the TLV. The number of such inspecting the <length> field in the TLV. The number of such
pairs, n, is: pairs, n, is:
* n = (<length> - 1) / 2 * n := (<length> - 1) / 2
This MUST be an integer value. This MUST be an integer value.
6.2. Multi-value Time TLVs 6.2. Multi-Value Time TLVs
The purpose of a multi-value Time TLV is to associate a set of <time- The purpose of a multi-value Time TLV is to associate a set of <time-
data> structures to an identically sized set of addresses, as data> structures to an identically sized set of addresses, as
described in [packetbb]. For each of these <time-data> structures, a described in [RFC5444]. For each of these <time-data> structures, a
single time-value can be determined by a node receiving an entity single time-value can be determined by a node receiving an entity
containing the Time TLV, based on its hop count from the entity's containing the Time TLV, based on its hop count from the entity's
originator. The Time TLV may contain information that allows that originator. The Time TLV may contain information that allows that
time-value to be a function of the hop count, and thus different time-value to be a function of the hop count, and thus different
receiving nodes may determine different time-values. receiving nodes may determine different time-values.
Multi-value Time TLVs MUST be address block TLVs. A multi-value Time Multi-value Time TLVs MUST be Address Block TLVs. A multi-value Time
TLV MUST NOT be a packet or message TLV. TLV MUST NOT be a Packet TLV or Message TLV.
A Time TLV which has the tismultivalue flag set ('1') in its <tlv- A Time TLV that has the tismultivalue flag set ('1') in its <tlv-
flags> field, as defined in [packetbb], contains a sequence of <time- flags> field, as defined in [RFC5444], contains a sequence of <time-
data> structures, as defined above, in its <value> field. For such a data> structures, as defined above, in its <value> field. For such a
Time TLV: Time TLV:
o The <length> field in the TLV MUST contain the value m * (2n+1), o The <length> field in the TLV MUST contain the value m * (2n+1),
with n being the number of (time-value, hop count) pairs in the with n being the number of (time-value, hop count) pairs in the
Time TLV, and m being number-values as defined in [packetbb]. Time TLV, and m being number-values as defined in [RFC5444].
o The number of <time-data> structures included in the <value> field o The number of <time-data> structures included in the <value> field
is equal to number-values as defined in [packetbb]. is equal to number-values as defined in [RFC5444].
o The number of (time-value, hop count) pairs in each <time-data> o The number of (time-value, hop count) pairs in each <time-data>
structure MUST be the same, and MUST be identified by inspecting structure MUST be the same, and MUST be identified by inspecting
the <length> field in the TLV and using number-values as defined the <length> field in the TLV and using number-values as defined
in [packetbb]. The number of such pairs in each <time-data> in [RFC5444]. The number of such pairs in each <time-data>
structure, n, is: structure, n, is:
* n = ((<length> / number-values) - 1) / 2 * n := ((<length> / number-values) - 1) / 2
This MUST be an integer value. The lists of hop count values MAY This MUST be an integer value. The lists of hop count values MAY
be different. be different.
7. Message TLVs 7. Message TLVs
Two message TLVs are defined, for signaling message interval Two Message TLVs are defined, for signaling message interval
(INTERVAL_TIME) and message validity time (VALIDITY_TIME). (INTERVAL_TIME) and message validity time (VALIDITY_TIME).
7.1. INTERVAL_TIME TLV 7.1. INTERVAL_TIME TLV
An INTERVAL_TIME TLV is a message TLV that defines the maximum time An INTERVAL_TIME TLV is a Message TLV that defines the maximum time
before another message of the same type as this message from the same before another message of the same type as this message from the same
originator should be received. This interval time MAY be specified originator should be received. This interval time MAY be specified
to depend on the hop count from the originator. (This is appropriate to depend on the hop count from the originator. (This is appropriate
if messages are sent with different hop limits, so that receiving if messages are sent with different hop limits so that receiving
nodes at greater hop counts have an increased interval time.) nodes at greater hop counts have an increased interval time.)
A message MUST NOT include more than one INTERVAL_TIME TLV. A message MUST NOT include more than one INTERVAL_TIME TLV.
An INTERVAL_TIME TLV is an example of a Time TLV specified as in An INTERVAL_TIME TLV is an example of a Time TLV specified as in
Section 5. Section 5.
7.2. VALIDITY_TIME TLV 7.2. VALIDITY_TIME TLV
A VALIDITY_TIME TLV is a message TLV that defines the validity time A VALIDITY_TIME TLV is a Message TLV that defines the validity time
of the information carried in the message in which the TLV is of the information carried in the message in which the TLV is
contained. After this time the receiving node MUST consider the contained. After this time, the receiving node MUST consider the
message content to no longer be valid (unless repeated in a later message content to no longer be valid (unless repeated in a later
message). The validity time of a message MAY be specified to depend message). The validity time of a message MAY be specified to depend
on the hop count from its originator. (This is appropriate if on the hop count from its originator. (This is appropriate if
messages are sent with different hop limits, so that receiving nodes messages are sent with different hop limits so that receiving nodes
at greater hop counts receive information less frequently and must at greater hop counts receive information less frequently and must
treat is as valid for longer.) treat is as valid for longer.)
A message MUST NOT include more than one VALIDITY_TIME TLV. A message MUST NOT include more than one VALIDITY_TIME TLV.
A VALIDITY_TIME TLV is an example of a Time TLV specified as in A VALIDITY_TIME TLV is an example of a Time TLV specified as in
Section 5. Section 5.
8. Address Block TLVs 8. Address Block TLVs
Two address block TLVs are defined, for signaling address Two Address Block TLVs are defined, for signaling address
advertisement interval (INTERVAL_TIME) and address validity time advertisement interval (INTERVAL_TIME) and address validity time
(VALIDITY_TIME). (VALIDITY_TIME).
8.1. INTERVAL_TIME TLV 8.1. INTERVAL_TIME TLV
An INTERVAL_TIME TLV is an address block TLV that defines the maximum An INTERVAL_TIME TLV is an Address Block TLV that defines the maximum
time before this address from the same originator should be received time before this address from the same originator should be received
again. This interval time MAY be specified to depend on the hop again. This interval time MAY be specified to depend on the hop
count from the originator. (This is appropriate if addresses are count from the originator. (This is appropriate if addresses are
contained in messages sent with different hop limits, so that contained in messages sent with different hop limits so that
receiving nodes at greater hop counts have an increased interval receiving nodes at greater hop counts have an increased interval
time.) time.)
A protocol using this TLV and the similarly named message TLV MUST A protocol using this TLV and the same named Message TLV MUST specify
specify how to interpret the case when both are present (typically how to interpret the case when both are present (typically, that the
that the former over-rides the latter for those addresses which are former overrides the latter for those addresses that are covered by
covered by the former). the former).
An INTERVAL_TIME TLV is an example of a Time TLV specified as in An INTERVAL_TIME TLV is an example of a Time TLV specified as in
Section 5. Section 5.
8.2. VALIDITY_TIME TLV 8.2. VALIDITY_TIME TLV
A VALIDITY_TIME TLV is an address block TLV that defines the validity A VALIDITY_TIME TLV is an Address Block TLV that defines the validity
time of the addresses to which the TLV is associated. After this time of the addresses to which the TLV is associated. After this
time the receiving node MUST consider the addresses to no longer be time, the receiving node MUST consider the addresses to no longer be
valid (unless these are repeated in a later message). The validity valid (unless these are repeated in a later message). The validity
time of an address MAY be specified to depend on the hop count from time of an address MAY be specified to depend on the hop count from
its originator. (This is appropriate if addresses are contained in its originator. (This is appropriate if addresses are contained in
messages sent with different hop limits, so that receiving nodes at messages sent with different hop limits so that receiving nodes at
greater hop counts receive information less frequently and must treat greater hop counts receive information less frequently and must treat
is as valid for longer.) is as valid for longer.)
A protocol using this TLV and the similarly named message TLV MUST A protocol using this TLV and the same named Message TLV MUST specify
specify how to interpret the case when both are present (typically how to interpret the case when both are present (typically, that the
that the former over-rides the latter for those addresses which are former overrides the latter for those addresses that are covered by
covered by the former). the former).
A VALIDITY_TIME TLV is an example of a Time TLV specified as in A VALIDITY_TIME TLV is an example of a Time TLV specified as in
Section 5. Section 5.
9. IANA Considerations 9. IANA Considerations
This specification defines two message TLV types, which must be This specification defines two Message TLV Types, which have been
allocated from the "Assigned Message TLV Types" repository of allocated from the "Assigned Message TLV Types" repository of
[packetbb] as specified in Table 1 and two address block TLV types, [RFC5444] as specified in Table 1, and two Address Block TLV Types,
which must be allocated from the "Assigned Address Block TLV Types" which have been allocated from the "Assigned Address Block TLV Types"
repository of [packetbb] as specified in Table 2. repository of [RFC5444] as specified in Table 2.
IANA is requested to assign the same numerical value to the message IANA has assigned the same numerical value to the Message TLV Type
TLV and address block TLV types with the same name. and Address Block TLV Type with the same name.
9.1. Expert Review: Evaluation Guidelines 9.1. Expert Review: Evaluation Guidelines
For the registries for TLV type extensions where an Expert Review is For the registries for TLV Type Extensions where an Expert Review is
required, the designated expert SHOULD take the same general required, the designated expert SHOULD take the same general
recommendations into consideration as are specified by [packetbb]. recommendations into consideration as are specified by [RFC5444].
9.2. Message TLV Types 9.2. Message TLV Types
+---------------+------+-----------+--------------------------------+ +---------------+------+-----------+--------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | Extension | | | | | Extension | |
+---------------+------+-----------+--------------------------------+ +---------------+------+-----------+--------------------------------+
| INTERVAL_TIME | TBD1 | 0 | The maximum time before | | INTERVAL_TIME | 0 | 0 | The maximum time before |
| | | | another message of the same | | | | | another message of the same |
| | | | type as this message from the | | | | | type as this message from the |
| | | | same originator should be | | | | | same originator should be |
| | | | received | | | | | received |
| | | 1-223 | Expert Review | | Unassigned | 0 | 1-223 | Expert Review |
| | | 224-255 | Experimental Use | | | | 224-255 | Experimental Use |
| VALIDITY_TIME | TBD2 | 0 | The time from receipt of the | | VALIDITY_TIME | 1 | 0 | The time from receipt of the |
| | | | message during which the | | | | | message during which the |
| | | | information contained in the | | | | | information contained in the |
| | | | message is to be considered | | | | | message is to be considered |
| | | | valid | | | | | valid |
| | | 1-223 | Expert Review | | Unassigned | 1 | 1-223 | Expert Review |
| | | 224-255 | Experimental Use | | | | 224-255 | Experimental Use |
+---------------+------+-----------+--------------------------------+ +---------------+------+-----------+--------------------------------+
Table 1 Table 1
9.3. Address Block TLV Types 9.3. Address Block TLV Types
+---------------+------+-----------+--------------------------------+ +---------------+------+-----------+--------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+---------------+------+-----------+--------------------------------+ +---------------+------+-----------+--------------------------------+
| INTERVAL_TIME | TBD1 | 0 | The maximum time before | | INTERVAL_TIME | 0 | 0 | The maximum time before |
| | | | another message of the same | | | | | another message of the same |
| | | | type as this message from the | | | | | type as this message from the |
| | | | same originator and containing | | | | | same originator and containing |
| | | | this address should be | | | | | this address should be |
| | | | received | | | | | received |
| | | 1-223 | Expert Review | | Unassigned | 0 | 1-223 | Expert Review |
| | | 224-255 | Experimental Use | | | | 224-255 | Experimental Use |
| VALIDITY_TIME | TBD2 | 0 | The time from receipt of the | | VALIDITY_TIME | 1 | 0 | The time from receipt of the |
| | | | address during which the | | | | | address during which the |
| | | | information regarding this | | | | | information regarding this |
| | | | address is to be considered | | | | | address is to be considered |
| | | | valid | | | | | valid |
| | | 1-223 | Expert Review | | Unassigned | 0 | 1-223 | Expert Review |
| | | 224-255 | Experimental Use | | | | 224-255 | Experimental Use |
+---------------+------+-----------+--------------------------------+ +---------------+------+-----------+--------------------------------+
Table 2 Table 2
10. Security Considerations 10. Security Considerations
This document specifies how to add data structures (TLVs) which This document specifies how to add data structures (TLVs) that
provide timing information to packets and messages specified using provide timing information to packets and messages specified using
[packetbb]. In particular, information validity durations and [RFC5444]. In particular, information validity durations and
reporting intervals may be added. reporting intervals may be added.
The general security threats that apply are those general to The general security threats that apply are those general to
[packetbb] and described therein, problems of integrity and [RFC5444] and described therein, problems of integrity and
confidentiality. With regard to the former, modification of a time confidentiality. With regard to the former, modification of a Time
TLV can cause information to have an invalid validity time, or TLV can cause information to have an invalid validity time, or
expected interval time. This may cause incorrect protocol expected interval time. This may cause incorrect protocol
performance. Modification or addition of timed information can add performance. Modification or addition of timed information can add
to a protocol's workload (especially if a short validity time is to a protocol's workload (especially if a short validity time is
specified) and storage requirements (especially if a long validity specified) and storage requirements (especially if a long validity
time is specified). time is specified).
To counter these threats, the security suggestions in [packetbb], for To counter these threats, the security suggestions in [RFC5444], for
the use of authentication and encryption, are appropriate. the use of authentication and encryption, are appropriate.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
draft-ietf-manet-packetbb-16.txt (work in progress), Format", RFC 5444, February 2009.
September 2008.
11.2. Informative References 11.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank Brian Adamson and Justin Dean (both The authors would like to thank Brian Adamson and Justin Dean (both
NRL) and Ian Chakeres (Motorola) for their contributions, and Alan NRL) and Ian Chakeres (Motorola) for their contributions, and Alan
skipping to change at page 15, line 4 skipping to change at line 608
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 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/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 101 change blocks. 
176 lines changed or deleted 177 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/