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

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

CoRE Working Group                                         B. Silverajan
Internet-Draft                                                       TUT
Intended status: Informational                                   M. Ocak
Expires: January 3, 2019                                        Ericsson
                                                            July 2, 2018


                       CoAP Protocol Negotiation
           draft-silverajan-core-coap-protocol-negotiation-09

Abstract

   CoAP has been standardised as an application-level REST-based
   protocol.  When multiple transport protocols exist for exchanging
   CoAP resource representations, this document introduces a way forward
   for CoAP endpoints as well as intermediaries to agree upon alternate
   transport and protocol configurations as well as URIs for CoAP
   messaging.  Several mechanisms are proposed: Extending the CoRE
   Resource Directory with new parameter types, introducing a new CoAP
   Option with which clients can interact directly with servers without
   needing the Resource Directory, and finally a new CoRE Link Attribute
   allowing exposing alternate locations on a per-resource basis.

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 https://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 January 3, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of



Silverajan & Ocak        Expires January 3, 2019                [Page 1]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Overcoming Middlebox Issues . . . . . . . . . . . . . . .   4
     2.2.  Better resource caching and serving in proxies  . . . . .   5
     2.3.  Interaction with Energy-constrained Servers . . . . . . .   6
   3.  Node Types based on Transport Availability  . . . . . . . . .   7
   4.  New Resource Directory Parameters . . . . . . . . . . . . . .   8
     4.1.  The 'at' RD parameter . . . . . . . . . . . . . . . . . .   8
     4.2.  The 'tt' RD parameter . . . . . . . . . . . . . . . . . .  10
   5.  CoAP Alternative-Transport Option . . . . . . . . . . . . . .  11
   6.  The 'ol' CoRE Link Attribute  . . . . . . . . . . . . . . . .  14
     6.1.  Using /.well-known/core . . . . . . . . . . . . . . . . .  14
     6.2.  Using CoRE Resource Directory . . . . . . . . . . . . . .  15
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  17
     A.1.  From -08 to -09 . . . . . . . . . . . . . . . . . . . . .  17
     A.2.  From -07 to -08 . . . . . . . . . . . . . . . . . . . . .  17
     A.3.  From -06 to -07 . . . . . . . . . . . . . . . . . . . . .  17
     A.4.  From -05 to -06 . . . . . . . . . . . . . . . . . . . . .  17
     A.5.  From -04 to -05 . . . . . . . . . . . . . . . . . . . . .  17
     A.6.  From -03 to -04 . . . . . . . . . . . . . . . . . . . . .  17
     A.7.  From -02 to -03 . . . . . . . . . . . . . . . . . . . . .  17
     A.8.  From -01 to -02 . . . . . . . . . . . . . . . . . . . . .  18
     A.9.  From -00 to -01 . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] allows clients,
   origin servers and proxies, to exchange and manipulate resource
   representations using REST-based methods over UDP or DTLS.  CoAP
   messaging however can use other alternative underlying transports
   [I-D.silverajan-core-coap-alternative-transports].




Silverajan & Ocak        Expires January 3, 2019                [Page 2]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   When CoAP-based endpoints and proxies possess the ability to perform
   CoAP messaging over multiple transports, significant benefits can be
   obtained if communicating client endpoints can discover that multiple
   transport bindings may exist on an origin server over which CoAP
   resources can be retrieved.  This allows a client to understand and
   possibly substitute a different transport protocol configuration for
   the same CoAP resources on the origin server, based on the
   preferences of the communicating peers.  Inevitably, if two CoAP
   endpoints reside in distinctly separate networks with orthogonal
   transports, a CoAP proxy node is needed between the two networks so
   that CoAP Requests and Responses can be exchanged properly.

   A URI in CoAP, however, serves two purposes simultaneously.  It
   firstly functions as a locator, by specifying the network location of
   the endpoint hosting the resource, and the underlying transport used
   by CoAP for accessing the resource representation.  It secondly
   identifies the name of the specific resource found at that endpoint
   together with its namespace, or resource path.  A single CoAP URI
   cannot be used to express the identity of the resource independently
   of alternate underlying transports or protocol configuration.
   Multiple URIs can result for a single CoAP resource representations
   if:

   o  the authority components of the URI differ, owing to the same
      physical host exposing several network endpoints.  For example,
      "coap://example.org/sensors/temperature" and
      "coap://example.net/sensors/temperature"

   o  the scheme components of the URI differ, owing to the origin
      server exposing several underlying transport alternatives.  For
      example, "coap://example.org/sensors/temperature" and
      "coap+tcp://example.org/sensors/temperature"

   Without a priori knowledge, clients would be unable to ascertain if
   two or more URIs provided by an origin server are associated to the
   same representation or not.  Consequently, a communication mechanism
   needs to be conceived to allow an origin server to properly capture
   the relationship between these alternate representations or locations
   and then subsequently supply this information to clients.  This also
   goes some way in limiting URI aliasing [WWWArchv1].

   In order to support CoAP clients, proxies and servers wishing to use
   CoAP over multiple transports, this draft proposes the following:

   o  An ability for servers to register supported CoAP transports to a
      CoRE Resource Directory [I-D.ietf-core-resource-directory] with
      optional registration lifetime values




