Internet DRAFT - draft-kleine-core-coap-endpoint-id
draft-kleine-core-coap-endpoint-id
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]
