[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-dt-roll-p2p-rpl) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 6997

Internet Engineering Task Force                            M. Goyal, Ed.
Internet-Draft                                   University of Wisconsin
Intended status: Experimental                                  Milwaukee
Expires: May 17, 2012                                        E. Baccelli
                                                              M. Philipp
                                                                   INRIA
                                                               A. Brandt
                                                           Sigma Designs
                                                             J. Martocci
                                                        Johnson Controls
                                                       November 14, 2011


   Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
                                Networks
                       draft-ietf-roll-p2p-rpl-05

Abstract

   This document specifies a route discovery mechanism, complementary to
   the RPL base functionality.  This mechanism allows an IPv6 router to
   discover and establish, on demand, a route to another IPv6 router in
   the LLN such that the discovered route meets specified metrics
   constraints, without necessarily going along the DAG links
   established by basic RPL.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 May 17, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Goyal, et al.             Expires May 17, 2012                  [Page 1]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   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
   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.  The Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Functional Overview  . . . . . . . . . . . . . . . . . . . . .  5
   6.  The Route Discovery Option (RDO) . . . . . . . . . . . . . . .  7
     6.1.  Setting a DIO Carrying a Route Discovery Option  . . . . . 10
   7.  The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 11
     7.1.  Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.2.  Setting an RDO Carried in a Discovery Reply Object . . . . 13
   8.  P2P Route Discovery By Creating a Temporary DAG  . . . . . . . 14
     8.1.  Joining a Temporary DAG  . . . . . . . . . . . . . . . . . 14
     8.2.  Trickle Operation For DIOs Carrying a Route Discovery
           Option . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.3.  Processing a DIO Carrying a Route Discovery Option . . . . 15
     8.4.  Additional Processing of a DIO Carrying a Route
           Discovery Option At An Intermediate Router . . . . . . . . 16
     8.5.  Additional Processing of a DIO Carrying a Route
           Discovery Option At The Target . . . . . . . . . . . . . . 16
     8.6.  Processing a DRO At An Intermediate Router . . . . . . . . 17
     8.7.  Processing a DRO At The Origin . . . . . . . . . . . . . . 18
   9.  The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 19
   10. Packet Forwarding Along a P2P Route  . . . . . . . . . . . . . 20
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Additions to RPL Control Codes . . . . . . . . . . . . . . 21
     12.2. Additions to RPL Control Message Options . . . . . . . . . 21
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     14.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23






Goyal, et al.             Expires May 17, 2012                  [Page 2]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


1.  Introduction

   Targeting Low power and Lossy Networks (LLNs), the RPL routing
   protocol [I-D.ietf-roll-rpl] provides paths along a Directed Acyclic
   Graph (DAG) rooted at a single router in the network: the sink.
   Establishment and maintenance of the DAG is performed by each router
   in the LLN using specific link-local multicast signalling (DIO
   messages).

   When two arbitrary routers (none of which being the sink) need to
   communicate, basic RPL provides dog-legged paths along DAG links,
   which may not be efficient enough for several Home and Building
   Automation applications [RFC5826][RFC5867], for the following reasons
   [I-D.brandt-roll-rpl-applicability-home-building]:

   o  The need to preprovision routes: each potential destination in the
      network must declare itself as such, via specific additional
      signalling (DAO messages).

   o  The need to route along DAG links: depending on the network
      topology and metrics in use, the constraint to route along a DAG
      may cause significantly suboptimal P2P routes and severe traffic
      congestion near the DAG root.

   This document thus describes a mechanism complementary to the basic
   RPL functionality, enabling source-initiated, on-demand discovery of
   a route between arbitrary routers in the LLN, such that the
   discovered route meets specified metrics constraints, without
   necessarily going along an existing DAG.  Hereafter, such routes are
   called point-to-point (P2P) routes.  The specified mechanism allows
   for the discovery of source routes as well as hop-by-hop routes.
   Discovered routes may not be the best available but are guaranteed to
   satisfy the desired constraints in terms of the routing metrics and
   are thus considered "good enough" from the application's perspective.

   A complementary functionality helping to decide whether or not to
   initiate a route discovery, is a mechanism measuring the end-to-end
   cost of an existing route.  Section 4 provides further details on how
   such functionality, specified in [I-D.ietf-roll-p2p-measurement], is
   used to determine the value of metric constraints parameters in the
   route discovery mechanism described in this document.


2.  The Use Cases

   The mechanism described in this document is intended to be employed
   as complementary to RPL in specific scenarios that need P2P paths
   between arbitrary routers.



Goyal, et al.             Expires May 17, 2012                  [Page 3]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   One use case, common in a home environment, involves a remote control
   (or a motion sensor) that suddenly needs to communicate with a lamp
   module, whose network address is a-priori known.  In this case, the
   source of data (the remote control or the motion sensor) must be able
   to discover a route to the destination (the lamp module) "on demand".

   Another use case, common in a large commercial building environment,
   involves a large LLN deployment where P2P communication along a
   particular DAG among hundreds (or thousands) of routers creates
   severe traffic congestion near that DAG's root, and thus routes
   across this DAG are desirable.

   The use cases also include scenarios where energy or latency
   constraints are not satisfied by P2P routes provided by basic RPL
   along a DAG because they involve traversing many more intermediate
   routers than necessary to reach the destination.


