Internet DRAFT - draft-becker-core-transport-scenarios
draft-becker-core-transport-scenarios
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:
<coap://[2001:DB8::1]:8080>;preference=1
<coap+sms://+49....>;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]
