Skip to main content

Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
draft-ietf-manet-nhdp-olsrv2-tlv-extension-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7188.
Authors Christopher Dearlove , Thomas H. Clausen
Last updated 2014-03-03 (Latest revision 2014-02-24)
Replaces draft-dearlove-manet-nhdp-olsrv2-tlv-extension
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Ulrich Herberg
Shepherd write-up Show Last changed 2014-01-07
IESG IESG state Became RFC 7188 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Adrian Farrel
Send notices to manet-chairs@tools.ietf.org, draft-ietf-manet-nhdp-olsrv2-tlv-extension@tools.ietf.org
IANA IANA review state IANA - Not OK
draft-ietf-manet-nhdp-olsrv2-tlv-extension-03
Mobile Ad hoc Networking (MANET)                             C. Dearlove
Internet-Draft                                           BAE Systems ATC
Updates: RFC6130, OLSRv2                                      T. Clausen
(if approved)                                   LIX, Ecole Polytechnique
Intended status: Standards Track                       February 24, 2014
Expires: August 28, 2014

   Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET
         Neighborhood Discovery Protocol (NHDP) Extension TLVs
             draft-ietf-manet-nhdp-olsrv2-tlv-extension-03

Abstract

   This specification describes extensions to definitions of TLVs used
   by the Optimized Link State Routing Protocol version 2 (OLSRv2) and
   the MANET Neighborhood Discovery Protocol (NHDP), to increase their
   abilities to accommodate protocol extensions.  This document updates
   OLSRv2 and RFC6130.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 28, 2014.

Copyright Notice

   Copyright (c) 2014 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Dearlove & Clausen       Expires August 28, 2014                [Page 1]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  3
   4.  TLV Values . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Unrecognized TLV Values  . . . . . . . . . . . . . . . . .  4
     4.2.  TLV Value Lengths  . . . . . . . . . . . . . . . . . . . .  5
     4.3.  Undefined TLV Values . . . . . . . . . . . . . . . . . . .  5
       4.3.1.  NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB  . .  6
       4.3.2.  OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . .  6
       4.3.3.  Unspecified TLV Values . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Address Block TLVs . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Dearlove & Clausen       Expires August 28, 2014                [Page 2]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

1.  Introduction

   The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
   Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2]
   are protocols for use in mobile ad hoc networks (MANETs) [RFC2501],
   based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message
   Format [RFC5444].

   This document updates [RFC6130] and [OLSRv2], specifically their use
   of TLV (Type-Length-Value) elements, to increase the extensibility of
   these protocols, and to enable some improvements in their
   implementation.

   This specification reduces the latitude of implementations of
   [OLSRv2] and [RFC6130] to consider some messages, which will not be
   created by implementations simply following those specifications, as
   a reason to consider the message as "badly formed", and thus as a
   reason to reject the message.  This gives greater latitude to the
   creation of extensions of these protocols, in particular extensions
   that will interoperate with unextended implementations of those
   protocols.  As part of that, it indicates how TLVs (Type-Length-Value
   elements) [RFC5444] with unexpected value fields must be handled, and
   adds some additional options to those TLVs.

   Note that TLVs with unknown type or type extension are already
   specified as to be ignored by [RFC6130] and [OLSRv2], and also are
   not a reason to reject a message.

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 the terminology of [RFC5444],
   [RFC6130], and [OLSRv2].

3.  Applicability Statement

   This document updates the specification of the protocols [OLSRv2] and
   [RFC6130].

   Specifically, this specification updates [RFC6130] and [OLSRv2] in
   the following way:

Dearlove & Clausen       Expires August 28, 2014                [Page 3]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

   o  Removes the latitude of rejecting a message with a TLV with a
      known type, but with an unexpected TLV Value field, for the TLV
      Types defined in [RFC6130] and [OLSRv2].

   o  Specifies the handling of a TLV Value field with unexpected
      length.

   o  Sets up IANA registries for TLV Values for the Address Block TLVs:

      *  LOCAL_IF, defined in [RFC6130].

      *  LINK_STATUS, defined in [RFC6130].

      *  OTHER_NEIGHB, defined in [RFC6130].

      *  MPR, defined in [OLSRv2], now considered as a bit field.

      *  NBR_ADDR_TYPE, defined in [OLSRv2], now considered as a bit
         field.

   o  Defines a well-known TLV Value for "UNSPECIFIED" for the Address
      Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all
      defined in [RFC6130].