Silverajan & Ocak        Expires January 3, 2019                [Page 3]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   o  A means for CoAP clients to interact with a CoRE resource
      directory interface for requesting and discovering alternative
      transports and locations of CoAP resources

   o  New Resource Directory parameter types enabling the above-
      mentioned features.

   o  A new CoAP Option called Alternative-Transport that can be used by
      CoAP clients to discover and retrieve the types of alternative
      transports available at the origin server, as well as the links
      describing the transport-specific endpoint address at which CoAP
      resources are exposed from.

   o  A new CoRE Link attribute for exposing transports and endpoint
      locations on an origin server on a per-resource basis.

2.  Aim

   The following simple scenarios aim to better portray how CoAP
   protocol negotiation benefits communicating nodes

2.1.  Overcoming Middlebox Issues

   Discovering which transports are available is important for a client
   to determine the optimal alternative to perform CoAP messaging
   according to its needs, particularly when separated from a CoAP
   server via a NAT.  It is well-known that some firewalls as well as
   many NATs, particularly home gateways, hinder the proper operation of
   UDP traffic.  NAT bindings for UDP-based traffic do not have as long
   timeouts as TCP-based traffic.



        +-------------+-----+      +---+      +-------------------+
        |             |     |--1-->|   |--1-->|     |             |
        |             | UDP |      | N |      | UDP |             |
        |             |     |<--2--|   |<--2--|     |             |
        | CoAP Client +-----+      | A |      +-----+ CoAP Server |
        |             |     |--3-->|   |--3-->|     |             |
        |             | TCP |      | T |      | TCP |             |
        |             |     |<--4--|   |<--4--|     |             |
        +-------------+-----+      +---+      +-----+-------------+



     Figure 1: CoAP Client initially accesses CoAP Server over UDP and
                           then switching to TCP




Silverajan & Ocak        Expires January 3, 2019                [Page 4]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   Figure 1 depicts such a scenario, where a CoAP client residing behind
   a NAT uses UDP initially for accessing a CoAP Server, and engages in
   discovering alternative transports offered by the server.  The client
   subsequently decides to use TCP for CoAP messaging instead of UDP to
   set up an Observe relationship for a resource at the CoAP Server, in
   order to avoid incoming packets containing resource updates being
   discarded by the NAT.

2.2.  Better resource caching and serving in proxies

   Figure 2 outlines a more complex example of intermediate nodes such
   as CoAP-based proxies to intelligently cache and respond to CoAP or
   HTTP clients with the same resource representation requested over
   alternative transports or server endpoints.  As with the earlier
   example, the CoAP Server registers its transports to a Resource
   Directory (This is assumed to be performed beforehand and not
   depicted in the figure, for brevity)

   In this example, a CoAP over WebSockets client successfully obtains a
   response from a CoAP forward proxy to retrieve a resource
   representation from an origin server using UDP, by supplying the CoAP
   server's endpoint address and resource in a Proxy-URI option.  Arrow
   1 represents a GET request to "coap+ws://proxy.example.com" which
   subsequently retrieves the resource from the CoAP server using the
   URI "coap://example.org/sensors/temperature", shown as arrow 2.



        +---------+
        | CoAP+WS |     +--------+-------+---+     +-----+---------+
        | Client  |<-1->|  Web   |       |   |<-2->|     |         |
        +---------+     | Socket | CoAP  | U |     | UDP |   CoAP  |
        +---------+     +--------+ Proxy | D |     +-----+  Server |
        |  HTTP   |<-3->|  HTTP  |       | P |     | TCP |         |
        | Client  |<-4->|        |       |   |     |     |         |
        +---------+     +--------+-------+---+     +-----+---------+



      Figure 2: Proxying and returning a resource's alternate cached
                    representations to multiple clients

   Subsequently, assume an HTTP client requests the same resource, but
   instead specifies a CoAP over TCP alternative URI instead.  Arrow 3
   represents this event, where the HTTP client performs a GET request
   to "http://proxy.example.com/coap+tcp://example.org/sensors/
   temperature".  When the proxy receives the request, instead of
   immediately retrieving the temperature resource again over TCP, it