3.  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
   [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl].  This document
   introduces the following terms:

   Origin : The RPL node initiating the route discovery.

   Target : The RPL node at the other end point of the route(s) to be
   discovered.

   Intermediate Router: An RPL router that is neither the origin nor the
   target.

   Forward Route: A route in the forward direction, i.e., from the
   origin to the target.

   Backward Route: A route in the backward direction, i.e., from the
   target to the origin.

   Bidirectional Route: A route that can be used in both forward and
   backward directions.

   Source Route: A complete and ordered list of routers that can be used
   by a packet to travel from a source to a destination node.



Goyal, et al.             Expires May 17, 2012                  [Page 4]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   Hop-by-hop Route: The route characterized by each router on the route
   using its routing table to determine the next hop on the route.


4.  Applicability

   The route discovery mechanism, described in this document, may be
   invoked by an origin when no route exists between itself and the
   target or when the existing routes do not satisfy the desired
   performance requirements.  The mechanism is designed to discover and
   establish one hop-by-hop route or discover one or more source routes
   such that the discovered route(s) meet the specified constraints.  In
   some application contexts, the constraints that the discovered
   route(s) must satisfy are intrinsically known or can be specified by
   the application.  For example, an origin that expects a target to be
   less than 5 hops away may use "hop-count < 5" as the constraint.  In
   other application contexts, the origin may need to measure the cost
   of an existing route to the target to determine the constraints.  For
   example, an origin that measures the total ETX of its along-DAG route
   to the target to be 20 may use "ETX < x*20", where x is a fraction
   that the origin decides, as the constraint.  A mechanism measuring
   the cost of an existing route between the origin and the target is
   specified in [I-D.ietf-roll-p2p-measurement].  If there is no
   existing route between the origin and target or the cost measurement
   for the existing route fails, the origin will have to guess the
   constraints used in the initial route discovery.  Once, the initial
   route discovery succeeds or fails, the origin will have a better
   estimate for the constraints to be used in the subsequent route
   discovery.

   This document describes an on-demand discovery mechanism for P2P
   routes that is complementary to the proactive routes offered by RPL
   base functionality.  The mechanism described in this document may
   result in discovery of better P2P routes than the ones available
   along a DAG designed to optimize routing cost to the DAG's root.  The
   improvement in route quality depends on a number of factors including
   the network topology, the routing metrics in use and the prevalent
   conditions in the network.  A network designer may take in
   consideration both the benefits (potentially better routes; no need
   to maintain routes proactively) and costs (control messages generated
   during the route discovery process) when using this mechanism.


5.  Functional Overview

   This section contains a high level description of P2P-RPL, the route
   discovery mechanism specified in this document.




Goyal, et al.             Expires May 17, 2012                  [Page 5]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   Similarly to basic RPL, P2P-RPL uses IPv6 link-local multicasted DIO
   messages to establish a DAG (maintained temporarily).  Each router
   joining the DAG determines a rank for itself in the DAG and ignores
   the subsequent DIO messages received from lower (higher in numerical
   value) ranked neighbors.  Thus, the DIO messages propagate outward
   from the DAG root rather than return inward towards the DAG root.  As
   basic RPL, DIO message generation at a router is further controlled
   by a Trickle timer that allows a router to avoid generating
   unnecessary messages [RFC6206].  P2P-RPL also uses the routing
   metrics, objective function [I-D.ietf-roll-routing-metrics] and
   packet forwarding framework developed for basic RPL.

   The P2P route discovery takes place by forming a temporary DAG rooted
   at the origin.  The DIOs used to create the temporary DA, carry the
   following additional information via a Route Discovery Option (RDO
   defined in Section 6):

   o  The target

   o  The relevant routing metrics

   o  The constraints that the discovered route must satisfy.  These
      constraints also limit how far the Discovery message may travel.

   o  The nature of the route(s) to be discovered: hop-by-hop or source
      routes.  This specification allows for the discovery of one hop-
      by-hop route or up to four source routes in the forward direction.

   o  The desired number of routes (if source routes are being
      discovered)

   o  Whether the route(s) need to be bidirectional.  If bidirectional
      route(s) are being discovered, the target may store the route in
      backward direction for use as a source route.  This specification
      does not provide for the establishment of backward hop-by-hop
      routes.

   As the routers join the temporary DAG, they keep track of the best
   (partial) route(s) they have seen and advertise these routes, along
   with the corresponding routing metrics, in their DIOs.  The routing
   metrics are measured in forward direction unless bidirectional routes
   are being discovered, in which case the measurement of routing
   metrics need to take in account both forward and backward directions.
   A router, including the target, discards a received DIO if the
   aggregated routing metrics on the route advertised by the DIO do not
   satisfy the listed constraints.  These constraints can be used to
   limit the propagation of DIO messages used for P2P route discovery.
   A router may also discard a received DIO if it does not wish to be a



