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

Versions: 00 01

Internet Engineering Task Force                                O. Kleine
Internet-Draft                                University of Luebeck, ITM
Intended status: Informational                        September 12, 2014
Expires: March 16, 2015


                      CoAP Endpoint Identification
               draft-kleine-core-coap-endpoint-id-01.txt

Abstract

   The Constrained Application Protocol (CoAP) (see [RFC7252]), is an
   application layer protocol for constrained devices (e.g.low power,
   few memory) and networks (e.g. lossy, low bandwidth) which relies on
   UDP on the transport layer.  With CoAP it is often the case, that
   message exchanges need to extend the common request/response pattern,
   e.g.  for seperate responses.  This holds, e.g. for CON requests that
   are confirmed by the server with an empty ACK and answered later with
   a seperate response.  According to the CoAP specification the
   request/response matching is realized using a unique pair of the
   servers IP address and a token defined by the client.

   Due to the mobile nature of some devices. e.g. smartphones, they are
   often assigned new IP addresses because of a network change.  Thus,
   the IP address of a CoAP server might change during an ongoing
   conversation.  This draft proposes a method to assign each
   communication partner with an identifier (endpoint ID) which replaces
   the IP address as (partial) key to relate requests and responses.

   Besides the common seperate responses, the proposed method is also
   useful to handle IP address changes, e.g.  during an ongoing
   observation ([observe]) or a blockwise transfer ([block]).

Requirements Language

   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 inRFC 2119 [RFC2119].

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



Kleine                   Expires March 16, 2015                 [Page 1]


Internet-Draft              CoAP Endpoint ID              September 2014


   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 March 16, 2015.

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
   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.  A "Message Exchange"  . . . . . . . . . . . . . . . . . . . .   3
   3.  Endpoint Identification Options . . . . . . . . . . . . . . .   6
     3.1.  ENDPOINT_ID_1 option  . . . . . . . . . . . . . . . . . .   6
     3.2.  ENDPOINT_ID_2 option  . . . . . . . . . . . . . . . . . .   6
     3.3.  Option syntax and semantics . . . . . . . . . . . . . . .   7
     3.4.  Endpoint IDs for obervations  . . . . . . . . . . . . . .   7
       3.4.1.  Client IP changes during observation  . . . . . . . .   7
       3.4.2.  Server IP changes during observation  . . . . . . . .   7
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  NON request and NON response  . . . . . . . . . . . . . .   8
     4.2.  NON request, CON response, and empty ACK  . . . . . . . .   8
     4.3.  CON request, empty ACK, and NON response  . . . . . . . .   9
     4.4.  CON request, empty ACK, CON response, and empty ACK . . .   9
     4.5.  Server IP address changes during observation  . . . . . .   9
     4.6.  Client IP address changes during observation  . . . . . .  10
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12




Kleine                   Expires March 16, 2015                 [Page 2]


Internet-Draft              CoAP Endpoint ID              September 2014


1.  Introduction

   The concept of confirmable messages (CON) introduced in the main CoAP
   specification provides reliability in terms of message reception by
   the remote endpoint, i.e. the recipient of a confirmable message MUST
   confirm the reception with an acknowledgement (ACK) within 2 seconds.
   The absence of an ACK causes the sender of the CON message to
   retransmit the CON message.  However, an (empty) ACK just confirms
   the reception and for confirmable requests this might cause the
   server to send a separate response containing the actual result of
   the request processing, i.e. a third message within a single
   conversation.

   According to the CoAP specification the key to match incoming
   responses with open requests is a token which is defined by the
   client.  This token is set as one part of the requests header and
   sent to the server.  The server includes the same token in the
   response and by this means enables the client to match the response
   with a request.  The token is unique per communication partner, i.e.
   a client would use 2 different tokens for 2 parallel requests to a
   server but may use the same token for 2 parallel requests to
   different servers.  Thus, the client must use the combination of the
   server address and the token to match incoming responses with open
   requests.

   CoAP servers may run on mobile devices, e.g. smartphones, that are
   often assigned new IP addresses due to network changes.  The
   assignment of a new IP could happen within an ongoing conversion,
   i.e. after an empty ACK was sent but before the actual (separate)
   response.  In this case, the client can not match the response with
   the open request.  This draft introduces 2 new CoAP options to deal
   with this issue and enable ongoing conversations to continue even if
   one of the endpoints changes its IP address.

   Besides the common separate responses, the proposed method is also
   useful to handle IP address changes, e.g.  during an ongoing
   observation [observe] or a blockwise transfer [block].