Silverajan & Ocak        Expires January 3, 2019                [Page 5]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   first verifies either from the Resource Directory or directly from
   the server, whether the cached resource retrieved over UDP is a valid
   equivalent representation of the resource requested by the HTTP
   client over TCP.  Upon confirmation, the proxy is able to supply the
   same cached representation to the HTTP client as well (arrow 4).

2.3.  Interaction with Energy-constrained Servers

   Figure 3 illustrates discovery and communication between a CoAP
   client and an energy-constrained CoAP Server.  Such a server aims at
   conserving its energy unless a need arises otherwise.  The figure
   first depicts the server registering itself to a Resource Directory
   over IP, and also supplies its alternative CoAP transport endpoints
   (in this case, SMS), in steps 1 and 2.  The server can subsequently
   disable communication radio interfaces requiring greater energy (such
   as for IP-based comunication), powering it up sporadically for
   maintenance activities like registration renewals.  At other times,
   it maintains communication in a low-power state by listening only for
   incoming SMS messages.



                                +---------+
                                |  CoRE   |
                            +-->|   RD    |<--+
                            | +-+---------+-+ |
                           3| |             | |1
                            | |4           2| |
                            | v             v |
                 +---------------+       +---------------+
                 |         |     |       |     |         |
                 |  CoAP   | UDP |       | UDP |   CoAP  |
                 | Client  +-----+  5    +-----+  Server |
                 |         | SMS +------>| SMS |         |
                 |         |     +<------+     |         |
                 +---------------+   6   +---------------+



   Figure 3: CoAP client interacting with RD to discover a server's SMS-
                              based endpoint

   A CoAP client wishing to perform CoAP operations with an energy-
   constrained CoAP server may query a resource directory for the SMS-
   based endpoint of the server (steps 3 and 4).  Subsequently, SMS-
   based CoAP communication can occur between the endpoints as shown by
   arrows 5 and 6.  Alternatively, the incoming SMS can be also used by
   the server as a triggering event to temporarily power up its radio



Silverajan & Ocak        Expires January 3, 2019                [Page 6]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   interface so that UDP or other transport-based CoAP communication can
   instead be employed for low latency communication with the client.

3.  Node Types based on Transport Availability

   In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for
   devices, in terms of their resource constraints, energy limitations
   and communication power.  For this document, in addition to these
   capabilities, it seems useful to also identify devices based on their
   transport capabilities.


     +-------+----------------------------+
     | Name  |  Transport Availability    |
     +-------+----------------------------+
     |  T0   |  Single transport          |
     |       |                            |
     |  T1   |  Multiple transports, with |
     |       |  one or more active at any |
     |       |  point in time             |
     |       |                            |
     |  T2   |  Multiple active and       |
     |       |  persistent transports     |
     |       |  at all times              |
     +-------+----------------------------+

    Table 1: Classes of Available Transports


   Type T0 nodes possess the capability of exactly 1 type of transport
   channel for CoAP, at all times.  These include both active and sleepy
   nodes, which may choose to perform duty cycling for power saving.

   Type T1 nodes possess multiple different transports, and can retrieve
   or expose CoAP resources over any or all of these transports.
   However, not all transports are constantly active and certain
   transport channels and interfaces could be kept in a mostly-off state
   for energy-efficiency, such as when using CoAP over SMS.

   Type T2 nodes possess more than 1 transport, and multiple transports
   are simultaneously active at all times in a persistent manner.  CoAP
   proxy nodes which allow CoAP endpoints from disparate transports to
   communicate with each other, are a good example of this.