Goyal, et al.             Expires May 17, 2012                  [Page 6]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   part of the discovered route due to limited resources or due to
   policy reasons.

   When the target receives a DIO, it checks whether the route
   advertised therein satisfies the routing constraints.  If yes, the
   target may select the route for further processing as described next.
   This document does not specify a particular method for the target to
   select a route among the ones that satisfy the route constraints.
   Example selection methods include selecting any route that meets the
   constraints or selecting the best route(s) discovered over a certain
   time period.

   If one or more source routes are being discovered, the target sends
   the discovered source routes to the origin via Discovery Reply Object
   (DRO) messages, defined in Section 7, with one DRO message carrying
   one discovered route.  On receiving a DRO message, the origin stores
   the route contained therein in its memory.

   If a hop-by-hop route is being discovered, the target sends a DRO
   message to the origin after selecting a suitable route among the ones
   that satisfy the route constraints.  The DRO message travels towards
   the origin along the discovered route, establishing state for this
   route in the routers on the path.

   The target may store a discovered route in its memory if it is
   bidirectional and use it as a backward source-route to send packets
   to the origin.

   The target may request the origin to acknowledge the receipt of a DRO
   message by sending back a DRO Acknowledgement (DRO-ACK) message
   defined in Section 9.  The origin unicasts a DRO-ACK message to the
   target.  When the target does not receive the requested DRO-ACK
   within a certain time interval of sending a DRO, it resends the DRO
   message carrying the same route as before.

   The use of trickle timers to delay the propagation of DIO messages
   may cause some nodes to generate these messages even when the desired
   routes have already been discovered.  In order to preempt the
   generation of such unnecessary messages, the target may set a "stop"
   bit in the DRO message defined in Section 7, to let the nodes in the
   LLN know about the completion of the route discovery process.


6.  The Route Discovery Option (RDO)

   This section specifies a new RPL option, Route Discovery Option (RDO)
   which, when carried inside a DIO message, identifies that message as
   performing a P2P route discovery by creating a temporary DAG as



Goyal, et al.             Expires May 17, 2012                  [Page 7]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   specified in this document.

       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 10   | Option Length |D|H| N | Compr | L |    Rem    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                           Target                              |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Address[1..n]                           |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 1: Format of the Route Discovery Option

   In order to perform P2P route discovery as specified in this
   document, a DIO MUST carry a Route Discovery Option (RDO) illustrated
   in Figure 1.  A Route Discovery Option consists of the following
   fields:

   o  Option Type: 0x0A (to be confirmed by IANA).

   o  Option Length: 8-bit unsigned integer, representing the length in
      octets of the option, not including the Option Type and Option
      Length fields.

   o  Direction (D): This flag indicates the direction in which the
      desired routes should be optimized.  The flag is set to 1 if the
      routes are to be optimized for use in both forward and backward
      directions.  If the discovered routes need be optimized in the
      forward direction only, the flag is reset to 0.  Note that the
      discovered routes must have bidirectional reachability
      irrespective of the value of D flag.  This is because DRO messages
      (defined in Section 7) travel from the target back the origin
      along one of the discovered routes.  The link-level metric objects
      contained in the DIO SHOULD be measured in the direction indicated
      by the D flag.

   o  Hop-by-hop (H): This flag is set to 1 if a hop-by-hop route is
      desired.  The flag is reset to zero if source routes are desired.
      This specification allows for the establishment of one hop-by-hop
      route and up to four source routes in the forward direction.  This



Goyal, et al.             Expires May 17, 2012                  [Page 8]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


      specification does not allow for the establishment of hop-by-hop
      routes in the backward direction.  If a bidirectional route is
      discovered, the target MAY use the route in backward direction as
      a source route to reach the origin, irrespective of the value of H
      flag.

   o  Number of Routes (N): When source routes are being discovered, the
      value in this field plus one indicates the desired number of
      routes.  When a hop-by-hop route is being discovered this field
      MUST be set to zero on transmission and ignored on reception.

   o  Compr: 4-bit unsigned integer indicating the number of prefix
      octets that are elided from the Target field and the Address
      vector.  For example, Compr value will be 0 if full IPv6 addresses
      are carried in the Target field and the Address vector.

   o  Life Time (L): A 2-bit field that indicates the suggested life
      time of the temporary DAG, i.e., the suggested duration a router
      joining the temporary DAG must maintain its membership in the DAG.
      The mapping between the values in this field and the minimum life
      time of the temporary DAG is as follows:

      *  0x00: 1 second;

      *  0x01: 4 seconds;

      *  0x02: 16 seconds;

      *  0x03: 64 seconds;

      Note that a router MAY detach from the temporary DAG sooner if it
      receives a DRO message concerning this DAG with "stop" bit set
      (defined in Section 7).

   o  Rem: this field indicates the number of empty fields inside the
      Address vector.

   o  Target: The IPv6 address of the target after eliding Compr number
      of prefix octets.

   o  Address[1..n]: A vector of IPv6 addresses representing a (partial)
      route in the forward direction:

      *  Each element in the vector has size (16 - Compr) octets.

      *  The total number of elements inside the Address vector is given
         by n = (Option Length - 2 - (16 - Compr))/(16 - Compr).