2.  A "Message Exchange"

   A single message exchange is considered to consist of all messages
   that are sent between two endpoints as direct consequence of the
   first message plus this first message.  Thus, according to the CoAP
   specification (without extensions) a message exchange consists of
   either 1, 2, 3, or 4 messages.

   As NON request do not require a response, it is possible, that a
   message exchange consists only of a single message (see Figure 1).



Kleine                   Expires March 16, 2015                 [Page 3]


Internet-Draft              CoAP Endpoint ID              September 2014


                   CLIENT                         SERVER
                     |                              |
                     | ------ NON (request) ------> |
                     |                              |


                Figure 1: NON request without any response

   There are 2 possible types of Message Exchange that consist of 2
   messages.  Those are depicted in Figure 2 and Figure 3.



                   CLIENT                         SERVER
                     |                              |
                     | ----- NON (request) -------> |
                     |                              |
                     | <------ NON (response) ----- |
                     |                               |


                  Figure 2: NON requests and NON response



            CLIENT                                      SERVER
              |                                           |
              | ----- CON (request) --------------------> |
              |                                           |
              | <------ ACK (piggy-backed response) ----- |
              |                                           |


           Figure 3: CON request and ACK response (piggy-backed)

   Those were the types of Message Exchange that match the common
   request/response pattern.  However, due to the reliability concept of
   CoAP there are also types of Message Exchange that extends this
   pattern by consisting of 3 or even 4 messages.  The 2 possible types
   of Message Exchange that consist of 3 messages are depicted in
   Figure 4 and Figure 5.










Kleine                   Expires March 16, 2015                 [Page 4]


Internet-Draft              CoAP Endpoint ID              September 2014


                  CLIENT                          SERVER
                    |                               |
                    | ----- NON (request) --------> |
                    |                               |
                    | <------- CON (response) ----- |
                    |                               |
                    | ----- ACK (empty) ----------> |
                    |                               |


                  Figure 4: NON requests and CON response



               CLIENT                                 SERVER
                 |                                      |
                 | ----- CON (request) ---------------> |
                 |                                      |
                 | <----------------- ACK (empty) ----- |
                 |                                      |
                 | <----- NON (seperate response) ----- |
                 |                                      |


       Figure 5: CON request, empty ACK and NON response (seperate)

   The last type of Message Exchange consists of 4 messages to be sent
   and includes reliability for both, request and response (see
   Figure 6).



               CLIENT                                 SERVER
                 |                                      |
                 | ----- CON (request) ---------------> |
                 |                                      |
                 | <----------------- ACK (empty) ----- |
                 |                                      |
                 | <----- CON (seperate response) ----- |
                 |                                      |
                 | ----- ACK (empty) -----------------> |
                 |                                      |


         Figure 6: CON request, empty ACK, CON response, empty ACK






Kleine                   Expires March 16, 2015                 [Page 5]


Internet-Draft              CoAP Endpoint ID              September 2014


3.  Endpoint Identification Options

   The Endpoint Identification Extension introduces 2 new (opaque)
   options.  The first option (ENDPOINT_ID_1) is used to assign the
   communication partner, i.e. the remote CoAP endpoint, a unique ID.
   The recipient of a CoAP message that contains an ENDPOINT_ID_1 option
   repeats its value in every follow-up message as value of the
   ENDPOINT_ID_2 option.

   Furthermore, the sender of a CoAP message with ENDPOINT_ID_1 option
   uses the value as (partial) key for the duration of the conversation
   instead of the remote endpoints IP address, e.g. for request/response
   matching in combination with a token.  However, this approach does
   not include CoAPs reliability "layer" as empty ACKs MUST not include
   any options.  Thus, the CON/ACK matching still bases on the
   combination of remote IP and message ID.

3.1.  ENDPOINT_ID_1 option

   The ENDPOINT_ID_1 option is set by the sender of a CoAP message to
   assign the remote endpoint an ID which is supposed to be used to
   identify this endpoint for the remaining duration of the actual
   message exchange (see Section 3.2) whenever possible (this does
   explicitly not include empty messages, e.g.  ACK or RST).

   If the recipient of a CoAP message with ENDPOINT_ID_1 option does not
   support the option it SHOULD ignore that option.  As the recipient is
   supposed to repeat the value of the ENDPOINT_ID_1 option as value of
   the ENDPOINT_ID_2 option in every follow-up message within a message
   exchange, the first message origin can derive the lack of support for
   that option from the missing ENDPOINT_ID_2 option in the follow-up
   messages.  Thus, the ENDPOINT_ID_1 option is defined to be elective.

