doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5497.txt b/doc/rfc/rfc5497.txt
new file mode 100644
index 0000000..4f531a7
--- /dev/null
+++ b/doc/rfc/rfc5497.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                         T. Clausen
+Request for Comments: 5497                      LIX, Ecole Polytechnique
+Category: Standards Track                                    C. Dearlove
+                                                         BAE Systems ATC
+                                                              March 2009
+
+
+    Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   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 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
+
+   This document describes a general and flexible TLV (type-length-value
+   structure) for representing time-values, such as an interval or a
+   duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/
+   message format.  It defines two Message TLVs and two Address Block
+   TLVs for representing validity and interval times for MANET routing
+   protocols.
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 1]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Motivation and Rationale . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  6
+   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  6
+   5.  Representing Time  . . . . . . . . . . . . . . . . . . . . . .  6
+   6.  General Time TLV Structure . . . . . . . . . . . . . . . . . .  7
+     6.1.  Single-Value Time TLVs . . . . . . . . . . . . . . . . . .  8
+     6.2.  Multi-Value Time TLVs  . . . . . . . . . . . . . . . . . .  9
+   7.  Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     7.1.  INTERVAL_TIME TLV  . . . . . . . . . . . . . . . . . . . . 10
+     7.2.  VALIDITY_TIME TLV  . . . . . . . . . . . . . . . . . . . . 10
+   8.  Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10
+     8.1.  INTERVAL_TIME TLV  . . . . . . . . . . . . . . . . . . . . 10
+     8.2.  VALIDITY_TIME TLV  . . . . . . . . . . . . . . . . . . . . 11
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+     9.1.  Expert Review: Evaluation Guidelines . . . . . . . . . . . 11
+     9.2.  Message TLV Types  . . . . . . . . . . . . . . . . . . . . 12
+     9.3.  Address Block TLV Types  . . . . . . . . . . . . . . . . . 12
+   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 2]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+1.  Introduction
+
+   The generalized packet/message format [RFC5444] specifies a signaling
+   format that MANET routing protocols can employ for exchanging
+   protocol information.  This format presents the ability to express
+   and associate attributes to packets, messages, or addresses, by way
+   of a general TLV (type-length-value) mechanism.
+
+   This document specifies a general Time TLV structure, which can be
+   used by any MANET routing protocol that needs to express either
+   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
+   Header of [RFC5444].  This allows a receiving node to determine a
+   single time-value if either it knows its hop count from the
+   originator node or the Time TLV specifies a single time-value.
+
+   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,
+   therefore, express an interval or a duration such as "10 seconds".
+
+   This document also specifies two Message TLV Types, which use the TLV
+   structure proposed.  These TLV Types are INTERVAL_TIME and
+   VALIDITY_TIME, specifying, respectively, the maximum time before
+   another message of the same type as this message from the same
+   originator should be received, and the duration for which the
+   information in this message is valid after receipt.  Note that, if
+   both are present, then the latter will usually be greater than the
+   former in order to allow for possible message loss.
+
+   This document also specifies two Address Block TLV Types, which use
+   the TLV structure proposed.  These TLV Types are INTERVAL_TIME and
+   VALIDITY_TIME, defined equivalently to the two Message TLVs with the
+   same names.
+
+1.1.  Motivation and Rationale
+
+   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 expected spacing between successive transmissions of a given
+   Message Type, by including a Time TLV in transmitted messages.
+
+   Some MANET routing protocols may employ very short spacing for some
+   messages and very long spacing for others, or may change the message
+   transmission rate according to observed behavior.  For example, if a
+   network is observed at some point in time to exhibit a highly dynamic
+   topology, a very short (sub-second) message spacing could be
+   appropriate, whereas if the network later is observed to stabilize,
+   multi-hour message spacing may become appropriate.  Different MANET
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 3]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+   routing protocols and different deployments of MANET routing
+   protocols may have different granularity requirements and bounds on
+   shortest and longest spacing between successive message
+   transmissions.
+
+   In addition, MANET routing protocol deployments typically use
+   bandwidth-limited wireless network interfaces, and therefore prefer
+   to trade off computational complexity for a saving in the number of
+   bits transmitted.  This is practical in this case, because the
+   intended usages of Time TLVs, including the specified examples of
+   message interval time and information validity time, do not require
+   high-precision values of time.
+
+   The Time TLV structure, specified in this document, caters to these
+   characteristics by:
+
+   o  encoding time-values, such as an interval or a duration, in an
+      8-bit field; while
+
+   o  allowing these time-values to range from "very small" (e.g.,
+      1/1024 second) to "very long" (e.g., 45 days); and
+
+   o  allowing a MANET routing protocol, or a deployment, to
+      parameterize this (e.g., to attain finer granularity at the
+      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
+   deployment.
+
+   The TLV mechanism as specified in [RFC5444] allows associating a
+   "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 cases; however, the TLV's position in a received packet allows
+   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
+   Block immediately following a Message Header), or an "Address Block
+   TLV" (it appears in the TLV Block immediately following an Address
+   Block).
+
+   While TLVs may be structurally identical, that which they express may
+   be different.  This is determined from the kind (packet, message, or
+   Address Block) and type of the TLV.  For example, one TLV might
+   associate a lifetime to an address, another a content sequence number
+   to a message, and another a cryptographic signature to a packet.  For
+   this reason, [RFC5444] specifies separate registries for Packet TLV
+   Types, Message TLV Types, and Address Block TLV Types, and it does
+   not specify any structure in the TLV Value field.
+
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 4]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+   The TLVs defined in this document express, essentially, that "this
+   information will be refreshed within X seconds" and that "this
+   information is valid for X seconds after being received", each
+   allowing the "X seconds" to be specified as a function of the number
+   of hops from the originator of the information.  This document
+   specifies a general format allowing expressing and encoding this as
+   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,
+   and the offered precision and range is appropriate for MANET routing
+   protocols.
+
+   A TLV of this format may be used for packets, messages, or addresses.
+   For example, a proactive MANET routing protocol periodically
+   reporting link-state information could include a TLV of this format
+   as a Message TLV.  This may indicate a different periodicity in
+   different scopes (possibly frequently up to a few hops, less
+   frequently beyond that) because some messages may be sent with
+   limited scope, as specified in [RFC5444].  A reactive MANET routing
+   protocol could include a TLV of this format as an Address Block TLV
+   for reporting the lifetime of routes to individual addresses.
+
+   In addition to defining the general format as outlined above, this
+   document requests IANA assignments for INTERVAL_TIME and
+   VALIDITY_TIME TLVs.  These IANA assignments are requested in this
+   document in order to avoid interdependencies between otherwise
+   unrelated MANET protocols and in order to not exhaust the TLV Type
+   spaces by having different protocols request types for essentially
+   identical data structures.  Only Message TLVs and Address Block TLVs
+   are requested, as these are those for which a need has been
+   demonstrated.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   Additionally, this document uses terminology from [RFC5444], and
+   introduces the following terminology:
+
+   hop count  - the number of hops from the message originator to the
+      message recipient.  This is defined to equal the <msg-hop-count>
+      field in the <msg-header> element defined in [RFC5444], if
+      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
+      defined to equal 255.
+
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 5]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+   time-value  - a time, measured in seconds.
+
+   time-code  - an 8-bit field, representing a time-value.
+
+3.  Applicability Statement
+
+   The TLV structure described in this document is applicable whenever a
+   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
+   using the generalized MANET packet/message format [RFC5444].
+
+   Examples of time-values that may be included in a protocol message
+   are:
+
+   o  The maximum time interval until the next message of the same type
+      is to be generated by the message's originator node.
+
+   o  The validity time of the information with which the time-value is
+      associated.
+
+   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
+   different hop limits as defined in [RFC5444].
+
+   Parts of this document have been generalized from material in the
+   proactive MANET routing protocol OLSR (Optimized Link State Routing
+   Protocol) [RFC3626].
+
+4.  Protocol Overview and Functioning
+
+   This document does not specify a protocol nor does it mandate
+   specific node or protocol behavior.  Rather, it outlines mechanisms
+   for encoding time-values using the TLV mechanism of [RFC5444].
+
+5.  Representing Time
+
+   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
+   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
+   represent the exponent (b), so that:
+
+   o  time-value := (1 + a/8) * 2^b * C
+
+   o  time-code := 8 * b + a
+
+
+
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 6]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+   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.
+   C MUST be greater than 0 seconds.  Note that ascending values of the
+   time-code represent ascending time-values; time-values may thus be
+   compared by comparison of time-codes.
+
+   An algorithm for computing the time-code representing the smallest
+   representable time-value not less than the time-value t is:
+
+   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
+       integer;
+
+   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
+       can be represented by the time-code 8 * b + a, otherwise it
+       cannot.
+
+   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 *
+   2^28 * C, or about 4.0 * 10^9 * C.  If, for example, C = 1/1024
+   second, then this is about 45 days.
+
+   A protocol using this time representation MUST define the value of C.
+   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
+   all-bits one time-value (255) represents an indefinitely large time-
+   value.
+
+6.  General Time TLV Structure
+
+   The following data structure allows the representation of a single
+   time-value, or of a default time-value plus pairs of (time-values,
+   hop counts) for when hop-count-dependent time-values are required.
+   The time-values are represented as time-codes as defined in
+   Section 5.  This <time-data> data structure is specified, using the
+   regular expression syntax of [RFC5444], by:
+
+       <time-data> = (<time-code><hop-count>)*<time-code>
+
+   where:
+
+   <time-code>  is an 8-bit unsigned integer field containing a time-
+      code as defined in Section 5.
+
+
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 7]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+   <hop-count>  is an 8-bit unsigned integer field specifying a hop
+      count from the message originator.
+
+   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
+   regular expression syntax, it contains 2n+1 octets.  On reception, n
+   is determined from the length.
+
+   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>
+
+   <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
+   originator node, the time-value indicated is that represented by the
+   time-code:
+
+   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
+      that 1 <= i < 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
+   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
+   be used.
+
+6.1.  Single-Value Time TLVs
+
+   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
+   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
+   function of the hop count; thus, different receiving nodes may
+   determine different time-values.
+
+   A single-value Time TLV may be a Packet TLV, a Message TLV, or an
+   Address Block TLV.
+
+   A Time TLV that has the tismultivalue flag cleared ('0') in its <tlv-
+   flags> field, as defined in [RFC5444], contains a single <time-data>,
+   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
+      being the number of (time-value, hop count) pairs in the Time TLV.
+
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 8]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+   o  The number of (time-value, hop count) pairs MUST be identified by
+      inspecting the <length> field in the TLV.  The number of such
+      pairs, n, is:
+
+      *  n := (<length> - 1) / 2
+
+      This MUST be an integer value.
+
+6.2.  Multi-Value Time TLVs
+
+   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
+   described in [RFC5444].  For each of these <time-data> structures, a
+   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
+   originator.  The Time TLV may contain information that allows that
+   time-value to be a function of the hop count, and thus different
+   receiving nodes may determine different time-values.
+
+   Multi-value Time TLVs MUST be Address Block TLVs.  A multi-value Time
+   TLV MUST NOT be a Packet TLV or Message TLV.
+
+   A Time TLV that has the tismultivalue flag set ('1') in its <tlv-
+   flags> field, as defined in [RFC5444], contains a sequence of <time-
+   data> structures, as defined above, in its <value> field.  For such a
+   Time TLV:
+
+   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
+      Time TLV, and m being number-values as defined in [RFC5444].
+
+   o  The number of <time-data> structures included in the <value> field
+      is equal to number-values as defined in [RFC5444].
+
+   o  The number of (time-value, hop count) pairs in each <time-data>
+      structure MUST be the same, and MUST be identified by inspecting
+      the <length> field in the TLV and using number-values as defined
+      in [RFC5444].  The number of such pairs in each <time-data>
+      structure, n, is:
+
+      *  n := ((<length> / number-values) - 1) / 2
+
+      This MUST be an integer value.  The lists of hop count values MAY
+      be different.
+
+
+
+
+
+
+
+Clausen & Dearlove          Standards Track                     [Page 9]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+7.  Message TLVs
+
+   Two Message TLVs are defined, for signaling message interval
+   (INTERVAL_TIME) and message validity time (VALIDITY_TIME).
+
+7.1.  INTERVAL_TIME TLV
+
+   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
+   originator should be received.  This interval time MAY be specified
+   to depend on the hop count from the originator.  (This is appropriate
+   if messages are sent with different hop limits so that receiving
+   nodes at greater hop counts have an increased interval time.)
+
+   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
+   Section 5.
+
+7.2.  VALIDITY_TIME TLV
+
+   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
+   contained.  After this time, the receiving node MUST consider the
+   message content to no longer be valid (unless repeated in a later
+   message).  The validity time of a message MAY be specified to depend
+   on the hop count from its originator.  (This is appropriate if
+   messages are sent with different hop limits so that receiving nodes
+   at greater hop counts receive information less frequently and must
+   treat is as valid for longer.)
+
+   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
+   Section 5.
+
+8.  Address Block TLVs
+
+   Two Address Block TLVs are defined, for signaling address
+   advertisement interval (INTERVAL_TIME) and address validity time
+   (VALIDITY_TIME).
+
+8.1.  INTERVAL_TIME TLV
+
+   An INTERVAL_TIME TLV is an Address Block TLV that defines the maximum
+   time before this address from the same originator should be received
+   again.  This interval time MAY be specified to depend on the hop
+   count from the originator.  (This is appropriate if addresses are
+
+
+
+Clausen & Dearlove          Standards Track                    [Page 10]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+   contained in messages sent with different hop limits so that
+   receiving nodes at greater hop counts have an increased interval
+   time.)
+
+   A protocol using this TLV and the same named Message TLV MUST specify
+   how to interpret the case when both are present (typically, that the
+   former overrides the latter for those addresses that are covered by
+   the former).
+
+   An INTERVAL_TIME TLV is an example of a Time TLV specified as in
+   Section 5.
+
+8.2.  VALIDITY_TIME TLV
+
+   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, the receiving node MUST consider the addresses to no longer be
+   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
+   its originator.  (This is appropriate if addresses are contained in
+   messages sent with different hop limits so that receiving nodes at
+   greater hop counts receive information less frequently and must treat
+   is as valid for longer.)
+
+   A protocol using this TLV and the same named Message TLV MUST specify
+   how to interpret the case when both are present (typically, that the
+   former overrides the latter for those addresses that are covered by
+   the former).
+
+   A VALIDITY_TIME TLV is an example of a Time TLV specified as in
+   Section 5.
+
+9.  IANA Considerations
+
+   This specification defines two Message TLV Types, which have been
+   allocated from the "Assigned Message TLV Types" repository of
+   [RFC5444] as specified in Table 1, and two Address Block TLV Types,
+   which have been allocated from the "Assigned Address Block TLV Types"
+   repository of [RFC5444] as specified in Table 2.
+
+   IANA has assigned the same numerical value to the Message TLV Type
+   and Address Block TLV Type with the same name.
+
+9.1.  Expert Review: Evaluation Guidelines
+
+   For the registries for TLV Type Extensions where an Expert Review is
+   required, the designated expert SHOULD take the same general
+   recommendations into consideration as are specified by [RFC5444].
+
+
+
+Clausen & Dearlove          Standards Track                    [Page 11]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+9.2.  Message TLV Types
+
+   +---------------+------+-----------+--------------------------------+
+   |      Name     | Type |    Type   | Description                    |
+   |               |      | Extension |                                |
+   +---------------+------+-----------+--------------------------------+
+   | INTERVAL_TIME |   0  |     0     | The maximum time before        |
+   |               |      |           | another message of the same    |
+   |               |      |           | type as this message from the  |
+   |               |      |           | same originator should be      |
+   |               |      |           | received                       |
+   |   Unassigned  |   0  |   1-223   | Expert Review                  |
+   |               |      |  224-255  | Experimental Use               |
+   | VALIDITY_TIME |   1  |     0     | The time from receipt of the   |
+   |               |      |           | message during which the       |
+   |               |      |           | information contained in the   |
+   |               |      |           | message is to be considered    |
+   |               |      |           | valid                          |
+   |   Unassigned  |   1  |   1-223   | Expert Review                  |
+   |               |      |  224-255  | Experimental Use               |
+   +---------------+------+-----------+--------------------------------+
+
+                                  Table 1
+
+9.3.  Address Block TLV Types
+
+   +---------------+------+-----------+--------------------------------+
+   |      Name     | Type |    Type   | Description                    |
+   |               |      | extension |                                |
+   +---------------+------+-----------+--------------------------------+
+   | INTERVAL_TIME |   0  |     0     | The maximum time before        |
+   |               |      |           | another message of the same    |
+   |               |      |           | type as this message from the  |
+   |               |      |           | same originator and containing |
+   |               |      |           | this address should be         |
+   |               |      |           | received                       |
+   |   Unassigned  |   0  |   1-223   | Expert Review                  |
+   |               |      |  224-255  | Experimental Use               |
+   | VALIDITY_TIME |   1  |     0     | The time from receipt of the   |
+   |               |      |           | address during which the       |
+   |               |      |           | information regarding this     |
+   |               |      |           | address is to be considered    |
+   |               |      |           | valid                          |
+   |   Unassigned  |   0  |   1-223   | Expert Review                  |
+   |               |      |  224-255  | Experimental Use               |
+   +---------------+------+-----------+--------------------------------+
+
+                                  Table 2
+
+
+
+Clausen & Dearlove          Standards Track                    [Page 12]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+10.  Security Considerations
+
+   This document specifies how to add data structures (TLVs) that
+   provide timing information to packets and messages specified using
+   [RFC5444].  In particular, information validity durations and
+   reporting intervals may be added.
+
+   The general security threats that apply are those general to
+   [RFC5444] and described therein, problems of integrity and
+   confidentiality.  With regard to the former, modification of a Time
+   TLV can cause information to have an invalid validity time, or
+   expected interval time.  This may cause incorrect protocol
+   performance.  Modification or addition of timed information can add
+   to a protocol's workload (especially if a short validity time is
+   specified) and storage requirements (especially if a long validity
+   time is specified).
+
+   To counter these threats, the security suggestions in [RFC5444], for
+   the use of authentication and encryption, are appropriate.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
+              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
+              Format", RFC 5444, February 2009.
+
+11.2.  Informative References
+
+   [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
+              Routing Protocol", RFC 3626, October 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen & Dearlove          Standards Track                    [Page 13]
+
+RFC 5497                        Time TLV                      March 2009
+
+
+Appendix A.  Acknowledgements
+
+   The authors would like to thank Brian Adamson and Justin Dean (both
+   NRL) and Ian Chakeres (Motorola) for their contributions, and Alan
+   Cullen (BAE Systems) and Jari Arkko (Ericsson, Finland) for their
+   careful reviews of this specification.
+
+Authors' Addresses
+
+   Thomas Heide Clausen
+   LIX, Ecole Polytechnique, France
+
+   Phone: +33 6 6058 9349
+   EMail: T.Clausen@computer.org
+   URI:   http://www.ThomasClausen.org/
+
+
+   Christopher Dearlove
+   BAE Systems Advanced Technology Centre
+
+   Phone: +44 1245 242194
+   EMail: chris.dearlove@baesystems.com
+   URI:   http://www.baesystems.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen & Dearlove          Standards Track                    [Page 14]
+