Goyal, et al.             Expires May 17, 2012                  [Page 9]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


      *  The Address vector is used to accumulate a route optimized in
         the direction specified by the D field.

      *  The IPv6 addresses in the Address vector MUST be accessible in
         both forward and backward directions.  Accessibility in the
         backward direction is required because the DRO message uses the
         route accumulated in the Address vector to travel from the
         target to the origin.

      *  The Address vector MUST carry the accumulated route in the
         forward direction, i.e., the first element in the Address
         vector must contain the IPv6 address of the router next to the
         origin and so on.

      *  The origin and target addresses MUST NOT be included in the
         Address vector.

      *  A router adding its address to the vector MUST ensure that its
         address does not already exist in the vector.  A router
         specifying a complete route in the Address vector MUST ensure
         that the vector does not contain any address more than once.

      *  The Address vector MUST NOT contain any multicast addresses.

6.1.  Setting a DIO Carrying a Route Discovery Option

   A DIO message MUST NOT carry more than one Route Discovery Option.  A
   router MUST discard a DIO if it contains more than one Route
   Discovery Option.

   The Base Object in a DIO message carrying a Route Discovery Option
   MUST be set in the following manner:

   o  RPLInstanceID: RPLInstanceID MUST be a local value as described in
      Section 5.1 of [I-D.ietf-roll-rpl].  The origin MUST NOT use the
      same RPLInstanceID in two or more concurrent route discoveries.
      The origin MAY use the same RPLInstanceID value to establish hop-
      by-hop P2P routes to different target routers.

   o  Version Number: MUST be set to zero.  The temporary DAG used for
      P2P route discovery does not exist long enough to have new
      versions.

   o  Grounded (G) Flag: MUST be cleared since this DAG is temporary in
      nature and MUST NOT be used for routing purpose.

   o  Mode of Operation (MOP), DTSN: These fields MUST be set to value 0
      since this DAG does not support downward routing.



Goyal, et al.             Expires May 17, 2012                 [Page 10]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   o  DODAGPreference (Prf): This field MUST be set to value 0 (least
      preferred).

   o  DODAGID: This field MUST be set to the IPv6 address of the origin.

   o  The other fields in the Base Object can be set in the desired
      fashion as per the rules described in [I-D.ietf-roll-rpl].

   The DIO message must carry a DODAG Configuration option.  The DODAG
   Configuration option MUST be set in the following manner:

   o  MaxRankIncrease: This field MUST be set to 0 to disable local
      repair of the temporary DAG.

   o  Trickle parameters SHOULD be set as described in Section 8.2.

   o  The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using the
      mechanism described in this draft.

   o  The other fields in the DODAG Configuration option, including the
      OCP (identifying the Objective function defining the considered
      metrics and constraints [I-D.ietf-roll-routing-metrics]) can be
      set in the desired fashion as per the rules described in
      [I-D.ietf-roll-rpl].

   A DIO, carrying a Route Discovery Option, MUST NOT carry any Route
   Information or Prefix Information options described in
   [I-D.ietf-roll-rpl], in which case the DIO should be discarded.


7.  The Discovery Reply Object (DRO)

   This section defines two new RPL Control Message types, the Discovery
   Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the
   Secure DRO, with code 0x84 (to be confirmed by IANA).  A DRO serves
   one of the following functions:

   o  Carry a discovered source route from the target to the origin;

   o  Establish a hop-by-hop route as it travels from the target to the
      origin.

   A DRO message MAY also serve the function of letting the routers in
   the LLN know that a P2P route discovery is complete and no more DIO
   messages need to be generated for the corresponding temporary DAG.  A
   DRO message MUST carry one Route Discovery Option and travel from the



Goyal, et al.             Expires May 17, 2012                 [Page 11]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   target to the origin via link-local multicast along the route
   specified in the Route Discovery Option.

       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RPLInstanceID |    Version    |Seq|S|A|     Reserved          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         DODAGID                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...


         Figure 2: Format of the base Discovery Reply Object (DRO)

   The format of the base Discovery Reply Object (DRO) is shown in
   Figure 2.  A base DRO consists of the following fields:

   o  RPLInstanceID: The RPLInstanceID of the temporary DAG used for
      route discovery.

   o  Version: The Version of the temporary DAG used for route
      discovery.

   o  Sequence Number (Seq): This 2-bit field indicates the sequence
      number for the DRO.  This field is relevant when the A flag
      (specified below) is set, i.e., the target requests an
      acknowledgement from the origin for a received DRO.  The origin
      includes the RPLInstanceID, the DODAGID and the Sequence Number of
      the received DRO inside the DRO-ACK message it sends back to the
      target.

   o  Stop (S): This flag, when set by the target, indicates that the
      P2P route discovery is over.  The routers, receiving such a DRO,
      SHOULD cancel any pending DIO transmissions for the temporary DAG
      created for the route discovery and MAY detach from this DAG
      immediately.  Note that the stop flag serves to stop further DIO
      transmissions for a P2P route discovery but it does not affect the
      processing of DRO messages at either the origin or the
      intermediate routers.  In other words, a router (the origin or an
      intermediate router) MUST continue to process the DRO messages
      even if an earlier DRO message (with same RPLInstanceID, DODAGID
      and Version Number fields) had the stop flag set.