4.  TLV Values

   NHDP [RFC6130] and OLSRv2 [OLSRv2] define a number of TLVs within the
   framework of [RFC5444].  These TLVs define the meaning of only some
   of the contents that can be found in a TLV Value field.  This
   limitation may be either only defining certain TLV Values, or
   considering only some lengths of the TLV Value fields (or single
   value field in a multi value Address-Block TLV).  This specification
   describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] are to handle TLVs
   with other TLV Value fields.

4.1.  Unrecognized TLV Values

   NHDP and OLSRv2 specify that, in addition to well-defined reasons (in
   the respective protocol specifications), an implementation of these
   protocols MAY recognize a message as "badly formed" and therefore
   "invalid for processing" for other reasons (Section 12.1 of [RFC6130]
   and Section 16.3.1 of [OLSRv2]).  These sections could be interpreted
   as allowing rejection of a message because a TLV Value field is
   unrecognized.  This specification removes that latitude:

   o  An implementation MUST NOT reject a message because it contains an
      unrecognized TLV value.  Instead, any unrecognised TLV Value field

Dearlove & Clausen       Expires August 28, 2014                [Page 4]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

      MUST be processed or ignored by an unextended implementation of
      NHDP or OLSRv2, as described in the following sections.

   It should be stressed that this is not a change to [RFC6130] or
   [OLSRv2], except with regard to not allowing this to be a reason for
   rejection of a message.  [RFC6130] or [OLSRv2] are specified in terms
   such as "if an address is associated with a value of LOST by a
   LINK_STATUS TLV".  Association with an unrecognized value has no
   effect on any implementation strictly following such a specification.

4.2.  TLV Value Lengths

   The TLVs specified in [RFC6130] and [OLSRv2] may be either single-
   value or multi-value TLVs.  In either case, the length of each item
   of information encoded in the TLV Value field is the "single-length",
   defined and calculated as in section 5.4.1 in [RFC5444].  All TLVs
   specified in [RFC6130] and [OLSRv2] have a one or two octet single-
   length.  These are considered the expected single-lengths of such a
   received TLV.

   Other single-length TLV Value fields may be introduced by extensions
   to [RFC6130] and [OLSRv2].  This document specifies how
   implementations of [RFC6130] and [OLSRv2], or extensions thereof,
   MUST behave on receiving TLVs of the TLV types defined in [RFC6130]
   and [OLSRv2], but with TLV Value fields with other single-length
   values.

   The following principles apply:

   o  If the received single-length is greater than the expected single-
      length, then the excess octets MUST be ignored.

   o  If the received single-length is less than the expected single-
      length, then the absent octets MUST considered to have all bits
      cleared (0).

   Exceptions:

   o  A received CONT_SEQ_NUM with a single-length < 2 SHOULD be
      considered an error.

4.3.  Undefined TLV Values

   [RFC6130] and [OLSRv2] define a number of TLVs, but for some of these
   TLVs specify meanings for only some TLV Values.  This document
   establishes IANA registries for these TLV Values, with initial
   registrations reflecting those used by [RFC6130] and [OLSRv2], and as
   specified in Section 4.3.3.

Dearlove & Clausen       Expires August 28, 2014                [Page 5]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

   There are different cases of TLV Values with different
   characteristics.  These cases are considered in this section.

4.3.1.  NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB

   For the Address-Block TLVs LOCAL_IF, LINK_STATUS and OTHER_NEIGHB
   TLVs, defined in [RFC6130], only a limited number of values are
   specified for each.  These are converted, by this specification, into
   extensible registries with initial registrations for values defined
   and used by [RFC6130] - see Section 5.

   An implementation of [RFC6130], receiving a LOCAL_IF, LINK_STATUS, or
   OTHER_NEIGHB TLV with any TLV Value other than the values which are
   defined in [RFC6130] MUST ignore that TLV Value, as well as any
   corresponding attribute association to the address.