Silverajan & Ocak        Expires January 3, 2019                [Page 7]


Internet-Draft          CoAP Protocol Negotiation              July 2018


4.  New Resource Directory Parameters

   In order to allow resource interactions between clients and servers
   with multiple locations or transports, the registration, update and
   lookup interfaces of the CoRE Resource Directory need to be extended.
   In this section two new RD parameters, "at" and "tt" are introduced.
   Both are optional CoAP features.  If supported, they occur at the
   granularity level of an origin server, ie.  they cannot be applied
   selectively on some resources only.  When absent, it is assumed that
   the server does not support multiple transports or locations.

4.1.  The 'at' RD parameter

   A CoAP server wishing to advertise its resources over multiple
   transports does so by using one or more "at" parameters to register
   CoAP alternative transport URIs with a Resource Directory.  Such a
   URI would contain the scheme, address as well as any port or paths at
   which the server is available.


   +-----------+-------+---------------+---------------------+------------+
   | Name      | Query | Validity      | Description         |   Value    |
   +-----------+-------+---------------+---------------------+------------+
   | CoAP      | at    |     URI       | URI scheme, address | xsd:string |
   | Transport |       |               | port and path       |            |
   | URI       |       |               | on the server       |            |
   +-----------+-------+---------------+---------------------+------------+

 Table 2: The "at" RD parameter


   The "at" parameter extends the Resource Directory's Registration and
   Update interfaces.

   The following example shows a type T1 endpoint registering its
   resources and advertising its ability to use TCP and WebSockets as
   alternative transports:


    Req: POST coap://rd.example.com/rd?ep=node1
       &at=coap+tcp://[2001:db8:f1::2]&at=coap+ws://server.example.com
    Content-Format: 40
    Payload:
    </temperature>;ct=0;rt="temperature";if="core.s"

    Res: 2.01 Created
    Location: /rd/1234




Silverajan & Ocak        Expires January 3, 2019                [Page 8]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   An endpoint lookup would just reflect the registered attributes:

   Req: GET /rd-lookup/ep

   Res: 2.05 Content
   </rd/1234>;ep="node1";base="coap://[2001:db8:f1::2]:5683";
      at="coap+tcp://[2001:db8:f1::2]";at="coap+ws://server.example.com"

   The next example shows the same endpoint updating its registration
   with a new lifetime and the availability of a single alternative
   transport for CoAP (in this case TCP):


    Req: POST /rd/1234?lt=600
       &at=coap+tcp://[2001:db8:f1::2]
    Content-Format: 40
    Payload:
    </temperature>;ct=0;rt="temperature";if="core.s"

    Res: 2.04 Changed

   If a lookup is performed on the same endpoint only 1 alternative
   transport is indicated:

    Req: GET /rd-lookup/ep

    Res: 2.05 Content
    </rd/1234>;ep="node1";base="coap://[2001:db8:f1::2]:5683";
       at="coap+tcp://[2001:db8:f1::2]"

   A resource lookup for UDP client would be returned as the following:

 Req: GET /rd-lookup/res?rt=temperature

 Res: 2.05 Content
 <coap://[2001:db8:f1::2]/temperature>;ct=0;rt="temperature";if="core.s";
    anchor="coap://[2001:db8:f1::2]"

   A resource lookup for TCP client would be returned as the following:

 Req: GET /rd-lookup/res?rt=temperature

 Res: 2.05 Content
 <coap+tcp://[2001:db8:f1::2]/temperature>;ct=0;rt="temperature";if="core.s";
    anchor="coap+tcp://[2001:db8:f1::2]"






Silverajan & Ocak        Expires January 3, 2019                [Page 9]


Internet-Draft          CoAP Protocol Negotiation              July 2018