3.2.  ENDPOINT_ID_2 option

   The ENDPOINT_ID_2 option is set by the sender of a CoAP message to
   identify itself as the message origin.  The value of the
   ENDPOINT_ID_2 option repeats the value of the latest ENDPOINT_ID_1
   option that was received from the intended recipient of the message
   to be sent.

   Thus, a ENDPOINT_ID_2 option MUST not be set in a CoAP message if the
   intended recipient did not send a ENDPOINT_ID_1 option in a previous
   message.  If the ENDPOINT_ID_2 option is not supported the message
   MUST be rejected via RST message.  Also ENDPOINT_ID_2 option values
   that are unknown to the recipient MUST be rejected with a RST
   message.  Consequently, the ENDPOINT_ID_2 option is defined to be
   critical.



Kleine                   Expires March 16, 2015                 [Page 6]


Internet-Draft              CoAP Endpoint ID              September 2014


3.3.  Option syntax and semantics

   +------+---+---+---+---+---------------+--------+--------+---------+
   | Type | C | U | N | R | Name          | Format | Length | Default |
   +------+---+---+---+---+---------------+--------+--------+---------+
   | 124  | E | U | - | - | ENDPOINT_ID_1 | opaque | 0-4 B  |  (none) |
   |      |   |   |   |   |               |        |        |         |
   | 189  | C | U | - | - | ENDPOINT_ID_2 | opaque | 0-4 B  |  (none) |
   +------+---+---+---+---+---------------+--------+--------+---------+

                  Table 1: The endpoint ID option numbers

   The maximum length of 4 bytes is arbitrarily chosen.

3.4.  Endpoint IDs for obervations

   Observing a CoAP resource means to retrieve multiple responses as a
   consequence of a single request.  If the observe option is set in a
   request and observing is supported by the addressed resource, the
   client receives another response (update notification) whenever the
   status of the observed resource changes [observe].

   This leads to a new type of Message Exchange consisting of an
   arbitrary number of messages.  Within the duration of an observation
   relationship between a client and a server, both, the IP of the
   client and the IP of the server may change.

3.4.1.  Client IP changes during observation

   The server MUST set the ENDPOINT_ID_1 option in every update
   notification.  By this means, the client is assigned an ID which is
   independent from its IP address.  Whenever the IP address of the
   client changes during an ongoing observation, the client resends its
   initial request and adds the assigned ID as value of the
   ENDPOINT_ID_2 option.

   By this means, the server is able to update its internal "client ID/
   IP address - mapping" and continue the observation.  However, if the
   request was a CON request, a server MAY only respond with an empty
   ACK instead of a full response if the observed resource did not
   change since the last update notification.

3.4.2.  Server IP changes during observation

   Due to the ENDPOINT_ID_1 option in the request starting the
   observation, the server is assigned an ID that is independent from
   its IP address.  This ID is to be set as ENDPOINT_ID_2 value in every




Kleine                   Expires March 16, 2015                 [Page 7]


Internet-Draft              CoAP Endpoint ID              September 2014


   follow-up response (update notification) within this observation
   relationship.

   By this means, a client is able to update its internal "server ID/IP
   address - mapping" with every update notification.

4.  Examples

   Within the figures in this section MID refers to the message ID,
   whereas EID_x refers to the value of the ENDPOINT_ID_x option.

4.1.  NON request and NON response



         CLIENT                                         SERVER
           |                                              |
           | ----- NON [MID=1234, EID_1=0xab] ----------> |
           |                                              |
           |                               (Server IP may change)
           |                                              |
           | <--------- NON [MID=5678, EID_2=0xab] ------ |
           |                                              |


                  Figure 7: NON requests and NON response

4.2.  NON request, CON response, and empty ACK



     CLIENT                                                 SERVER
       |                                                      |
       | ----- NON [MID=1234, EID_1=0xab] ------------------> |
       |                                                      |
       |                                       (Server IP may change)
       |                                                      |
       | <----------------- CON [MID=5678, EID_2=0xab] ------ |
       |                                                      |
       | ----- ACK [MID=5678] ------------------------------> |
       |                                                      |


                  Figure 8: NON requests and NON response







Kleine                   Expires March 16, 2015                 [Page 8]


Internet-Draft              CoAP Endpoint ID              September 2014