4.3.2.  OLSRv2 TLVs: MPR and NBR_ADDR_TYPE

   The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [OLSRv2],
   are similar to those defined in [RFC6130] in having only limited
   values specified (1, 2 and 3): 1 and 2, represent presence of two
   different attributes associated to an address, and 3 represents "both
   1 and 2".

   These TLV Value fields, are by this specification, converted to bit
   fields, and MUST be interpreted as such.  As the existing definitions
   of values 1, 2, and 3 behave in that manner, it is likely that this
   will involve no change to an implementation, but any test of (for
   example) Value = 1 or Value = 3 MUST be converted to a test of (for
   example) Value bitand 1 = 1, where "bitand" denotes a bitwise and
   operation.

   This specification creates registries for recording reservations of
   the individual bits in these bitfields, with initial registrations
   for values defined and used by [OLSRv2] - see Section 5.

   Other TLVs defined by [OLSRv2] are not affected by this
   specification.

4.3.3.  Unspecified TLV Values

   The registries defined in Section 5 for the LOCAL_IF, LINK_STATUS and
   OTHER_NEIGHB TLVs each include an additional TLV Value UNSPECIFIED.
   This TLV Value represents a defined value that, like currently
   undefined TLV Values, indicates that no information is associated
   with this address, but will always have this meaning.  Such a TLV
   Value may be used to enable the creation of more efficient multivalue
   Address Block TLVs, or to simplify an implementation.

Dearlove & Clausen       Expires August 28, 2014                [Page 6]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

   The similar requirement for the MPR and NBR_ADDR_TYPES TLVs is
   already satisfied by the TLV Value zero, provided that each bit in
   the TLV Value is defined as set ('1') when indicating the presence of
   an attribute, or clear ('0') when indicating the absence of an
   attribute; this is therefore required for registrations from the
   relevant registries, see Section 5.

   For the LINK_METRIC TLV, this is already possible by clearing the
   most significant bits (0 to 3) of the first octet of the TLV Value.
   It is RECOMMENDED that in this case the remaining bits of the TLV
   Value are either all clear ('0') or all set ('1').

5.  IANA Considerations

   Note: Values defined as "Unallocated: Expert Review" mean that these
   values may be allocated according to the expert review guidelines
   specified in [RFC6130] and [OLSRv2].  In two cases a constraint on
   future allocation is specified.  IANA tables referenced are from
   "Mobile Ad hoc NETwork (MANET) Parameters".

5.1.  Address Block TLVs

   IANA is requested to create a registry associated with the Address
   Block TLV with name LOCAL_IF (Type = 2, Type Extension = 0) defined
   in [RFC6130], specifying the meaning of its single values.  This
   replaces the Description column in IANA table "LOCAL_IF Address Block
   TLV Type Extensions" (from Table 6 in [RFC6130]) by a reference to
   this table.

   +---------+-------------+-------------------------------------------+
   |  Value  |     Name    |                Description                |
   +---------+-------------+-------------------------------------------+
   |    0    |   THIS_IF   |   The network address is associated with  |
   |         |             |    this local interface of the sending    |
   |         |             |                   router                  |
   |    1    |   OTHER_IF  |   The network address is associated with  |
   |         |             |   another local interface of the sending  |
   |         |             |                   router                  |
   |  2-223  |             |         Unallocated: Expert Review        |
   | 224-254 |             |              Experimental Use             |
   |   255   | UNSPECIFIED | No information about this network address |
   |         |             |                is provided                |
   +---------+-------------+-------------------------------------------+

                       Table 1: LOCAL_IF TLV Values

   IANA is requested to create a registry associated with the Address