4.2.  The 'tt' RD parameter

   A CoAP client wishing to perform a look-up on the Resource Directory
   for CoAP servers supporting multiple transports does so by using one
   or more "tt" parameters to query for CoAP alternative transport URIs.


      +-----------+-------+-----------------------------+------------+
      | Name      | Query | Validity | Description      |   Value    |
      +-----------+-------+-----------------------------+------------+
      | CoAP      | tt    |          | Transport type   | xsd:string |
      | Transport |       |          | requested by     |            |
      | Type      |       |          | the client       |            |
      +-----------+-------+-----------------------------+------------+

    Table 3: The "tt" RD parameter


   The "tt" parameter extends the Resource Directory's rd-lookup
   interface.  The "tt" parameter queries existing registrations, and
   MUST NOT be used with the Resource Directory's registration and
   update interfaces.

   The following example shows a client performing a lookup for
   endpoints supporting TCP:


      Req: GET /rd-lookup/ep?tt="coap+tcp"

      Res: 2.05 Content
      </rd/1234>;at="coap+tcp://[2001:db8:f1::2]";ep="node1";ct="40"


   The following example shows a client performing a resource lookup for
   endpoints supporting TCP:


     Req: GET /rd-lookup/res?rt=temperature&tt="coap+tcp"

     Res: 2.05 Content
     <coap+tcp://[2001:db8:f1::2]/temperature>;ct=0;rt="temperature";
      if="core.s";anchor="coap+tcp://[2001:db8:f1::2]"


   The following example shows a client performing a lookup for
   endpoints supporting SMS i.e. discovering SMS transports for sleepy
   nodes and using SMS to communicate with the endpoint:




Silverajan & Ocak        Expires January 3, 2019               [Page 10]


Internet-Draft          CoAP Protocol Negotiation              July 2018


      Req: GET /rd-lookup/ep?et=oic.d.switch&tt="coap+sms"

      Res: 2.05 Content
      </rd/2345>;at="coap+sms://0015105550101/";ep="node5";
       et="oic.d.switch";ct="40",
      </rd/4521>;at="coap+sms://0015105550202/";ep="node8";
       et="oic.d.switch";ct="40"


5.  CoAP Alternative-Transport Option

   The CoAP Alternative-Transport Option can be used by CoAP clients and
   CoAP servers in both Request and Response messages in constrained
   environments where a CoRE Resource Directory is not present.

   Figure 4 depicts the properties of the Alternative-Transport Option.




 +-----+---+---+---+---+------------------------+--------+--------+----------+
 | No. | C | U | N | R | Name                   | Format | Length | Default  |
 +-----+---+---+---+---+------------------------+--------+--------+----------+
 |  66 |   | x | - | x | Alternative-Transport  | string | 0-1034 | (none)   |
 +-----+---+---+---+---+------------------------+--------+--------+----------+

    C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable




                Figure 4: The Alternative-Transport Option

   When included in a Request message, this option is used by the client
   in 2 possible ways.  In the first case, a CoAP client can include the
   Option with Length 0 to retrieve all alternative transports from a
   CoAP server.  In response to the client, the server includes base URI
   for each transport in its own Option.  In the second case, a CoAP
   client can include the Option with a specific value in a CoAP
   Request, and the CoAP server returns the base URI(s) for the
   specified transport.  If the specified transport by a CoAP client
   returns multiple results on a CoAP server, the server returns all
   base URIs of the transport in the response, each base URI in its own
   Option.

   A CoAP client can also use this Option to retrieve several transports
   at once by including multiple Options in the request to a CoAP
   server.  If any of the specified transports is supported by the



Silverajan & Ocak        Expires January 3, 2019               [Page 11]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   server, the server returns all base URIs in its own option.  There
   can be more than 1 result for any of the transports so that each
   transport base URI is still included in the response in its own
   option.

   Figure 5 describes a simple interaction between a client and a
   server, in which the client uses an Alternative-Transports Option
   with a null value to discover and retrieve all the available
   transports from the server, as part of a GET operation to retrieve a
   resource representation.  The server responds with a CoAP Response
   message which contains the resource representation as a payload.  In
   addition, the server also supplies multiple Alternative-Transport
   Options in the message, with each Option containing the base URI for
   an available transport.  In this case the base URIs returned for TCP-
   based and WebSocket transports indicate their availability over a
   non-standard port.



              Client                                  Server
                 +                                       |
                 |  GET /temperature                     |
                 |  Token: 0x64                          |
                 |  Alternative-Transport: (null)        |
                 +-------------------------------------->|
                 |                                       |
                 |    2.05 Content                       |
                 |    Token: 0x64                        |
                 |    Payload: 21.0 Cel                  |
                 |    Alternative-Transport:             |
                 |      coap+tcp://example.org:5555/     |
                 |    Alternative-Transport:             |
                 |      coaps+tcp://example.org:6666/    |
                 |    Alternative-Transport:             |
                 |      coap+sms://0015105550101/        |
                 |    Alternative-Transport:             |
                 |      coap+ws://example.org:8080/      |
                 |                                       |
                 |<--------------------------------------+
                 |                                       |





     Figure 5: Requesting all available alternative transports on the
                        server, and their locations




