CoRE M. Becker, Ed. Internet-Draft T. Poetsch Intended status: Standards Track K. Kuladinithi Expires: January 16, 2014 ComNets, TZI, University Bremen July 15, 2013 Scenarios for CoAP on non-UDP Transports draft-becker-core-transport-scenarios-00 Abstract Several drafts in the CoRE WG are discussing the usage of CoAP on non-UDP/IP transports already. There are various use cases for non- UDP/IP transports. In order to structure the discussion, this draft introduces new terminology and transport scenarios. 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 January 16, 2014. Copyright Notice Copyright (c) 2013 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. Becker, et al. Expires January 16, 2014 [Page 1] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. UI to UI . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. UI client to UI server . . . . . . . . . . . . . . . . 6 4.1.2. UI server to UI client . . . . . . . . . . . . . . . . 7 4.1.3. UI client/server to UI server/client . . . . . . . . . 7 4.2. UI(+NUI) to UI . . . . . . . . . . . . . . . . . . . . . . 7 4.3. UI to UI(+NUI) . . . . . . . . . . . . . . . . . . . . . . 7 4.4. UI(+NUI) to UI(+NUI) . . . . . . . . . . . . . . . . . . . 7 4.4.1. UI(+NUI) client to UI(+NUI) server . . . . . . . . . . 7 4.4.2. UI(+NUI) server to UI(+NUI) client . . . . . . . . . . 7 4.4.3. UI(+NUI) client/server to UI(+NUI) server/client . . . 8 4.5. NUI to NUI . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5.1. NUI client to NUI server . . . . . . . . . . . . . . . 8 4.5.2. NUI server to NUI client . . . . . . . . . . . . . . . 8 4.5.3. NUI client/server to NUI server/client . . . . . . . . 8 4.6. NUI(+UI) to NUI . . . . . . . . . . . . . . . . . . . . . 8 4.7. NUI to NUI(+UI) . . . . . . . . . . . . . . . . . . . . . 9 4.8. NUI(+UI) to NUI(+UI) . . . . . . . . . . . . . . . . . . . 9 4.8.1. NUI(+UI) client to NUI(+UI) server . . . . . . . . . . 9 4.8.2. NUI(+UI) server to NUI(+UI) client . . . . . . . . . . 9 4.8.3. NUI(+UI) client/server to NUI(+UI) server/client . . . 9 5. Proxy Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9 6. Possible non-DNS solution . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Becker, et al. Expires January 16, 2014 [Page 2] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 1. Introduction Several use cases show a demand for using CoAP on non-UDP/IP transports. In order to facilitate the discussion of the use cases and the non-UDP/IP addresses, some scenarios have been assembled in this document. With non-UDP/IP transports, the following problems arise: o Which transport stack should be used? o Which protocol-specific options and parameters should be used? o Which addresses should be used and where are thoses addresses coming from? How are the addresses updated? This information might be available in DNS, a detailed solution on how to use DNS is needed. If DNS is not available in constrained networks, a new solution is necessary. 2. Terminology The terms CoAP Server and CoAP Client are used synonymously to Server and Client as specified in the terminology section of [I-D.ietf-core-coap]. This draft distinguishes between two different stacks at the endpoints: UDP/IP stack (UI): is an endpoint with an UDP/IP protocol stack as described in [I-D.ietf-core-coap]. non-UDP/IP stack (NUI): is an endpoint with a non-UDP/IP protocol stack (e.g. SMS, USB, BLE, TCP). Possibly, but not necessarily, endpoints can have additionally a different transport stack, i.e. UI or NUI. The syntax for describing the combinations of transport stacks on an endpoint are specified as follows: Primary stack(+Optional stack): The primary stack is always available at the endpoint, while the optional stack might be enabled or disabled. Example: UI(+NUI) The role of the endpoints are defined as follows: Becker, et al. Expires January 16, 2014 [Page 3] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 Altering Endpoint: is the endpoint where a modified resource is changed first. Altered Endpoint: is the endpoint where a modified resource is changed second. When a client is POSTing to a server, the client is the Altering endpoint and the server is the Altered endpoint. (As well for PUT and DELETE.) When a client is GETing from a server, the client is the Altered endpoint and the server the Altering endpoint. 3. 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 in RFC 2119 [RFC2119]. 4. Scenarios Several scenarios for communications with CoAP are presented first. Altering and Altered endpoints need to be defined for each transport. E.g. for Machine-to-Machine communication: Altering endpoint | Altered endpoint ------------------------------------------------------------------- Device in cloud | Telematic device Telematic device | Device in cloud Telematic device/Device in cloud | Device in cloud/Telematic device Figure 1: Application Role Assignment for Altering and Altered Endpoints Altering endpoint | Altered endpoint ------------------------------------------------------------------- CoAP client (POST/PUT/DELETE) | -> CoAP server CoAP server <- | CoAP client (GET) CoAP server/CoAP client <- |-> CoAP client/CoAP server Figure 2: Network Role Assignment for Altering and Altered Endpoints Becker, et al. Expires January 16, 2014 [Page 4] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 Altering endpoint | Altered endpoint ------------------------------------------------------------------- UI | UI UI(+NUI) | UI UI | UI(+NUI) UI(+NUI) | UI(+NUI) NUI | NUI NUI(+UI) | NUI NUI | NUI(+UI) NUI(+UI) | NUI(+UI) Figure 3: Possible Protocol Stacks of Altering and Altered Endpoints Becker, et al. Expires January 16, 2014 [Page 5] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 Altering endpoint | Altered endpoint ------------------------------------------------------------------- UI client | UI server UI server | UI client UI server/client | UI server/client UI(+NUI) client | UI server UI(+NUI) server | UI client UI(+NUI) server/client | UI server/client UI client | UI(+NUI) server UI server | UI(+NUI) client UI server/client | UI(+NUI) server/client UI(+NUI) client | UI(+NUI) server UI(+NUI) server | UI(+NUI) client UI(+NUI) server/client | UI(+NUI) server/client NUI client | NUI server NUI server | NUI client NUI server/client | NUI server/client NUI(+UI) client | NUI server NUI(+UI) server | NUI client NUI(+UI) server/client | NUI server/client NUI client | NUI(+UI) server NUI server | NUI(+UI) client NUI server/client | NUI(+UI) server/client NUI(+UI) client | NUI(+UI) server NUI(+UI) server | NUI(+UI) client NUI(+UI) server/client | NUI(+UI) server/client Figure 4: Possible Combinations of Altering and Altered Endpoints 4.1. UI to UI This scenario works just as described in the base CoAP specification [I-D.ietf-core-coap]. 4.1.1. UI client to UI server Regular CoAP data is pushed from client to server. The client needs to know the server's IP address and UDP port. On the client side, the server's UDP/IP address information can be entered on the commandline, in a GUI textfield, preconfigured or provided in another Becker, et al. Expires January 16, 2014 [Page 6] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 way. 4.1.2. UI server to UI client An UDP/IP CoAP server hosts modified data which is pulled by the client. The client needs to know the server's UDP/IP address information. On the client side, the server's UDP/IP address information needs to be preconfigured. 4.1.3. UI client/server to UI server/client Mixture of the above two scenarios, where both endpoints can be client and server. The first endpoint can push data to the second endpoint, which can use that data to request from the first endpoint. The first endpoint needs to know the second endpoint's UDP/IP address information. 4.2. UI(+NUI) to UI This is a scenario where two endpoints use an UDP/IP transport, and one supports non-UDP/IP. This scenario works just as described in Section 4.1. 4.3. UI to UI(+NUI) This is a scenario where two endpoints use an UDP/IP transport, and one supports non-UDP/IP. This scenario works just as described in Section 4.1. 4.4. UI(+NUI) to UI(+NUI) In this scenario, both UDP/IP endpoints offer an additional non- UDP/IP stack to communicate. However, none, one or both non-UDP/IP stacks might be enabled or disabled. 4.4.1. UI(+NUI) client to UI(+NUI) server Regular CoAP data is pushed from client to server. The client needs to know the server's IP address and UDP port. On the client side, the server's UDP/IP address information can be entered on the commandline, in a GUI textfield, preconfigured or provided in another way. A way to decide which stack to use needs to be available, if multiple stacks are enabled on the endpoints. 4.4.2. UI(+NUI) server to UI(+NUI) client Am UDP/IP CoAP server hosts modified data which is pulled by the client. The client needs to know the server's UDP/IP address Becker, et al. Expires January 16, 2014 [Page 7] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 information. On the client side, the server's UDP/IP address information needs to be preconfigured. A way to decide which stack to use needs to be available, if multiple stacks are enabled on the endpoints. 4.4.3. UI(+NUI) client/server to UI(+NUI) server/client Mixture of the above two scenarios, where both endpoints can be client and/or server. The first endpoint can push data to the second endpoint, which can use that data to request from the first endpoint. The first endpoint needs to know the second endpoint's UDP/IP address information. A way to decide which stack to use needs to be available, if multiple stacks are enabled on the endpoint. 4.5. NUI to NUI This is a scenario where two endpoints use a non-UDP/IP transport. 4.5.1. NUI client to NUI server CoAP data is pushed from client to server. The client needs to know the server's non-UDP/IP address information. On the client side, non-UDP/IP address information can be entered on the commandline, in a GUI textfield, preconfigured or in a similar way. A representation of the non-UDP/IP address information needs to be defined. 4.5.2. NUI server to NUI client A non-UDP/IP CoAP server hosts modified data which is pulled by the client. The client needs to know the server's non-UDP/IP address information. On the client side, the server's non-UDP/IP address information needs to be preconfigured. A representation of the non- UDP/IP address information needs to be defined. 4.5.3. NUI client/server to NUI server/client Mixture of the above two scenarios, where both endpoints can be client and/or server. The first endpoint can push data to the second endpoint, which can use that data to request from the first endpoint. The first endpoint needs to know the second endpoint's non-UDP/IP address information. A representation of the non-UDP/IP address information needs to be defined. 4.6. NUI(+UI) to NUI This is a scenario where two endpoints use a non-UDP/IP transport, and one endpoint supports UDP/IP. This scenario works just as described in Section 4.5. Becker, et al. Expires January 16, 2014 [Page 8] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 4.7. NUI to NUI(+UI) This is a scenario where two endpoints use a non-UDP/IP transport, and one endpoint supports UDP/IP. This scenario works just as described in Section 4.5. 4.8. NUI(+UI) to NUI(+UI) In this scenario, both non-UDP/IP endpoints offer an additional UDP/IP stack to communicate. However, none, one or both UDP/IP stacks might be enabled or disabled. 4.8.1. NUI(+UI) client to NUI(+UI) server CoAP data is pushed from client to server. The client needs to know the server's non-UDP/IP address information. On the client side, non-UDP/IP address information can be entered on the commandline, in a GUI textfield, preconfigured or in a similar way. A representation of the non-UDP/IP address information needs to be defined. A way to decide which stack to use needs to be available, if multiple stacks are enabled on the endpoint. 4.8.2. NUI(+UI) server to NUI(+UI) client The non-UDP/IP CoAP server hosts modified data which is pulled by the client. The client needs to know the server's non-UDP/IP address information. On the client side, the server's non-UDP/IP address information needs to be preconfigured. A representation of the non- UDP/IP address information needs to be defined. A way to decide which stack to use needs to be available, if multiple stacks are enabled on the endpoint. 4.8.3. NUI(+UI) client/server to NUI(+UI) server/client Mixture of the above two scenarios, where both endpoints can be client and/or server. The first endpoint can push data to the second endpoint, which can use that data to request from the first endpoint. The first endpoint needs to know the second endpoint's non-UDP/IP address information. A representation of the non-UDP/IP address information needs to be defined. A way to decide which stack to use needs to be available, if multiple stacks are enabled on the endpoint. 5. Proxy Scenarios TODO Becker, et al. Expires January 16, 2014 [Page 9] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 6. Possible non-DNS solution POST to e.g. .well-known/tconf with JSON or link-format? link-format: ;preference=1 ;preference=2 Figure 5: Link-Format JSON: Becker, et al. Expires January 16, 2014 [Page 10] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 { "protocoloptions": [ { "preference": "1", "protocolstack": [ { "protocol": "coap", "config": { "ACK_TIMEOUT": "2", "MAX_RETRANSMIT": "4" } }, { "protocol": "udp", "config": { "port": "8080" } }, { "protocol": "ip", "config": { "dest": "[2001:DB8::1]" } } ] }, { "preference": "2", "protocolstack": [ { "protocol": "coap", "config": { "ACK_TIMEOUT": "10", "MAX_RETRANSMIT": "1" } }, { "protocol": "sms", "config": { "address": "+49 172..." } } ] } ] } Becker, et al. Expires January 16, 2014 [Page 11] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 Figure 6: JSON 7. Security Considerations TODO 8. Acknowledgements This document is partly based on research for the research project 'The Intelligent Container' which is supported by the Federal Ministry of Education and Research, Germany, under reference number 01IA10001. 9. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-18 (work in progress), June 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Markus Becker (editor) ComNets, TZI, University Bremen Bibliothekstrasse 1 Bremen 28359 Germany Phone: +49 421 218 62379 Email: mab@comnets.uni-bremen.de Thomas Poetsch ComNets, TZI, University Bremen Bibliothekstrasse 1 Bremen 28359 Germany Phone: +49 421 218 62379 Email: thp@comnets.uni-bremen.de Becker, et al. Expires January 16, 2014 [Page 12] Internet-Draft Scenarios for CoAP on non-UDP Transports July 2013 Koojana Kuladinithi ComNets, TZI, University Bremen Bibliothekstrasse 1 Bremen 28359 Germany Phone: +49 421 218 62382 Email: koo@comnets.uni-bremen.de Becker, et al. Expires January 16, 2014 [Page 13]