Goyal, et al.             Expires May 17, 2012                 [Page 12]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   o  Ack Required (A): This flag, when set by the target, indicates
      that the origin SHOULD unicast a DRO-ACK message (defined in
      Section 9) to the target when it receives the DRO.

   o  Reserved: These bits are reserved for future use.  These bits MUST
      be set to zero on transmission and MUST be ignored on reception.

   o  DODAGID: The DODAGID of the temporary DAG used for route
      discovery.  The DODAGID also identifies the origin.  The
      RPLInstanceID, the Version and the DODAGID together uniquely
      identify the temporary DAG used for route discovery and can be
      copied from the DIO message advertizing the temporary DAG.

   o  Options: The DRO message MUST carry one Route Discovery Option
      that MUST specify a complete route between the target and the
      origin.  The DRO message MAY carry a Metric Container Option that
      contains the aggregated routing metrics values for the route
      specified in Route Discovery Option.

7.1.  Secure DRO

   A Secure DRO message follows the format in Figure 7 of
   [I-D.ietf-roll-rpl], where the base format is the base DRO shown in
   Figure 2.

7.2.  Setting an RDO Carried in a Discovery Reply Object

   A Discovery Reply Object MUST carry a Route Discovery Option (RDO).
   An RDO carried in a Discovery Reply Object MUST be set as defined in
   Section 6 except for the following fields:

   o  Direction (D): this flag should be set to zero on transmission and
      ignored on reception.

   o  Number of Routes (N): this field MUST be set to zero on
      transmission and ignored on reception.

   o  Life Time (L): this field MUST be set to zero on transmission and
      ignored on reception.

   o  Rem: this field indicates the number of fields in the Address
      vector yet to be visited.

   o  Address[1..n]: the Address vector MUST contain a complete route
      between the origin and the target such that the first element in
      the vector contains the IPv6 address of the router next to the
      origin and the last element contains the IPv6 address of the
      router next to the target.



Goyal, et al.             Expires May 17, 2012                 [Page 13]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


8.  P2P Route Discovery By Creating a Temporary DAG

   This section details the functioning of P2P route discovery by
   creating a temporary DAG, using the RDO option in DIO messages on one
   hand and DRO messages on the other hand.

8.1.  Joining a Temporary DAG

   When a router joins a temporary DAG advertized by a DIO carrying a
   Route Discovery Option, it SHOULD maintain its membership in the DAG
   for the suggested Life Time duration listed in the Route Discovery
   Option.  Maintaining membership in the DAG implies storing:

   o  The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the
      temporary DAG;

   o  The router's rank in the temporary DAG;

   o  The best values of the routing metrics, along with the associated
      route(s) from the origin until this router (carried inside the
      Route Discovery Option) in the DIOs received so far.

   The only purpose of a temporary DAG's existence is to facilitate the
   propagation of the Discovery messages.  The temporary DAG MUST NOT be
   used to route packets.  A router SHOULD detach from the temporary DAG
   once the duration of its membership in the DAG has exceeded the DAG's
   suggested life time.  A router MAY detach from a temporary DAG sooner
   when it receives a DRO about the temporary DAG with stop flag set
   (defined in Section 7).

8.2.  Trickle Operation For DIOs Carrying a Route Discovery Option

   An RPL router uses a Trickle timer [RFC6206] to control DIO
   transmissions.  The Trickle control of DIO transmissions provides
   quick resolution of any "inconsistency" while avoiding redundant DIO
   transmissions.  The Trickle algorithm also imparts protection against
   loss of DIOs due to inherent lack of reliability in wireless
   communication.  When controlling the transmissions of a DIO carrying
   a Route Discovery Option, a Trickle timer SHOULD follow the following
   rules:

   o  The receipt of a DIO, that allows the router to advertise a better
      route (in terms of the routing metrics and the OCP in use) than
      before, is considered "inconsistent" and hence resets the Trickle
      timer.  Note that the first receipt of a DIO advertising a
      particular temporary DAG is always considered an inconsistent
      event under this rule.




Goyal, et al.             Expires May 17, 2012                 [Page 14]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   o  The receipt of a DIO, that advertises a better route than the
      router but does not lead to the router advertising a better route
      itself, is considered "consistent".

   o  The receipt of a DIO, that advertises as good a route as the
      router itself, is considered "consistent".

   o  The receipt of a DIO, that advertises a worse route than what the
      router advertises, is considered neither "consistent" nor
      "inconsistent", i.e., the receipt of such a DIO has no impact on
      the Trickle operation.

   o  The recommended values of Imin and Imax are same as in base RPL
      specification [I-D.ietf-roll-rpl], i.e., 8ms and 2.3 hours
      respectively.

   o  The recommended value of redundancy constant "k" is 1.  With this
      value of "k", a DIO transmission will be suppressed if the router
      receives even a single "consistent" DIO during a timer interval.

8.3.  Processing a DIO Carrying a Route Discovery Option

   The rules for DIO processing and transmission, described in Section 8
   of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route Discovery
   option as well except as modified in this document.

   The following rules for processing a DIO carrying a Route Discovery
   Option apply to both intermediate routers and the target.

   A router SHOULD discard a received DIO with no further processing if
   it does not have bidirectional reachability with the neighbor that
   originated the received DIO.  This is to ensure that a discovered
   route can be used to send a DRO message from the target to the
   origin.  Note that bidirectional reachability does not mean that the
   link must have the same values for a routing metric in both
   directions.  A router SHOULD update the values of the link-level
   routing metrics included inside the DIO in the direction indicated by
   the D flag in the Route Discovery Option.  If the D flag is 0, i.e.,
   the discovered routes need not be bidirectional, the link-level
   routing metrics SHOULD be measured in the forward direction, i.e.,
   towards the node receiving the DIO.  If the D flag is 1, i.e.,
   bidirectional routes are desired, the link-level routing metrics
   SHOULD be calculated so as to take in account the metric's value in
   both forward and backward directions.

   A router MUST discard the DIO with no further processing if it can
   not evaluate the mandatory route constraints listed in the DIO or if
   the routing metric values do not satisfy one or more of the mandatory