Silverajan & Ocak        Expires January 3, 2019               [Page 12]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   Alternatively, a client can also request for the availability of a
   specific transport on the server, as shown in Figure 6.  Here, the
   CoAP Request contains Alternative-Transport Options with values set
   to request the Base URIs for TCP-based endpoints.



              Client                                  Server
                 +                                       |
                 |  GET /temperature                     |
                 |  Token: 0x64                          |
                 |  Alternative-Transport: coap+tcp      |
                 |  Alternative-Transport: coaps+tcp     |
                 +-------------------------------------->|
                 |                                       |
                 |    2.05 Content                       |
                 |    Token: 0x64                        |
                 |    Payload: 21.0 Cel                  |
                 |    Alternative-Transport:             |
                 |      coap+tcp://example.org:5555/     |
                 |    Alternative-Transport:             |
                 |      coaps+tcp://example.org:6666/    |
                 |                                       |
                 |<--------------------------------------+
                 |                                       |




   Figure 6: Requesting TCP-based alternative transports on the server,
                            and their locations

   A client may also request a subset of available transports on the
   server, by providing multiple Options, each having a single transport
   identifier.  The server likewise responds to the client request by
   supplying the requested transport information.  This is shown in
   Figure 7.














Silverajan & Ocak        Expires January 3, 2019               [Page 13]


Internet-Draft          CoAP Protocol Negotiation              July 2018


              Client                                  Server
                 +                                       |
                 |  GET /temperature                     |
                 |  Token: 0x64                          |
                 |  Alternative-Transport:  ws           |
                 |  Alternative-Transport:  sms          |
                 +-------------------------------------->|
                 |                                       |
                 |    2.05 Content                       |
                 |    Token: 0x64                        |
                 |    Payload: 21.0 Cel                  |
                 |    Alternative-Transport:             |
                 |      coap+sms://0015105550101/        |
                 |    Alternative-Transport:             |
                 |      coap+ws://example.org:8080/      |
                 |                                       |
                 |<--------------------------------------+
                 |                                       |




   Figure 7: Requesting WebSocket- and SMS-based alternative transports
                    on the server, and their locations

6.  The 'ol' CoRE Link Attribute

   In the majority of cases, it is expected that an origin server would
   expose all its resources uniformly on its available transports or
   endpoint addresses.  Exceptions can exist however, where alternate
   locations are made available on a per-resource basis.  For such
   cases, a new 'ol' ("other locations") attribute is provided.  One or
   more 'ol' attributes are used to provide base URIs from which a
   specific resource can be reached.  Allowing per-resource endpoint or
   transport availability enables specific functions such as firmware
   updates or hardware-specific operations.  It also facilitates mapping
   to and from OCF-based resource-specific endpoint descriptions.  Note
   that the use of 'ol' is orthogonal to using 'at' as shown in
   Section 6.2.

6.1.  Using /.well-known/core










Silverajan & Ocak        Expires January 3, 2019               [Page 14]


Internet-Draft          CoAP Protocol Negotiation              July 2018


      REQ: GET /.well-known/core

      RES: 2.05 Content
      </sensors/temp>;ct=41;rt="temperature-f";if="sensor",
      </sensors/door>;ct=41;rt="door";if="sensor",
      </sensors/light>;if="sensor"; ol="http://[FDFD::123]:61616";
        ol="coap://server2.example.com"