4.3.  CON request, empty ACK, and NON response



           CLIENT                                      SERVER
             |                                           |
             | ----- CON [MID=1234, EID_1=0xab] -------> |
             |                                           |
             | <------------------ ACK [MID=1234] ------ |
             |                                           |
             |                            (Server IP may change)
             |                                           |
             | <------ NON [MID=5678, EID_2=0xab] ------ |
             |                                           |


                  Figure 9: NON requests and NON response

4.4.  CON request, empty ACK, CON response, and empty ACK



     CLIENT                                                 SERVER
       |                                                      |
       | ----- CON [MID=1234, EID_1=0xab] ------------------> |
       |                                                      |
       | <------------------------------ ACK [MID=1234] ----- |
       |                                                      |
       |                                       (Server IP may change)
       |                                                      |
       | <----------------- CON [MID=5678, EID_2=0xab] ------ |
       |                                                      |
       | ----- ACK [MID=5678] ------------------------------> |
       |                                                      |


      Figure 10: CON request, empty ACK, CON response, and empty ACK

4.5.  Server IP address changes during observation












Kleine                   Expires March 16, 2015                 [Page 9]


Internet-Draft              CoAP Endpoint ID              September 2014


  CLIENT                                                      SERVER
    |                                                            |
    | ----- CON [MID=1234, OBS=0, EID_1=0xab] -----------------> |
    |                                                            |
    | <------------------------------------ ACK [MID=1234] ----- |
    |                                                            |
    |                                                            |
    | <------------------ CON [MID=999, OBS=1, EID_2=0xab] ----- |
    |                                                            |
    | ----- ACK [MID=999] -------------------------------------> |
    |                                                            |
    |                                                            |
    |                                             (Server IP may change)
    |                                                            |
    |                                                            |
    | <----------------- CON [MID=1000, OBS=2, EID_2=0xab] ----- |
    |                                                            |
    | ----- ACK [MID=1000] ------------------------------------> |
    |                                                            |


          Figure 11: Server IP address changes during observation

4.6.  Client IP address changes during observation



























Kleine                   Expires March 16, 2015                [Page 10]


Internet-Draft              CoAP Endpoint ID              September 2014


    CLIENT                                                      SERVER
      |                                                           |
      | ----- CON [MID=1234, OBS=0, EID_1=0xab] ----------------> |
      |                                                           |
      | <----------------------------------- ACK [MID=1234] ----- |
      |                                                           |
      |                                                           |
      | <------ CON [MID=999, OBS=1, ID_1=0xef, EID_2=0xab] ----- |
      |                                                           |
      | ----- ACK [MID=999] ------------------------------------> |
      |                                                           |
      |                                                           |
    (Client IP may change)                                        |
      |                                                           |
      |                                                           |
      | ----- CON [MID=1235, OBS=0, EID_1=0xab, EID_2=0xef] ----> |
      |                                                           |
      | <----------------------------------- ACK [MID=1235] ----- |
      |                                                           |
      |                                                           |
      | <---- CON [MID=1000, OBS=2, EID_1=0xef, EID_2=0xab] ----- |
      |                                                           |
      | ----- ACK [MID=1000] -----------------------------------> |



          Figure 12: Client IP address changes during observation

5.  Acknowledgements

   No acknowledgements, yet...

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   To avoid an eval interruption of an ongoing Message Exchange, DTLS
   SHOULD be used to encrypt the CoAP messages.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <http://xml.resource.org/public/rfc/html/rfc2119.html>.



Kleine                   Expires March 16, 2015                [Page 11]


Internet-Draft              CoAP Endpoint ID              September 2014


   [RFC7252]  Shelby, et.al., , "The Contrained Application Protocol
              (CoAP)", RFC 7252, June 2014,
              <http://tools.ietf.org/html/rfc7252>.

8.2.  Informative References

   [block]    Borman, et al., , "Blockwise transfers in CoAP", 2013,
              <https://datatracker.ietf.org/doc/draft-ietf-core-block/>.

   [observe]  Hartke, , "Observing Resources in CoAP", 2014,
              <https://datatracker.ietf.org/doc/draft-ietf-core-
              observe/>.

Author's Address

   Oliver Kleine
   University of Luebeck, Institute of Telematics
   Ratzeburger Allee 160
   Luebeck  23552
   DE

   Email: kleine@itm.uni-luebeck.de





























Kleine                   Expires March 16, 2015                [Page 12]


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