Dearlove & Clausen       Expires August 28, 2014                [Page 7]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

   Block TLV with name LINK_STATUS (Type = 3, Type Extension = 0)
   defined in [RFC6130], specifying the meaning of its single values.
   This replaces the Description column in the IANA table "LINK_STATUS
   Address Block TLV Type Extensions" (from Table 7 in [RFC6130]) by a
   reference to this table.

   +---------+-------------+-------------------------------------------+
   |  Value  |     Name    |                Description                |
   +---------+-------------+-------------------------------------------+
   |    0    |     LOST    |    The link on this interface from the    |
   |         |             | router with that network address has been |
   |         |             |                    lost                   |
   |    1    |  SYMMETRIC  |    The link on this interface from the    |
   |         |             |  router with that network address has the |
   |         |             |            status of symmetric            |
   |    2    |    HEARD    |    The link on this interface from the    |
   |         |             |  router with that network address has the |
   |         |             |              status of heard              |
   |  3-223  |             |         Unallocated: Expert Review        |
   | 224-254 |             |              Experimental Use             |
   |   255   | UNSPECIFIED | No information about this network address |
   |         |             |                is provided                |
   +---------+-------------+-------------------------------------------+

                      Table 2: LINK_STATUS TLV Values

   IANA is requested to create a registry associated with the Address
   Block TLV with name OTHER_NEIGHB (Type = 4, Type Extension = 0)
   defined in [RFC6130], specifying the meaning of its single values.
   This replaces the Description column in Table 8 in the IANA table
   "OTHER_NEIGHB Address Block TLV Type Extensions" (from [RFC6130]) by
   a reference to this table.

   +---------+-------------+-------------------------------------------+
   |  Value  |     Name    |                Description                |
   +---------+-------------+-------------------------------------------+
   |    0    |     LOST    | The neighbor relationship with the router |
   |         |             |  with that network address has been lost  |
   |    1    |  SYMMETRIC  | The neighbor relationship with the router |
   |         |             |   with that network address is symmetric  |
   |  2-223  |             |         Unallocated: Expert Review        |
   | 224-254 |             |              Experimental Use             |
   |   255   | UNSPECIFIED | No information about this network address |
   |         |             |                is provided                |
   +---------+-------------+-------------------------------------------+

                     Table 3: OTHER_NEIGHB TLV Values

Dearlove & Clausen       Expires August 28, 2014                [Page 8]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

   IANA is requested to create a registry associated with the Address
   Block TLV with name MPR (Type = 8, Type Extension = 0) defined in
   [OLSRv2], specifying the meaning of its single values in terms of the
   values of each bit of the value, from bit 0 (most significant) to bit
   7 (least significant).  If multiple bits are set then each applies.
   This replaces the Description column in the (not yet created) IANA
   table "MPR Address Block TLV Type Extensions" (from Table 14 in
   [OLSRv2]) by a reference to this table.

   +-------+-------+----------+----------------------------------------+
   | Value | Value |   Name   |               Description              |
   |  Bit  |       |          |                                        |
   +-------+-------+----------+----------------------------------------+
   |   7   |   1   | FLOODING | The neighbor with that network address |
   |       |       |          |    has been selected as flooding MPR   |
   |   6   |   2   |  ROUTING | The neighbor with that network address |
   |       |       |          |    has been selected as routing MPR    |
   |  0-5  |       |          |       Unallocated: Expert Review       |
   +-------+-------+----------+----------------------------------------+

                        Table 4: MPR TLV Bit Values

   Note that this registry maintains a bit field, and that the
   combination of the bits FLOODING + ROUTING being set (1) (which gives
   a value of 3) is given the name FLOOD_ROUTE in [OLSRv2].  For each
   bit in the field, a set bit (1) means that the address has the
   designated property, while an unset bit (0) means that no information
   about the designated property is provided.  For future allocations,
   the Designated Expert has to ensure that this sense is preserved,
   and, in particular, an unset bit MUST NOT be used to convey any
   specific information about the designated property.