6.2.  Using CoRE Resource Directory

   Req: POST coap:/rd.example.com/rd
    ?ep=node1&at=coap+tcp://server.example.com&at=coap+ws://server.example.com:5683/ws/
   Content-Format: 40
   Payload:
   </sensors/temp>;ct=41;rt="temperature-f";if="sensor",
   </sensors/door>;ct=41;rt="door";if="sensor",
   </sensors/light>;if="sensor"; ol="http://[FDFD::123]:61616";
     ol="coap://server2.example.com"

   Res: 2.01 Created
   Location: /rd/4521


7.  IANA Considerations

   This document requests the registration of new RD parameter types
   "at" and "tt".

   The following entry needs to be added to the CoAP Option Numbers
   Registry:



      +--------+------------------------+------------------+
      | Number | Name                   | Reference        |
      +--------+------------------------+------------------+
      |     66 | Alternative-Transports | (this document)  |
      +--------+------------------------+------------------+




8.  Security Considerations

   When multiple transports, locations and representations are used,
   some obvious risks are present both at the origin server as well as
   by requesting clients.



Silverajan & Ocak        Expires January 3, 2019               [Page 15]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   When a client is presented with alternate URIs for retrieving
   resources, it presents an opportunity for attackers to mount a series
   of attacks, either by hijacking communication and masquerading as an
   alternate location or by using a man-in-the-middle attack on TLS-
   based communication to a server and redirecting traffic to an
   alternate location.  A malicious or compromised server could also be
   used for reflective denial-of-service attacks on innocent third
   parties.  Moreover, clients may obtain web links to alternate URIs
   containing weaker security properties than the existing session.

9.  Acknowledgements

   Thanks to Christian Amsuess, Klaus Hartke, Jaime Jimenez and Jim
   Schaad for comments and reviewing this draft.  Teemu Savolainen was
   involved in initial discussions about protocol negotations and
   lifetime values.  Zach Shelby provided significant suggestions on how
   the Resource Directory can be employed and extended in place of link
   attributes and relation types.

10.  References

10.1.  Normative References

   [I-D.ietf-core-resource-directory]
              Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
              Amsuess, "CoRE Resource Directory", draft-ietf-core-
              resource-directory-14 (work in progress), July 2018.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

10.2.  Informative References

   [I-D.silverajan-core-coap-alternative-transports]
              Silverajan, B. and T. Savolainen, "CoAP Communication with
              Alternative Transports", draft-silverajan-core-coap-
              alternative-transports-11 (work in progress), March 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.







Silverajan & Ocak        Expires January 3, 2019               [Page 16]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [WWWArchv1]
              http://www.w3.org/TR/webarch/#uri-aliases, "Architecture
              of the World Wide Web, Volume One", December 2004.

Appendix A.  Change Log

A.1.  From -08 to -09

   Using "tt" and "Alternative Transports" updated.

A.2.  From -07 to -08

   Added example of energy constrained CoAP server

   Updated examples of using "at" and "tt"

   "at" and "ol" are no longer comma-separated URI lists.

A.3.  From -06 to -07

   Added support for 'ol' Link attribute

A.4.  From -05 to -06

   Added support for CoAP Alternative-Transports Option

A.5.  From -04 to -05

   Freshness update

A.6.  From -03 to -04

   Removed previously introduced link attribute and relation types

   Initial foray with Resource Directory support

A.7.  From -02 to -03

   Added new author

   Rewrite of "Introduction" section

   Added new Aims Section



Silverajan & Ocak        Expires January 3, 2019               [Page 17]


Internet-Draft          CoAP Protocol Negotiation              July 2018


   Added new Section on Node Types

   Introduced "al" Active Lifetime link attribute

   Added new Section on Observing transports and resources

   Security and IANA considerations sections populated

A.8.  From -01 to -02

   Freshness update.

A.9.  From -00 to -01

   Reworked "Introduction" section, added "Rationale", and "Goals"
   sections.

Authors' Addresses

   Bilhanan Silverajan
   Tampere University of Technology
   Korkeakoulunkatu 10
   FI-33720 Tampere
   Finland

   Email: bilhanan.silverajan@tut.fi


   Mert Ocak
   Ericsson
   Hirsalantie 11
   02420 Jorvas
   Finland

   Email: mert.ocak@ericsson.com
















Silverajan & Ocak        Expires January 3, 2019               [Page 18]


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