[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 7650

P2PSIP                                                        J. Jimenez
Internet-Draft                                                  Ericsson
Intended status: Standards Track                           J. Lopez-Vega
Expires: August 27, 2012                           University of Granada
                                                              J. Maenpaa
                                                            G. Camarillo
                                                                Ericsson
                                                       February 24, 2012


 A Constrained Application Protocol (CoAP) Usage for REsource LOcation
                         And Discovery (RELOAD)
                  draft-jimenez-p2psip-coap-reload-00

Abstract

   This document defines a Constrained Application Protocol (CoAP) Usage
   for REsource LOcation And Discovery (RELOAD).  The CoAP Usage
   provides the functionality to federate Wireless Sensor Networks (WSN)
   in a peer-to-peer fashion.  The CoAP Usage also provides a rendezvous
   service for CoAP Nodes and caching of sensor information.  The RELOAD
   AppAttach method is used to establish a direct connection between
   nodes through which CoAP messages are exchanged.

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 27, 2012.

Copyright Notice

   Copyright (c) 2012 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



Jimenez, et al.          Expires August 27, 2012                [Page 1]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


   (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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Registering CoAP URIs  . . . . . . . . . . . . . . . . . . . .  6
   5.  Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Forming a direct connection and reading data . . . . . . . . .  7
   7.  Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  ProxyCache . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.2.  SensorCache  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  CoAP Usage Kinds Definition  . . . . . . . . . . . . . . . . . 12
     8.1.  CoAP-REGISTRATION Kind . . . . . . . . . . . . . . . . . . 12
     8.2.  CoAP-CACHING Kind  . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     10.1. RELOAD Sensor Type Registry  . . . . . . . . . . . . . . . 13
     10.2. CoAP-REGISTRATION Kind-ID  . . . . . . . . . . . . . . . . 14
     10.3. CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     11.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15



















Jimenez, et al.          Expires August 27, 2012                [Page 2]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


1.  Introduction

   The Constrained Application Protocol (CoAP) is a specialized web
   transfer protocol.  It realizes the Representational State Transfer
   (REST) architecture for the most constrained nodes, such as sensors
   and actuators.  CoAP can be used not only between nodes on the same
   constrained network but also between constrained nodes and nodes on
   the Internet.  The latter is possible since CoAP can be translated to
   Hypertext Transfer Protocol (HTTP) for integration with the web.
   Application areas of CoAP include different forms of M2M
   communication, such as home automation, construction, health care or
   transportation.  Areas with heavy use of sensor and actuator devices
   that monitor and interact with the surrounding environment.

   The CoAP Usage for RELOAD allows CoAP nodes to store resources in a
   RELOAD peer-to-peer overlay, provides a rendezvous service, and
   enables the use of RELOAD overlay as a cache for sensor data.  This
   functionality is implemented in the RELOAD overlay itself, without
   the use of centralized servers.  The CoAP Usage involves three basic
   functions:

   1.  Registration: CoAP nodes can use the RELOAD data storage
       functionality to store a mapping from their CoAP URI to their
       Node-ID in the overlay, and to retrieve the Node-IDs of other
       nodes.
   2.  Rendezvous: Once a CoAP node has identified the Node-ID for an
       URI it wishes to retrieve, it can use the RELOAD message routing
       system to set up a direct connection which can be used to
       exchange CoAP messages.
   3.  Caching: Nodes can use the RELOAD overlay as a caching mechanism
       for their sensor information.  This is specially useful for
       battery constrained nodes that can make their data available in
       the cache provided by the overlay while in sleep mode.

   For instance, a CoAP proxy (See Section 3) could register its Node-ID
   (e.g. "9996172") and a list of sensors (e.g. "/temperature-1;
   ./temperature-2; ./temperature-3") under its URI (e.g.
   "coap://overlay-1.com/proxy-1/").

   When a node wants to discover the values associated with that URI, it
   queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back
   the Node-ID of the proxy and the list of its associated sensors.  The
   requesting node can then use the RELOAD overlay to establish a direct
   connection with the proxy and to read sensor values.

   Moreover, the CoAP proxy can store the sensor information in the
   overlay.  In this way information can be retrieved directly from the
   overlay without performing a direct connection to the storing proxy.



Jimenez, et al.          Expires August 27, 2012                [Page 3]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


2.  Terminology

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

   We use the terminology and definitions from Concepts and Terminology
   for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base
   Protocol [I-D.ietf-p2psip-base] extensively in this document.


3.  Architecture

   In our architecture we extend the different nodes present in RELOAD
   (Peer, Client) and add support for sensor devices or other
   constrained devices.  Figure 1 illustrates our architecture.  The
   different nodes, according to their functionality are :

   Client
      Devices that are capable of participating in a RELOAD overlay as
      client nodes, that is they do not route messages in the overlay.
   Router
      Devices that are members of (i.e., peers in) a RELOAD overlay and
      capable of forwarding RELOAD messages following a path through the
      overlay to the destination.
   Sensor
      Devices capable of measuring a physical quantity.  Sensors usually
      acquire quantifiable information about their surrounding
      environment such as: temperature, humidity, electric current,
      moisture, radiation, and so on.
   Actuator
      Devices capable of interacting and affecting their environment
      such as: electrical motors, pneumatic actuators, electric
      switches, and so on.
   Proxy
      Devices having sufficient resources to run RELOAD either as client
      or peer.  These devices are located at the edge of the sensor
      network and, in case of Wireless Sensor Networks (WSN), act as
      coordinators of the network.

   Physical devices can have one or several of the previous functional
   roles.  According to the functionalities that are present in each of
   the nodes, they can be:








Jimenez, et al.          Expires August 27, 2012                [Page 4]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


   Constrained Node
      A Constrained Node (CN) is a node with limited computational
      capabilities.  If it is wireless then it will be part of a Low-
      Rate Wireless Personal Area Network (LR-WPAN), it might be movable
      and often offer unreliable connectivity.  Also, devices will
      usually be in sleep mode in order to prevent battery drain, and
      will not communicate during those periods.  A CN is NOT part of
      the RELOAD overlay, therefore it can not act as a client, router
      nor proxy.  A CN is always either a either a Sensor or an
      Actuator.  In the latter case the node is often connected to a
      continuous energy power supply.

   Reload Node
      A Reload Node (RN) MUST implement the client functionality in the
      Overlay.  Additionally the node will often be a full RELOAD peer
      with Proxy functionality.  A RN may also be sensor or actuator
      since it can have those devices connected to it.


                                +------+
                                |      |
                       +--------+  RN  +---------+
                       |        |      |         |
                   +---+--+     +------+      +--+---+
                   |      |                   |      |
                   |  RN  |                   |  RN  |
                   |      |                   |      |   +------------+
                   +---+--+                   +--+---+   |        WSN |
                       |         RELOAD          |       |     +----+ |
                       |         OVERLAY         |       | +---+ CN | |
                   +---+--+                   +--+---+   | |   +----+ |
                   |      |                   |      +-----+          |
                   |  RN  |                   |  PN  |   |            |
                   |      |                   |      +-----+          |
                   +---+--+     +------+      +--+---+   | |   +----+ |
                       |        |      |         |       | +---+ CN | |
                       +--------+  PN  +---------+       |     +----+ |
                                |      |                 +------------+
                                +-+--+-+
                                  |  |
                         +--------|--|--------+
                         |     +--+  +--+     |
                         |     |        |     |
                         |  +--+-+    +-+--+  |
                         |  | CN |    | CN |  |
                         |  +----+    +----+  |
                         |                WSN |
                         +--------------------+



Jimenez, et al.          Expires August 27, 2012                [Page 5]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


                          Figure 1: Architecture


4.  Registering CoAP URIs

   CoAP URIs are typically resolved using a DNS.  When CoAP is needed in
   a RELOAD environment, URI resolution is provided by the overlay as a
   whole.  Instead of registering register a URI, a peer stores a
   CoAPRegistration structure under a hash of its own URI.  This uses
   the CoAP REGISTRATION Kind-ID, which is formally defined in
   Section 6, and that uses a DICTIONARY data model.

   As an example, if a CoAP proxy that is located in an overlay overlay-
   1.com using a Node-ID "9996172" wants to register three different
   temperature sensors to the URI
   "coap://overlay-1.com/proxy-1/.well-known/", it might store the
   following mapping in the overlay:


           RESOURCE-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
           KEY =    9996172,
           VALUE = {./temperature-1;
                   ./temperature-2;
                   ./temperature-3}

   Note that the RESOURCE-ID stored in the overlay is calculated as a
   SHA-1 hash over the URI (i.e. h(URI)).

   This would inform any other node performing a lookup for the previous
   URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value
   for proxy-1 is "9996172".  In addition, this mapping provides
   relevant information as to the number of sensors (CNs) and the URI
   path to connect to them using CoAP.


5.  Rendezvous

   The RELOAD overlay supports rendezvous by fetching mapping
   information between CoAP URIs and Node-IDs.

   As an example, if a node RN located in the overlay overlay-1.com
   wishes to read which resources are served at a RN with URI
   coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay.
   The RESOURCE-ID used in this fetch is a SHA-1 hash over the URI
   "coap://overlay-1.com/proxy-1/.well-known/".

   After this fetch request, the overlay will return the following
   result:



Jimenez, et al.          Expires August 27, 2012                [Page 6]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


           RESOURCE-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
           KEY =    9996172,
           VALUE = { ./temperature-1;
                     ./temperature-2;
                     ./temperature-3}

   The obtained KEY is the Node-ID of the RN responsible of this KEY/
   VALUE pair.  The VALUE is the set of URIs necessary to read data from
   the CNs associated with the RN.

   Using the RELOAD DICTIONARY model allows for multiple nodes to
   perform a store to the same RESOURCE-ID.  This feature allows for
   performing rendezvous with multiple RNs that host CNs of the same
   class.

   As an example, a fetch to the URI
   "coap://overlay-1.com/temperature/.well-known/" could return the
   following results:


           RESOURCE-ID = h(coap://overlay-1.com/temperature/.well-known/)
           KEY =    9992323,
           VALUE = { ./temperature}

           KEY =    9996172,
           VALUE = { ./temperature-1;
                     ./temperature-2;
                     ./temperature-3}

           KEY =   9996173,
           VALUE = { ./temp-a;
                     ./temp-b}


6.  Forming a direct connection and reading data

   Once a RN (e.g., node-A) has obtained the rendezvous information for
   a node in the overlay (e.g., proxy-1), it can open a direct
   connection to that node.  This is performed by sending an AppAttach
   request to the Node-ID obtained during the rendezvous process.

   After the AppAttach negotiation, node-A can access to the values of
   the CNs at proxy-1 using the URIs obtained during the rendezvous.
   Following the example in Section 5, the URIs for accessing to the CNs
   at proxy-1 would be:






Jimenez, et al.          Expires August 27, 2012                [Page 7]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


           coap://overlay-1.com/proxy-1/temperature-1
           coap://overlay-1.com/proxy-1/temperature-2
           coap://overlay-1.com/proxy-1/temperature-3

   Note that the ".well-known" string has been removed from the URIs, as
   this is only used during CNs discovery.  Figure 1 shows a sample of a
   node reading humidity data.












































Jimenez, et al.          Expires August 27, 2012                [Page 8]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


   +---+         +-----+     +---------+    +-----+          +---+
   |CNA|         | PNA |     | OVERLAY |    | PNB |          |CNB|
   +---+         +-----+     +---------+    +-----+          +---+
    |               |             |            |                |
    | .COAP CON GET |             |            |                |
    |  /humidity    | 2.RELOAD    |            |                |
    |+------------->|   Fetch     |            |                |
    |               |+----------->|            |                |
    |               |             |            |                |
    |               | 3.RELOAD    |            |                |
    |               |   200 OK    |            |                |
    |               |<-----------+|            |                |
    |               |             |            |                |
    |               | 4.RELOAD    |            |                |
    |               |   Attach    |            |                |
    |               |+----------->|            |                |
    |               |             | 5.RELOAD   |                |
    |               |             |   Attach   |                |
    |               |             |+---------->|                |
    |               |             |            |                |
    |               |             | 6.RELOAD   |                |
    |               | 7.RELOAD    |   200 OK   |                |
    |               |   200 OK    |<----------+|                |
    |               |<-----------+|            |                |
    |               |             |            |                |
    |               |                          |                |
    |               |   ---------------------  |                |
    |               | /        8.ICE          \|                |
    |               | \   connectivity checks /|                |
    |               |   ---------------------  |                |
    |               |                          |                |
    |               |      9.CoAP CON          |                |
    |               |        GET humidity      |                |
    |               |+------------------------>|                |
    |               |                          | 10.CoAP CON    |
    |               |                          |   GET humidity |
    |               |                          |+-------------->|
    |               |                          | 11.CoAP        |
    |               |     12.CoAP              |    ACK 200     |
    |  12.CoAP      |        ACK 200           |<--------------+|
    |     ACK 200   |<------------------------+|                |
    |<-------------+|                          |                |
    |               |                          |                |


                Figure 2: An Example of a Message Sequence





Jimenez, et al.          Expires August 27, 2012                [Page 9]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


7.  Caching Mechanisms

   The CoAP protocol itself supports the caching of sensor information
   in order to reduce the response time and network bandwidth
   consumption of future, equivalent requests.  This storage is done in
   CoAP proxies.

   This CoAP usage proposes an additional caching mechanism for storing
   sensor information directly in the overlay.  This caching mechanism
   is primarily intended for CNs with sensor capabilities, not for RN
   sensors.  This is due to the battery constrains of CNs, forcing them
   to stay in sleep mode for long periods of time.

   Whenever a CN wakes up, it sends the most recent data from its
   sensors to its proxy (RN), which stores the data in the overlay using
   a RELOAD StoredData structure defined in Section 6 of the RELOAD base
   draft.  We use the StoredDataValue structure defined in Section 6.2
   of the RELOAD base draft, in particular we use the SingleValue format
   type to store the cached values in the overlay.  From that structure
   length, storage_time, lifetime and Signature are used in the same
   way.  The only difference is data_value which in our case can be
   either a ProxyCache or a SensorCache:


   struct {
   uint16 coap_caching_type;

           select(coap_caching_type) {
                   case proxy_cache:       ProxyCache proxy_cache_entry;
                   case sensor_cache:      SensorCache sensor_cache_entry;

                   /* extensions */

           }
   } CoAPCaching;

7.1.  ProxyCache

   ProxyCache is meant to store values and sensor information (e.g.
   inactivity time) for all the sensors associated with a certain proxy,
   as well as their CoAP URIs.  On the other hand, SensorCache is used
   for storing the information and cached value of only one sensor (CoAP
   URI is not necessary, as is the same as the one used for generating
   the Resource-ID associated to that SensorCache entry).

   ProxyCache contains the fields NodeId and series of SensorEntry
   types.




Jimenez, et al.          Expires August 27, 2012               [Page 10]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


   struct {
           NodeId          Node_ID;
           SensorEntry     sensors[];
   } ProxyCache;

   NodeId
      The NodeID of the Proxy Node (PN) responsible for different sensor
      devices;
   SensorEntry
      List of sensors in the form of SensorEntry types;

   SensorEntry contains the coap_uri, sensor_info and a series of
   SensorValue types.

   struct {
           opaque          coap_uri;
           SensorInfo      sensor_info;
           SensorValue     sensor_value[];
   } SensorEntry;

   coap_uri
      CoAP name of the sensor device in question;
   sensor_info
      contains relevant sensor information;
   sensor_value
      contains a list of values stored by the sensor;

7.2.  SensorCache

   SensorCache: contains the information related to one sensor.

   struct {
           NodeId          Node_ID;
           SensorInfo      sensor_info;
           SensorValue     sensor_value[];
   } SensorCache;

   Node_ID
      identifies the NodeID of the Proxy Node responsible for the
      sensor;
   sensor_info
      contains relevant sensor information;
   sensor_value
      contains a list of values stored by the sensor;

   SensorInfo contains relevant sensor information, such as sensor_type,
   duration_of_inactivity and last_awake fields.




Jimenez, et al.          Expires August 27, 2012               [Page 11]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


   struct {
           integer         sensor_type;
           uint32          duration_of_inactivity;
           uint32          last_awake;

           /* extensions */

   } SensorInfo;

   sensor_type
      is an integer identifying the type of the sensor.  See Figure 3;
   duration_of_inactivity
      contains the sleep pattern (if any) that the sensor device
      follows, specified in seconds;
   last_awake
      indicates the last time that the sensor was awake in UNIX time;

   SensorValue contains the measurement_time, lifetime and value.

   struct {
           uint32          measurement_time;
           uint32          lifetime;
           opaque          value;

           /* extensions */

   } SensorValue;


   measurement_time
      indicates the moment in which the measure was taken;
   lifetime
      indicates the validity time of that measured value;
   value
      indicates the actual value measured.  It can be of different types
      (integer, long, string) therefore opaque has been used;


8.  CoAP Usage Kinds Definition

   This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds.


8.1.  CoAP-REGISTRATION Kind







Jimenez, et al.          Expires August 27, 2012               [Page 12]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


   Kind IDs
      The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP
      URI.  The data stored is a CoAPRegistration, which contains a
      Node-ID and a set of CoAP URIs.
   Data Model
      The data model for the CoAP-REGISTRATION Kind-ID is dictionary.
      The dictionary key is the Node-ID of the storing RN.  This allows
      each RN to store a single mapping.
   Access Control
      URI-NODE-MATCH.  The "coap:" prefix needs to be removed from the
      COAP URI before matching.

   Data stored under the COAP-REGISTRATION kind is of type
   CoAPRegistration, defined below.

   struct {
           uint16 coap_uris_length;
           opaque coap_uris (0..2^16-1);
   } CoAPRegistration;

8.2.  CoAP-CACHING Kind
   KindIDs
      The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI.
      The data stored is a CoAPCaching, which contains a Node-ID and a
      value.
   Data Model
      The data model for the CoAP-CACHING Kind-ID is single value.
   Access Control
      URI-MATCH.  The "coap:" prefix needs to be removed from the COAP
      URI before matching.

   Data stored under the CoAP-CACHING kind is of type CoAPCaching,
   defined in Section 7 .


9.  Security Considerations

   TBD.


10.  IANA Considerations

10.1.  RELOAD Sensor Type Registry

   IANA SHALL create a "RELOAD sensor type" Registry.  Entries in this
   registry are 16-bit integers denoting method codes as described in
   Section 7.  The initial contents of this registry are:




Jimenez, et al.          Expires August 27, 2012               [Page 13]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


                           +-----------------+-------+
                           | Code Name       | Value |
                           +-----------------+-------+
                           | temperature     |     0 |
                           | humidity        |     1 |
                           | acceleration    |     2 |
                           | pressure        |     3 |
                           | altitude        |     4 |
                           | luminance       |     5 |
                           | velocity        |     6 |
                           | signal_strength |     7 |
                           | battery         |     8 |
                           | heart_rate      |     9 |
                           +-----------------+-------+

                                 Figure 3

10.2.  CoAP-REGISTRATION Kind-ID

   This document introduces one additional data Kind-ID to the "RELOAD
   Data Kind-ID" Registry:


                   +-------------------+------------+----------+
                   | Kind              |    Kind-ID |      RFC |
                   +-------------------+------------+----------+
                   | CoAP-REGISTRATION |        105 | RFC-AAAA |
                   +-------------------+------------+----------+

   This Kind-ID was defined in Section 4.

10.3.  CoAP-CACHING Kind-ID

   This document introduces one additional data Kind-ID to the "RELOAD
   Data Kind-ID" Registry:


                   +--------------+------------+----------+
                   | Kind         |    Kind-ID |      RFC |
                   +--------------+------------+----------+
                   | CoAP-CACHING |        106 | RFC-AAAA |
                   +--------------+------------+----------+

   This Kind-ID was defined in Section 4.


11.  References




Jimenez, et al.          Expires August 27, 2012               [Page 14]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


11.1.  Normative References

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

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-08 (work in progress), October 2011.

   [I-D.ietf-p2psip-base]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", draft-ietf-p2psip-base-20 (work in
              progress), January 2012.

11.2.  Informative References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.


Authors' Addresses

   Jaime Jimenez
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: jaime.j.jimenez@ericsson.com


   Jose M. Lopez-Vega
   University of Granada
   CITIC-UGR Periodista Rafael Gomez Montero 2
   Granada  18071
   Spain

   Email: jmlvega@ugr.es









Jimenez, et al.          Expires August 27, 2012               [Page 15]


Internet-Draft           A CoAP Usage for RELOAD           February 2012


   Jouni Maenpaa
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: jouni.maenpaa@ericsson.com


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: gonzalo.camarillo@ericsson.com



































Jimenez, et al.          Expires August 27, 2012               [Page 16]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/