Mobile Ad hoc Networking (MANET)                              T. Clausen
Internet-Draft                          LIX, Ecole Polytechnique, France
Expires: August 12, 2007                                     C. Dearlove
                                         BAE Systems Advanced Technology
                                                                  Centre
                                                        February 8, 2007


                Representing multi-value time in MANETs
                     draft-clausen-manet-timetlv-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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
   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 12, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Clausen & Dearlove       Expires August 12, 2007                [Page 1]

Internet-Draft                  Time TLV                   February 2007


Abstract

   This document describes a general and flexible TLV (type-length-value
   structure) for representing time using the generalized MANET packet/
   message format.  It defines two message TLVs for representing
   validity and interval times for MANET routing protocols.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  6
   5.  Representing Time  . . . . . . . . . . . . . . . . . . . . . .  7
   6.  General Time TLV Structure . . . . . . . . . . . . . . . . . .  8
   7.  Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  VALIDITY_TIME TLV  . . . . . . . . . . . . . . . . . . . . 10
     7.2.  INTERVAL_TIME TLV  . . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16
























Clausen & Dearlove       Expires August 12, 2007                [Page 2]

Internet-Draft                  Time TLV                   February 2007


1.  Introduction

   The generalized packet/message format [1] specifies a signaling
   format which 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 value associated
   with a range of distances.  This allows a receiving node to determine
   a single time value if either it knows its distance from the
   originator node, which [1] may provide, or the Time TLV specifies a
   single time value.

   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.



























Clausen & Dearlove       Expires August 12, 2007                [Page 3]

Internet-Draft                  Time TLV                   February 2007


2.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [2].

   Additionally, this document uses terminology from [1], and introduces
   the following terminology:

   Distance  - the number of hops from the message originator to the
      message recipient, as may be indicated using the <hop-count> field
      in the full message header defined in [1], after being incremented
      on reception.

   Time Value  - a time, measured in seconds.

   Time Code  - an 8 bit field, representing a time value.


































Clausen & Dearlove       Expires August 12, 2007                [Page 4]

Internet-Draft                  Time TLV                   February 2007


3.  Applicability Statement

   The TLV described in this document is applicable whenever a single
   time value, or a time value that varies with distance from the
   originator of a message, is required in a protocol using the
   generalized MANET packet/message format [1].

   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 distance between the originating
   and receiving nodes if messages of the same type are sent with
   different hop limits as defined in [1].  Note that if using [1], then
   distance information is available as the hop count field in a full
   message header (after being incremented).

   Parts of this document have been generalized from material in the
   proactive MANET routing protocol OLSR (The Optimized Link State
   Routing Protocol) [3].


























Clausen & Dearlove       Expires August 12, 2007                [Page 5]

Internet-Draft                  Time TLV                   February 2007


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 [1].  Protocols
   using the mechanisms and TLVs specified in this document must ensure
   that they do so in a coherent way.












































Clausen & Dearlove       Expires August 12, 2007                [Page 6]

Internet-Draft                  Time TLV                   February 2007


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 four
   bits represent the mantissa (a), and the most significant four bits
   represent the exponent (b), so that:

   o  time value = (1 + a/16) * 2^b * C

   o  time code = 16 * b + a

   All nodes in the network MUST use the same value of C, which will be
   specified in seconds, hence so will be all time values.  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 = 16 * (t / (C * 2^b) - 1), rounded up to the nearest
       integer;

   3.  if a == 16 then set b = b + 1 and set a = 0;

   4.  if a and b are in the range 0 and 15 then the required time value
       can be represented by the time code 16 * b + a, otherwise it can
       not.

   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
   63488 * C.

















Clausen & Dearlove       Expires August 12, 2007                [Page 7]

Internet-Draft                  Time TLV                   February 2007


6.  General Time TLV Structure

   A Time TLV may be a packet, message or address block TLV.  If it is a
   packet or message TLV then it must be a single value TLV as defined
   in [1]; if it is an address block TLV then it may be single value or
   multivalue TLV.  The specific Time TLVs specified in this document,
   in Section 7 are message, and hence single value, TLVs.  Note that
   even a single value Time TLV may contain a multiple octet <value>
   field.

   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 distance from the entity's originator.  The
   Time TLV may contain information that allows that time value to be a
   function of distance, and thus different receiving nodes may
   determine different time values.  If a receiving node will not be
   able to determine its distance from the originating node, then the
   form of this Time TLV with a single time code in a <value> field (or
   single value subfield) SHOULD be used.

   The <value> field of a single value Time TLV is specified, using the
   regular expression syntax of [1], by:

       <value> = {<time><distance>}*<time>

   where:

   <time>  is an 8 bit field containing a time code as defined in
      Section 5.

   <distance>  is an 8 bit field specifying a distance from the message
      originator, in hops.

   A single value <value> field thus consists of an odd number of
   octets; with a repetition factor of n in the regular expression
   syntax it contains 2n+1 octets, thus the <length> field of a single
   value Time TLV, which MUST always be present, is given by:

   o  <length> = 2n+1

   A single value <value> 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.
   Then, at the receiving node's distance from the originator node, the
   time value indicated is that represented by the time code:




Clausen & Dearlove       Expires August 12, 2007                [Page 8]

Internet-Draft                  Time TLV                   February 2007


   o  <t_1>, if n > 0 and distance <= <d_1>;

   o  <t_i+1>, if n > 1 and <d_i> < distance <= <d_i+1> for some i such
      that 1 <= i < n;

   o  <t_default> otherwise, i.e. if n == 0 or distance > <d_n>.

   In a multivalue Time TLV, each single value subfield of the
   multivalue Time TLV is defined as above.  Note that [1] requires that
   each single value subfield has the same length (i.e. the same value
   of n) but they need not use the same values of <d_1> to <d_n>.








































Clausen & Dearlove       Expires August 12, 2007                [Page 9]

Internet-Draft                  Time TLV                   February 2007


7.  Message TLVs

   Two message TLVs are defined, for signaling message validity time
   (VALIDITY_TIME) and message interval (INTERVAL_TIME).

7.1.  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 distance from its originator.  (This is appropriate if
   messages are sent with different hop limits, so that receiving nodes
   at greater distances receive information less frequently and must
   treat is as valid for longer.)

   A VALIDITY_TIME TLV is an example of a Time TLV specified as in
   Section 5.

7.2.  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 distance from the originator.  (This is appropriate
   if messages are sent with different hop limits, so that receiving
   nodes at greater distances have an increased interval time.)

   An INTERVAL_TIME TLV is an example of a Time TLV specified as in
   Section 5.




















Clausen & Dearlove       Expires August 12, 2007               [Page 10]

Internet-Draft                  Time TLV                   February 2007


8.  IANA Considerations

   This specification defines two message TLV types, which must be
   allocated from the "Assigned Message TLV Types" repository of [1].

   +--------------------+-------+--------------------------------------+
   |      Mnemonic      | Value | Description                          |
   +--------------------+-------+--------------------------------------+
   |    VALIDITY_TIME   |  TBD  | The time from receipt of the message |
   |                    |       | during which the information         |
   |                    |       | contained in the message is to be    |
   |                    |       | considered valid                     |
   |                    |       |                                      |
   |    INTERVAL_TIME   |  TBD  | The maximum time before another      |
   |                    |       | message of the same type as this     |
   |                    |       | message from the same originator     |
   |                    |       | should be received                   |
   +--------------------+-------+--------------------------------------+

                                  Table 1































Clausen & Dearlove       Expires August 12, 2007               [Page 11]

Internet-Draft                  Time TLV                   February 2007


9.  Security Considerations

   This document does not specify any security considerations.
















































Clausen & Dearlove       Expires August 12, 2007               [Page 12]

Internet-Draft                  Time TLV                   February 2007


10.  References

10.1.  Normative References

   [1]  Clausen, T., Dean, J., Dearlove, C., and C. Adjih, "Generalized
        MANET Packet/Message Format", Work In
        Progress draft-ietf-manet-packetbb-03.txt, June 2006.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

10.2.  Informative References

   [3]  Clausen, T. and P. Jacquet, "The Optimized Link State Routing
        Protocol", RFC 3626, October 2003.




































Clausen & Dearlove       Expires August 12, 2007               [Page 13]

Internet-Draft                  Time TLV                   February 2007


Appendix A.  Acknowledgements

   The authors would like to thank Brian Adamson and Justin Dean (both
   NRL) for their contributions.















































Clausen & Dearlove       Expires August 12, 2007               [Page 14]

Internet-Draft                  Time TLV                   February 2007


Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique, France

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/


   Christopher M. Dearlove
   BAE Systems Advanced Technology Centre

   Phone: +44 1245 242194
   Email: chris.dearlove@baesystems.com
   URI:   http://www.baesystems.com/ocs/sharedservices/atc/



































Clausen & Dearlove       Expires August 12, 2007               [Page 15]

Internet-Draft                  Time TLV                   February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Clausen & Dearlove       Expires August 12, 2007               [Page 16]