Goyal, et al.             Expires May 17, 2012                 [Page 15]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   constraints.

8.4.  Additional Processing of a DIO Carrying a Route Discovery Option
      At An Intermediate Router

   An intermediate router MUST discard a received DIO, containing a
   Route Discovery Option, with no further processing if the router can
   not elide "Compr" (as specified in the Route Discovery Option) prefix
   octets from its IPv6 address that would potentially be added to the
   Address vector as specified next.

   On receiving a DIO containing a Route Discovery Option, an
   intermediate router MUST determine whether this DIO advertises a
   better route than the router itself and whether the receipt of the
   DIO would allow the router to advertise a better route than before.
   Accordingly, the router SHOULD consider this DIO as consistent/
   inconsistent from Trickle perspective as described in Section 8.2.
   If the received DIO would allow the router to improve the route it
   advertises, the router MUST add its IPv6 address to the route inside
   the received DIO at location Address[n-Rem+1] and store this route in
   memory for inclusion in its future DIOs.  When an intermediate router
   adds itself to a route, it MUST ensure that the IPv6 address added to
   the route is accessible in both forward and backward directions.  To
   improve the diversity of the routes being discovered, an intermediate
   router SHOULD remember multiple partial routes, the best it knows in
   terms of the routing metrics, that it can advertise in the Route
   Discovery Option inside its DIO.  When the router generates its DIO,
   it SHOULD randomly select the partial route to be included in the
   Route Discovery Option from the set of best routes it has seen so
   far.

8.5.  Additional Processing of a DIO Carrying a Route Discovery Option
      At The Target

   The target discards a received DIO with no further processing if the
   routing metrics inside the DIO do not satisfy the mandatory
   constraints.  Otherwise, the target MAY select the route contained in
   the Route Discovery Option for further processing.  This document
   does not prescribe a particular method for the target to select such
   routes.  Example selection methods include selecting the desired
   number of routes as they are identified or selecting the best routes
   discovered over a certain time period.  If multiple routes are
   desired, the target SHOULD avoid selecting routes that have large
   segments in common.  If a discovered route is bidirectional (D=1),
   the target MAY store the route in backward direction, obtained by
   reversing the discovered forward route, for use as a source route to
   reach the origin.  After selecting a route, the target sends a
   Discovery Reply Object (DRO) message back to the origin (identified



Goyal, et al.             Expires May 17, 2012                 [Page 16]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   by the DODAGID field in the DIO).  In this DRO, the target includes a
   Route Discovery Option that contains the selected route inside the
   Address vector.  The Route Discovery Option included in the DRO
   message MUST copy the H flag from the Route Discovery Option inside
   the received DIO message.  The other fields inside the Route
   Discovery Option MUST be set as specified in Section 6.  The
   mechanism for the propagation of DRO messages is described in
   Section 7.

   The target MAY set the A flag inside the DRO message if it desires
   the origin to send back a DRO-ACK message on receiving the DRO.  In
   this case, the target waits for DRO_ACK_WAIT_TIME duration for the
   DRO-ACK message to arrive.  Failure to receive the DRO-ACK message
   within this time duration causes the target to retransmit the DRO
   message.  The target MAY retransmit the DRO message in this fashion
   up to MAX_DRO_RETRANSMISSIONS times.

   The target MAY include a Metric Container Option in the DRO message.
   This Metric Container contains the end-to-end routing metric values
   for the route specified in the Route Discovery Option.  The target
   MAY set the stop flag inside the DRO message (defined in Section 7)
   if it has already selected the desired number of routes.  A target
   MUST NOT forward a DIO carrying a Route Discovery option any further.

8.6.  Processing a DRO At An Intermediate Router

   When a router receives a DRO message that does not list its IPv6
   address in the DODAGID field, the router MUST process the received
   message in the following manner:

   o  If the stop flag inside the received DRO is set and the router
      currently belongs to the temporary DAG identified by the
      (RPLInstanceID, DODAGID and Version fields of the) DRO, the router
      SHOULD cancel any pending DIO transmissions for this temporary
      DAG.  Additionally, the router MAY detach from the temporary DAG
      immediately.

   o  An intermediate router MUST ignore any Metric Container Option
      contained in the DRO message.

   o  If Address[Rem] element inside the Route Discovery Option lists
      the router's own IPv6 address, the router is a part of the route
      carried in the Route Discovery Option.  In this case, the router
      MUST do the following:

      *  If the H flag inside the Route Discovery Option inside the DRO
         message is set, the router SHOULD store the state for the
         forward hop-by-hop route carried inside the Route Discovery