Dearlove & Clausen       Expires August 28, 2014                [Page 9]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

   IANA is requested to create a registry associated with the Address
   Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0)
   defined in [OLSRv2], specifying the meaning of its single values in
   terms of the values of each bit of the value, from bit 0 (most
   significant) to bit 7 (least significant).  If multiple bits are set
   then each applies.  This replaces the Description column in the (not
   yet created) IANA table "NBR_ADDR_TYPE Address Block TLV Type
   Extensions" (from Table 15 in [OLSRv2]) by a reference to this table.

   +-------+-------+------------+--------------------------------------+
   | Value | Value |    Name    |              Description             |
   |  Bit  |       |            |                                      |
   +-------+-------+------------+--------------------------------------+
   |   7   |   1   | ORIGINATOR | The network address is an originator |
   |       |       |            |       address reachable via the      |
   |       |       |            |          originating router          |
   |   6   |   2   |  ROUTABLE  |   The network address is a routable  |
   |       |       |            |       address reachable via the      |
   |       |       |            |          originating router          |
   |  0-5  |       |            |      Unallocated: Expert Review      |
   +-------+-------+------------+--------------------------------------+

                   Table 5: NBR_ADDR_TYPE TLV Bit Values

   Note that this registry maintains a bit field, and that the
   combination of the bits ORIGINATOR + ROUTABLE being set (1) (which
   gives a value of 3) is given the name ROUTABLE_ORIG in [OLSRv2].  For
   each bit in the field, a set bit (1) means that the address has the
   designated property, while an unset bit (0) means that no information
   about the designated property is provided.  For future allocations,
   the Designated Expert has to ensure that this sense is preserved,
   and, in particular, an unset bit MUST NOT be used to convey any
   specific information about the designated property.

6.  Security Considerations

   The presented updates to [RFC6130] and [OLSRv2]:

   o  Create IANA registries for retaining TLV values for TLVs, already
      defined in the already published specifications of the two
      protocols, and with initial registrations for the TLV values
      defined by these specifications.  This does not give rise to any
      additional security considerations.

   o  Enable protocol extensions to be able to register TLV values in
      the created IANA registries.  Such extensions MUST specify
      appropriate security considerations.

Dearlove & Clausen       Expires August 28, 2014               [Page 10]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

   o  Create, in some registries, a registration for "UNSPECIFIED"
      values, for more efficient use of multi-value Address Block TLVs.
      The interpretation of an address being associated with a TLV of a
      given type and with the value "UNSPECIFIED" is identical to that
      address not being associated with a TLV of that type.  Thus, this
      update does not give rise to any additional security
      considerations.

   o  Reduces the latitude of implementations of the two protocols to
      reject a message as "badly formed", due to the value field of a
      TLV being unexpected.  These protocols are specified in terms such
      as "if an address is associated with a value of LOST by a
      LINK_STATUS TLV".  Association with an unknown value (or a value
      newly defined to mean no link status information) has no effect on
      such a specification.  Thus, this update does not give rise to any
      additional security considerations.

   o  Do not introduce any opportunities for attacks on the protocols
      through signal modification that are not already present in the
      two protocols.

7.  Acknowledgments

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews, and comments on the
   specification (listed alphabetically): Ulrich Herberg (Fujitsu
   Laboratories of America) and Henning Rogge (Frauenhofer FKIE).

8.  References

8.1.  Normative References

   [OLSRv2]   Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol version 2",
              work in progress draft-ietf-manet-olsrv2-19, March 2013.

   [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 MANET Packet/Message Format", RFC 5444,
              February 2009.

   [RFC6130]  Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

Dearlove & Clausen       Expires August 28, 2014               [Page 11]
Internet-Draft       NHDP and OLSRv2 Extension TLVs        February 2014

8.2.  Informative References

   [RFC2501]  Macker, J. and S. Corson, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501, January 1999.

Authors' Addresses

   Christopher Dearlove
   BAE Systems Advanced Technology Centre
   West Hanningfield Road
   Great Baddow, Chelmsford
   United Kingdom

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

   Thomas Heide Clausen
   LIX, Ecole Polytechnique

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/

Dearlove & Clausen       Expires August 28, 2014               [Page 12]