Goyal, et al.             Expires May 17, 2012                 [Page 17]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


         Option.  This state consists of:

         +  The RPLInstanceID and the DODAGID fields of the DRO.

         +  The route's destination, the target (identified by Target
            field in Route Discovery Option).

         +  The IPv6 address of the next hop, Address[Rem+1] (unless Rem
            value equals the number of elements in the Address vector,
            in which case the target itself is the next hop).

         The router MUST drop the DRO message without further processing
         if the H flag inside the Route Discovery Option is set but the
         router chooses not to store the state for the hop-by-hop route.

      *  If the router already maintains a hop-by-hop state listing the
         target as the destination and carrying same RPLInstanceID and
         DODAGID fields as the received DRO and the next hop information
         in the state does not match the next hop indicated in the
         received DRO, the router MUST drop the DRO message with no
         further processing.

      *  The router MUST decrement the Rem field inside the Route
         Discovery Option and send the DRO further via link-local
         multicast.

8.7.  Processing a DRO At The Origin

   When a router receives a DRO message that lists its IPv6 address in
   the DODAGID field, the router recognizes itself as the origin for the
   corresponding P2P route discovery and processes the Route Discovery
   Option contained in the DRO in the following manner.

   If the stop flag inside the received DRO is set and the origin still
   belongs to the temporary DAG it initiated, it SHOULD cancel any
   pending DIO transmissions for this temporary DAG.  Additionally, the
   origin MAY detach from the temporary DAG immediately.

   If the Route Discovery Option inside the DRO identifies the
   discovered route as a source route (H=0), the origin SHOULD store in
   its memory the discovered route contained in the Address vector.

   If the Route Discovery Option inside the DRO identifies the
   discovered route as a hop-by-hop route (H=1), the origin SHOULD store
   in its memory the state for the discovered route in the manner
   described in Section 8.6.

   If the received DRO message contains a Metric Container Option as



Goyal, et al.             Expires May 17, 2012                 [Page 18]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   well, the origin MAY store the values of the routing metrics
   associated with the discovered route in its memory.  This information
   may be useful in formulating the constraints for any future P2P route
   discovery to the target.

   If the A flag is set to one in the received DRO message, the origin
   SHOULD generate a DRO-ACK message as described in Section 9 and
   unicast the message to the target.  The origin MAY source route the
   DRO-ACK message to the target using the route contained in the
   received DRO.  If the received DRO established a hop-by-hop route to
   the target, the origin MAY send the DRO-ACK message along this route.
   Section 10 describes how a packet may be forwarded along a route
   discovered using the mechanism described in this document.


9.  The Discovery Reply Object Acknowledgement (DRO-ACK)

       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RPLInstanceID |    Version    |Seq|        Reserved           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         DODAGID                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 3: Format of the base Discovery Reply Object Acknowledgement
                                 (DRO-ACK)

   A DRO message may fail to reach the origin due to a number of
   reasons.  Unlike the DIO messages that benefit from Trickle-
   controlled retransmissions, the DRO messages are prone to loss due to
   reasons associated with wireless communication.  Since a DRO message
   travels via link-local multicast, it can not use link-level
   acknowledgements to improve the reliability of its transmission.
   Also, an intermediate router may drop the DRO message (e.g., because
   of its inability to store the state for the hop-by-hop route the DRO
   is establishing).  To protect against the potential failure of a DRO
   message to reach the origin, the target MAY request the origin to
   send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO
   message.  Failure to receive such an acknowledgement within the
   DRO_ACK_WAIT_TIME interval of sending the DRO message forces the
   target to resend the message.

   This section defines two new RPL Control Message types: DRO



Goyal, et al.             Expires May 17, 2012                 [Page 19]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA)
   and Secure DRO-ACK (with code 0x85; to be confirmed by IANA).  A DRO-
   ACK message MUST travel as a unicast message from the origin to the
   target.  The format of a base DRO-ACK message is shown in Figure 3.
   Various fields in a DRO-ACK message MUST have the same values as the
   corresponding fields in the DRO message.  The field marked as
   "Reserved" MUST be set to zero on transmission and MUST be ignored on
   reception.  A Secure DRO-ACK message follows the format in Figure 7
   of [I-D.ietf-roll-rpl], where the base format is same as the base
   DRO-ACK shown in Figure 3.


10.  Packet Forwarding Along a P2P Route

   This document specifies a mechanism to discover P2P routes, which can
   be either source routes or hop-by-hop ones.  A packet MAY use an RH4
   header [I-D.ietf-6man-rpl-routing-header] to travel along a P2P
   source route.  Travel along a P2P hop-by-hop route requires
   specifying the RPLInstanceID and the DODAGID to identify the route.
   This is because P2P route discovery does not use globally unique
   RPLInstanceID values and hence both the RPLInstanceID, which is a
   local value assigned by the origin, and the DODAGID, which is an IPv6
   address belonging to the origin, are required to uniquely identify a
   P2P hop-by-hop route to a particular destination.  A packet MAY
   include an RPL option [I-D.ietf-6man-rpl-option] inside the IPv6 hop-
   by-hop options header to travel along a P2P hop-by-hop route.  In
   this case, the origin MUST set the DODAGID of the P2P route as the
   source IPv6 address of the packet.  Further, the origin MUST specify
   the RPLInstanceID, associated with the P2P route, inside the RPL
   option and set the O flag inside the RPL option to 1.  A router
   receiving this packet will check the O flag inside the RPL option and
   correctly infer the source IPv6 address of the packet as the DODAGID
   of the hop-by-hop route to be used for forwarding the packet further.


11.  Security Considerations

   The security considerations for the operation of the reactive P2P
   route discovery mechanism described in this document are similar to
   the ones for the operation of RPL (as described in Section 19 of
   [I-D.ietf-roll-rpl]).  Section 10 of RPL specification
   [I-D.ietf-roll-rpl] describes a variety of security mechanisms to
   provide data confidentiality, authentication, replay protection and
   delay protection services.  Each RPL control message has a secure
   version that allows the specification of the level of security and
   the algorithms used to secure the message.  The mechanism defined in
   this document is based on the use of DIOs to form temporary DAGs and
   discover P2P routes.  These DIOs can be used in their secure versions



Goyal, et al.             Expires May 17, 2012                 [Page 20]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   if desired.  New RPL control messages defined in this document (DRO
   and DRO-ACK) have secure versions as well.  Thus, a particular
   deployment of the reactive P2P route discovery mechanism described in
   this document can analyze its security requirements and use the
   appropriate set of RPL security mechanisms that meet those
   requirements.


12.  IANA Considerations

12.1.  Additions to RPL Control Codes

   IANA is requested to allocate new code points in the "RPL Control
   Codes" registry for the "Discovery Reply Object" and "Discovery Reply
   Object Acknowledgement" (and their secure versions) described in this
   document.

   +------+--------------------------------------------+---------------+
   | Code |                 Description                |   Reference   |
   +------+--------------------------------------------+---------------+
   | 0x04 |           Discovery Reply Object           | This document |
   | 0x05 |   Discovery Reply Object Acknowledgement   | This document |
   | 0x84 |        Secure Discovery Reply Object       | This document |
   | 0x85 |        Secure Discovery Reply Object       | This document |
   |      |               Acknowledgement              |               |
   +------+--------------------------------------------+---------------+

                             RPL Control Codes

12.2.  Additions to RPL Control Message Options

   IANA is requested to allocate a new value in the "RPL Control Message
   Options" registry for the "Route Discovery Option" described in this
   document.

                +-------+-----------------+---------------+
                | Value |     Meaning     |   Reference   |
                +-------+-----------------+---------------+
                |   10  | Route Discovery | This document |
                +-------+-----------------+---------------+

                        RPL Control Message Options


13.  Acknowledgements

   Authors gratefully acknowledge the contributions of the following
   individuals (in alphabetical order) in the development of this



Goyal, et al.             Expires May 17, 2012                 [Page 21]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   document: Dominique Barthel, Thomas Clausen, Richard Kelsey, Phil
   Levis, Zach Shelby, Pascal Thubert and JP Vasseur.


14.  References

14.1.  Normative References

   [I-D.ietf-roll-routing-metrics]
              Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
              Barthel, "Routing Metrics used for Path Calculation in Low
              Power and Lossy Networks",
              draft-ietf-roll-routing-metrics-19 (work in progress),
              March 2011.

   [I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-19 (work in
              progress), March 2011.

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

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, March 2011.

14.2.  Informative References

   [I-D.brandt-roll-rpl-applicability-home-building]
              Brandt, A., Baccelli, E., and R. Cragie, "Applicability
              Statement: The use of RPL in Building and Home
              Environments",
              draft-brandt-roll-rpl-applicability-home-building-01 (work
              in progress), November 2010.

   [I-D.ietf-6man-rpl-option]
              Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
              Information in Data-Plane Datagrams",
              draft-ietf-6man-rpl-option-04 (work in progress),
              October 2011.

   [I-D.ietf-6man-rpl-routing-header]
              Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with RPL",
              draft-ietf-6man-rpl-routing-header-04 (work in progress),
              October 2011.



Goyal, et al.             Expires May 17, 2012                 [Page 22]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   [I-D.ietf-roll-p2p-measurement]
              Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A
              Mechanism to Measure the Quality of a Point-to-point Route
              in a Low Power and Lossy Network",
              draft-ietf-roll-p2p-measurement-02 (work in progress),
              October 2011.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-06 (work in
              progress), September 2011.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.


Authors' Addresses

   Mukul Goyal (editor)
   University of Wisconsin Milwaukee
   3200 N Cramer St
   Milwaukee, WI  53201
   USA

   Phone: +1 414 2295001
   Email: mukul@uwm.edu


   Emmanuel Baccelli
   INRIA

   Phone: +33-169-335-511
   Email: Emmanuel.Baccelli@inria.fr
   URI:   http://www.emmanuelbaccelli.org/


   Matthias Philipp
   INRIA

   Phone: +33-169-335-511
   Email: Matthias.Philipp@inria.fr





Goyal, et al.             Expires May 17, 2012                 [Page 23]

Internet-Draft         draft-ietf-roll-p2p-rpl-05          November 2011


   Anders Brandt
   Sigma Designs
   Emdrupvej 26A, 1.
   Copenhagen, Dk-2100
   Denmark

   Phone: +45-29609501
   Email: abr@sdesigns.dk


   Jerald Martocci
   Johnson Controls
   507 E Michigan St
   Milwaukee, WI  53202
   USA

   Phone: +1 414-524-4010
   Email: jerald.p.martocci@jci.com

































Goyal, et al.             Expires May 17, 2012                 [Page 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/