CoRE Working Group A. Castellani Internet-Draft University of Padova Intended status: Informational March 7, 2011 Expires: September 8, 2011 Constrained Messaging Protocol: an UDP protocol extension useful for CoAP and other protocols. draft-castellani-core-transport-00.txt Abstract This document aims at exploring the benefits of designing a more general-purpose transport protocol for CoAP: the proposed protocol is believed to be viable for implementation on constrained devices and proves to be suitable for transporting CoAP request/responses. 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 September 8, 2011. Copyright Notice Copyright (c) 2011 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. Castellani Expires September 8, 2011 [Page 1] Internet-Draft Constrained Messaging Protocol March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Constrained Messaging Protocol (CMP) . . . . . . . . . . . . . 3 3.1. Protocol fields . . . . . . . . . . . . . . . . . . . . . 4 3.2. Endpoint turn . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Endpoint local variables . . . . . . . . . . . . . . . . . 5 3.4. Datagram types and messages . . . . . . . . . . . . . . . 6 3.4.1. Reset (RST) . . . . . . . . . . . . . . . . . . . . . 6 3.4.2. Interrogative (INT) . . . . . . . . . . . . . . . . . 6 3.4.3. Exclamative (EXC) . . . . . . . . . . . . . . . . . . 7 3.4.4. Partial (PAR) . . . . . . . . . . . . . . . . . . . . 7 3.4.5. Acknowledgment (ACK) . . . . . . . . . . . . . . . . . 8 3.4.6. Keep-alive (KPA) . . . . . . . . . . . . . . . . . . . 8 3.5. Sequence number . . . . . . . . . . . . . . . . . . . . . 9 4. Session handling . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Matching active sessions . . . . . . . . . . . . . . . . . 10 5. Delayed acknowledging . . . . . . . . . . . . . . . . . . . . 11 6. Datagram retransmission . . . . . . . . . . . . . . . . . . . 11 7. Datagram duplication . . . . . . . . . . . . . . . . . . . . . 11 8. Out-of-order message delivery . . . . . . . . . . . . . . . . 12 9. Congestion control . . . . . . . . . . . . . . . . . . . . . . 12 10. Multi-datagram messaging . . . . . . . . . . . . . . . . . . . 13 11. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. Protocol constants . . . . . . . . . . . . . . . . . . . . . . 13 13. CoAP header format over UDP+CMP and over TCP . . . . . . . . . 14 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 15. Security considerations . . . . . . . . . . . . . . . . . . . 19 16. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 18.1. Normative References . . . . . . . . . . . . . . . . . . . 20 18.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Castellani Expires September 8, 2011 [Page 2] Internet-Draft Constrained Messaging Protocol March 2011 1. Introduction Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] design is focused on defining a REST protocol for constrained devices. During the process of defining the CoAP protocol, a complementary effort has been devoted to the definition of an appropriate "message"-layer, providing basic transport features to facilitate the CoAP protocol design. 2. Motivation The motivation of this document has been to provide a more clear "message"-layer definition and to add more features to it. In order to maximize the reusability of this work and to provide a more clear definition of the trasport features, protocol definition has been specified separately from CoAP. Transport relevant for CoAP is specified in this document as an UDP protocol extension called Constrained Messaging Protocol (CMP). CMP design is based upon the "message"-layer defined in CoAP, to which the following features have been added: o multiple message session handling; o multi-datagram message transport; o clear session termination definition; o partly ordered delivery of unconfirmed messages. These features are especially of interest in the realization of advanced features of CoAP, i.e. [I-D.ietf-core-block] and [I-D.ietf-core-observe]. Thanks to the more general scope of this specification, it provides also a more clear definition of transport features already introduced in CoAP. Parts of the text present in [I-D.ietf-core-coap] is reusable in CMP, that parts have been explicitly referenced in this specification. 3. Constrained Messaging Protocol (CMP) Constrained Messaging Protocol (CMP) is an UDP protocol extension intended to reliably or unreliably transport messages from an endpoint to another, and to unreliably transmit messages to a multicast destination. Castellani Expires September 8, 2011 [Page 3] Internet-Draft Constrained Messaging Protocol March 2011 CMP adds the following features on top of UDP: o clear session definition supporting multiple messages; o reliable message transport handling retransmissions and network duplication; o unreliable message transport partly handling duplication and out- of-order delivery; o reliable message fragmentation in multiple UDP datagrams. Differently from TCP segments, using CMP no more than one datagram can be reliably transmitted in a single round-trip time. This important limitation is the main difference between UDP+CMP and TCP and leads to a simpler protocol design, specifically intended to allow its implementation even on very constrained devices. 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 [RFC2119]. Along the CMP specification some terms have a specific meaning: Datagram: input received by the UDP layer. Message: output provided to the higher-layer. A single message can be formed by multiple datagrams. Some datagrams are called "transparent" to the higher-layer, thus do not generate a message. See Section 3.4 for more details about which datagrams generate higher-layer messages. CMP specification is carried in two distinct phases, the whole protocol is defined in terms of the fields required for operation. Required fields are discussed in Section 3.1. Fields mapping to CoAP header has lower relevance to the protocol specification, and is discussed in Section 13. 3.1. Protocol fields CMP requires the following fields for operation: Datagram type (T): 2-bit unsigned integer. Indicates if this datagram is of type Interrogative (0), Exclamative (1), Partial (2) or Reset (3). See Section 3.4 for the semantics of this datagram types. Castellani Expires September 8, 2011 [Page 4] Internet-Draft Constrained Messaging Protocol March 2011 More messages (M): 1-bit boolean. Indicates that the endpoint has more messages pending for this session. Sequence number (Seq): K-bit unsigned integer. Indicates the sequence number of the datagram in the session. Sequence number size (K) does not change the protocol specification as long as K is higher than 2. If K is equal to 1, the protocol is still valid but has limited capabilities out-of-order handling capabilities. Performance and validity of the specified protocol depending upon the actual value of K requires deeper investigation currently not present in this version of the document. Some considerations on this topic follow. When K is small, unreliable message duplication or out-of-order delivery can occur more easily. Reliable message delivery is always in-order. Reliable message duplication is easier when K is smaller, e.g. late network duplication or intentional duplication by a malicious node. When K is small, reliable message duplication (even if very unlikely) can occur more easily. 3.2. Endpoint turn CMP introduces the concept of "in turn" endpoint. An endpoint is said to be "in turn" if it has the ability to reliably send a message. Endpoints not "in turn" can only send unreliable messages. In any session, the client always starts "in turn". The turn is passed to the other endpoint sending a reliable message or sending the last message in the session. Detailed rules for turn handling are discussed in the following sections. 3.3. Endpoint local variables CMP endpoints MUST internally keep the following variables related to the Seq field: iSeq: is the last reliable message sequence number known by an Castellani Expires September 8, 2011 [Page 5] Internet-Draft Constrained Messaging Protocol March 2011 endpoint. eSeq: is the last message sequence number known by an endpoint (both reliable and unreliable). Only endpoints "in turn" can emit sequence numbered messages. Endpoints not "in turn" can emit only unreliable messages, Seq field of those messages MUST be ignored. 3.4. Datagram types and messages Each unique non-empty Interrogative (INT) or Exclamative (EXC) datagram always corresponds to a unique message. Empty INT or EXC datagrams do not generate any message. Partial (PAR) or Reset (RST) datagrams do not generate any message. Even if non-empty PAR datagrams do not generate any message, their content is always part of a message corresponding to the INT datagram emitted after a set of PAR datagram(s). Network duplication or retransmissions can generate multiple identical datagrams: rules to avoid message duplication are discussed in Section 7. The type of a datagram is specified by the T field of the CMP header. The different types of datagrams are summarized below. 3.4.1. Reset (RST) A RST datagram is used by an endpoint to abruptly close a session. When a RST is received by an endpoint, it MUST immediately consider the session as closed. 3.4.2. Interrogative (INT) Some messages require to receive a response or at least an acknowledgment by the other endpoint. These messages MUST be trasmitted using INT datagrams and are called INT messages. A unique message is generated by each unique INT datagram. Endpoints MUST NOT emit more than one INT message before receiving at least one INT datagram (even empty) from the other endpoint. The current endpoint able to send the INT datagram is called "in Castellani Expires September 8, 2011 [Page 6] Internet-Draft Constrained Messaging Protocol March 2011 turn". When it emits one INT datagram it passes the turn to the other endpoint. At any time there is only one endpoint "in turn". When the session is started, the client is "in turn". An endpoint emitting a non-empty INT datagram MUST increase iSeq by 1, MUST set eSeq to iSeq and MUST set Seq field accordingly. Empty INT datagrams MUST be emitted with Seq field set to iSeq. An endpoint can pass the turn to the other endpoint by trasmitting an INT datagram (even empty). INT datagrams can be retrasmitted. Thus multiple identical datagrams corresponding to the same message could be emitted. Retransmission rules are discussed in Section 6. If an "in turn" endpoint receives either an INT or PAR datagram, it MUST ignore that datagram. 3.4.3. Exclamative (EXC) Some messages do not require to receive a response nor an acknowledgment from the other endpoint. These messages SHOULD be transmitted using EXC datagrams and are called EXC messages. An unique message is generated by each unique EXC datagram. Differently from INT datagrams, EXC datagrams can be emitted with lower restrictions by an endpoint. An "in turn" endpoint emitting non-empty EXC datagram MUST increase eSeq by 1 and set Seq field to eSeq, empty EXC datagrams MUST be emitted with Seq field set to eSeq. Moreover not "in turn" endpoints MUST always set Seq field to iSeq. Because of the implicitly unruled nature of this message type, in order to avoid congestion collapse, endpoints emitting EXC messages MUST limit their output rate to a value known to be suitable along the whole network path. If an "in turn" endpoint emits an EXC datagram with M=0, the turn is passed to the other endpoint. 3.4.4. Partial (PAR) Some messages do not fit into a single datagram. Large messages can be fragmented into multiple PAR datagrams. These messages are a special class of INT messages and are called fragmented INT messages. Castellani Expires September 8, 2011 [Page 7] Internet-Draft Constrained Messaging Protocol March 2011 A multi-datagram message is formed by the concatenation of a set of PAR messages, except its final part that MUST be trasmitted using an INT message type. An endpoint to emit a PAR datagram MUST be "in turn". An endpoint emitting a non-empty PAR datagram MUST increase iSeq by 1 and set Seq field to iSeq, empty PAR datagrams MUST be emitted with Seq field set to iSeq. Endpoints MUST NOT emit more than one PAR datagram before receiving an empty PAR message from the other endpoint. An empty PAR message serves as an acknowledgment of the reception of the current part. Handling of PAR messages is not mandatory, endpoints not supporting this datagram type MUST immediately send a RST datagram to the other endpoint. 3.4.5. Acknowledgment (ACK) Differently from INT, EXC, PAR and RST datagrams, ACK datagrams are not an explicit datagram type. An ACK datagram acknowledges a message transported in an INT datagram. Any datagram of type INT, EXC or PAR emitted after reception of an INT datagram assumes the role of ACK datagram. To successfully acknowledge a message, the Seq field contained in the ACK: o MUST be equal to iSeq, if the ACK is an empty datagram; o MUST be equal to iSeq+1, if the ACK is a non-empty datagram. 3.4.6. Keep-alive (KPA) Also KPA datagrams are not an explicit datagram type. A KPA datagram is an empty PAR message with Seq set to iSeq. A KPA datagram is used to ping the other endpoint, either to check that the remote session is still alive or to refresh any soft state along the network path. When a KPA datagram is received on an open session, if Seq is equal to iSeq, the endpoint MUST send an identical datagram to the other endpoint. Castellani Expires September 8, 2011 [Page 8] Internet-Draft Constrained Messaging Protocol March 2011 3.5. Sequence number Every endpoint keeps track of the Seq field, using two different local variables iSeq and eSeq. Client endpoint, before sending the first message, SHOULD initialize iSeq and eSeq to the same random value. "In turn" endpoints MUST NOT update iSeq and eSeq when receiving a datagram. Not "in turn" endpoints MUST NOT update iSeq and eSeq when sending a datagram. At every received non-empty PAR or INT datagram, if Seq field in the received datagram is equal to iSeq+1, a not "in turn" endpoint MUST set iSeq to that value. At every received datagram, if Seq field in the received datagram is equal to iSeq+1, a not "in turn" endpoint MUST set eSeq to that value. There are more rules for updating the eSeq variable, these rules are related with out-of-order reception of datagrams and are described in Section 8. When a non-empty PAR, EXC or INT datagram is to be sent by an "in turn" endpoint, iSeq MUST be increased by 1, eSeq set to iSeq and Seq field set accordingly. When a non-empty EXC datagram is to be sent by an "in turn" endpoint, eSeq MUST be increased by 1 and Seq field set accordingly. 4. Session handling CMP client session MUST be opened when sending a message to a server. The client MUST select a locally unused source UDP port. CMP server session SHOULD be opened when receiving a message from a client from a remotely unused source UDP port. If a server cannot open a new session, it MUST immediately send a RST datagram to the client. A CMP session can be closed either by agreed termination, by arbitrary reset, by endpoint drop or by timeout. A CMP session is called "terminated" or "closed by agreement" and MUST be closed when all the following conditions are verified: Castellani Expires September 8, 2011 [Page 9] Internet-Draft Constrained Messaging Protocol March 2011 o Last received datagram has field M=0; o Last sent datagram has field M=0; o Last datagram (either sent or received) is of type EXC. A CMP session is called "reset" or "closed by reset" and MUST be closed when an endpoint sends or receives a RST datagram. A CMP session is called "dropped" or "closed by drop" and MUST be closed when an endpoint receives no acknowledge to an INT (or PAR) datagram even after MAX_RETRANSMIT retransmissions. A CMP session is called "timed-out", if no message has been exchanged during CMP_TIMEOUT seconds and SHOULD be closed. Before closing the session the endpoint timing out SHOULD send a KPA datagram to the other endpoint. If no ACK is received back, the already "timed-out" session is also in state "dropped" and MUST be closed. The endpoint sending the last ACK datagram in a session closed by agreement, MUST keep the session CLOSING state for RESPONSE_TIMEOUT^(MAX_RETRANSMIT-1) seconds. The client endpoint MUST NOT reuse the same UDP source port used for a previous session before CMP_TIMEOUT seconds have passed after that session has been closed. 4.1. Matching active sessions Assuming that between two hosts (IPs) there can exist at most one session between two specific UDP ports, protocol session matching can be performed without any further addition on the upper layer protocol. In a client/server protocol the server is usually spawned on a static port. However, even using a static server port, session matching is still feasible as long as concurrently active clients on a host can use different source ports. E.g. TCP successfully performs session matching using source/ destination IP and port. Thus, to successfully perform session matching, as described in this section, it is sufficient that the following synthetic condition is verified: At any time, there MUST NOT exist two or more concurrent sessions having all the listed parameters equal between themselves: ( source IP, source UDP port, destination IP, destination UDP port ) Castellani Expires September 8, 2011 [Page 10] Internet-Draft Constrained Messaging Protocol March 2011 5. Delayed acknowledging After receiving a new message in an INT datagram, the endpoint SHOULD wait ACK_TIMEOUT seconds before sending the related ACK datagram. If the upper-layer provides a new message during this period of time, the new message will be sent immediately piggybacking an ACK to the previous INT datagram. If the upper-layer has already signaled to the CMP layer that it has no more messages pending in this session, an empty ACK datagram MUST be sent immediately: o Using an EXC datagram, if the acked datagram has M=0; o Using an INT datagram, if the acked datagram has M=1. 6. Datagram retransmission Retransmissions are handled as defined in Section 4.1 of [I-D.ietf-core-coap], for convenience a synthetic description of these rules follows. An endpoint sending an INT (or PAR) datagram MUST set the session retransmit counter to 0 and MUST start the retransmit timeout. The retransmit timeout duration is always equal to RESPONSE_TIMEOUT^(retransmit counter). When an ACK datagram for the sent INT (or PAR) datagram has been received, the retransmit timeout MUST be stopped. When the retransmit timeout is triggered, the retransmit counter MUST be increased by 1 and depending upon the retransmit counter value one the following actions MUST be done: If the retransmit counter is less than MAX_RETRANSMIT, the involved INT (or PAR) datagram MUST be sent again and the retransmit timeout MUST be restarted. Otherwise if the retransmit counter is equal to MAX_RETRANSMIT, the message is dropped and the related session MUST be closed. Higher- layer SHOULD be notified that the message has been dropped. 7. Datagram duplication Thanks to the reliable nature of INT messages, duplication of these messages can be avoided by handling datagram duplication. Castellani Expires September 8, 2011 [Page 11] Internet-Draft Constrained Messaging Protocol March 2011 Not "in turn" endpoints MUST NOT accept non-empty INT or PAR datagrams with Seq field not equal to iSeq+1 and MUST NOT accept empty INT or PAR datagrams with Seq field equal to iSeq. "In turn" endpoint MUST NOT accept INT or PAR datagrams. Due to unreliable nature of EXC messages, duplication of these messages can only be partly avoided. Endpoints SHOULD NOT deliver to the upper layer two EXC messages with identical UDP checksum within DUP_TIMEOUT seconds. "In turn" endpoints MAY relax this condition and deliver every EXC message received, not "in turn" endpoints emit EXC messages with identical Seq field (easier UDP checksum collision). 8. Out-of-order message delivery There is either zero or one INT message in transit between two endpoints, for this reason INT messages are never delivered out-of- order. Out-of-order delivery of EXC messages emitted by "in turn" endpoints can be partly handled. If a not "in turn" endpoint receives a non-empty EXC datagram with Seq field: o between eSeq+2 and eSeq+2^(K-1), the datagram SHOULD be queued for delivery for OOO_TIMEOUT seconds, when the OOO_TIMEOUT timer expires the message SHOULD be delivered to the upper-layer; o equal to eSeq+1, the contained message MUST be delivered immediately to the upper-layer and if a datagram queued with Seq field equal eSeq+1 is present, it is dequeued and processed as if it was just received; o between eSeq-2^(K-1)+1 and eSeq, it is probably an out-of-order older message and, depending upon applications, MAY be delivered to the upper-layer or dropped. Out-of-order delivery of EXC messages emitted by not "in turn" endpoints cannot be handled at all. Applications sensible to out-of- order delivery SHOULD avoid using EXC messages when not "in turn". 9. Congestion control As noted in Section 4.5 of [I-D.ietf-core-coap], basic congestion control is provided by the retransmission exponential back-off synthesized in Section 6 and further discussion on congestion control Castellani Expires September 8, 2011 [Page 12] Internet-Draft Constrained Messaging Protocol March 2011 can be found in [I-D.eggert-core-congestion-control]. 10. Multi-datagram messaging Some message requires to be fragmented in many datagrams, these messages can be only transmitted as INT messages. Every fragment of the message MUST be sent in order using PAR datagrams, except the last fragment which MUST be sent in an INT datagram. After emitting a new fragment the endpoint MUST wait that the previous fragment has been acknowledged with an empty PAR datagram. If the endpoint does not receive an empty PAR datagram within RESPONSE_TIMEOUT seconds, retransmission rules discussed in Section 6 apply. An endpoint can close at any time a multi-datagram exchange by emitting a RST datagram (e.g. out-of-memory). Multi-datagram messages can be emitted only if "in turn". 11. Multicast Only EXC messages MUST be sent to a multicast address. Congestion control for multicast communication is not defined in this document. For this reason endpoints MAY NOT support multicast communication thus multicast messages MUST be emitted at a very limited rate to avoid congestion collapse in the constrained network. Even if the protocol definition could be easily extended to support reliable multicast message transport, the implication of this on network congestion have to be deeply analyzed before defining this behaviour. 12. Protocol constants This section defines the relevant protocol constants defined in this document. ACK_TIMEOUT 0.2 seconds DUP_TIMEOUT 5 seconds Castellani Expires September 8, 2011 [Page 13] Internet-Draft Constrained Messaging Protocol March 2011 OOO_TIMEOUT 2 seconds CMP_TIMEOUT 120 seconds RESPONSE_TIMEOUT and MAX_RETRANSMIT are defined in Section 9 of [I-D.ietf-core-coap] and reported here for convenience of reading: RESPONSE_TIMEOUT 2 seconds MAX_RETRANSMIT 4 13. CoAP header format over UDP+CMP and over TCP The protocol defined in the previous Sections can be easily plugged into the current CoAP design. Figure 1 shows the final CoAP/UDP+CMP design. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| A | T |M| Seq | AC | OC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: CoAP/UDP+CMP header format The definition of Ver and OC fields described in Section 3.1 of [I-D.ietf-core-coap] is not changed. The definition of fields A and AC described in Section 3.2 and 3.2.1 of [I-D.castellani-core-coap-overhead] is not changed. The definition of fields T, M and Seq described in Section 3 is not changed. The whole REST protocol semantics and specification described in [I-D.ietf-core-coap] is still valid for CoAP/CMP. Using a CMP transport protocol extension for UDP, allows also to easily define how CoAP can be trasported over TCP. A proposal for CoAP/TCP header format is shown in Figure 2. Castellani Expires September 8, 2011 [Page 14] Internet-Draft Constrained Messaging Protocol March 2011 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| A |C| Len | AC | OC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: CoAP/TCP header format The definition of fields already present in Figure 2 is not changed. The new field Len is defined as follows: Concatenate messages (C): 1-bit unsigned integer. This field indicates whether the current message should wait for more fragments. Message lenght (Len): 10-bit unsigned integer. This field indicates the total length of the CoAP message. If C=0 the message is completed, otherwise if C=1 the message is not completed and more fragments will follow. The whole message is the result of the concatenation of all the fragments. Thus until a message with C=0 is received, the message MUST NOT be processed. Ver, A, AC and OC are present in every fragment, to avoid confusion only the value present in the first fragment MUST be processed. 14. Examples A lot of examples of CMP can be realized, however only a small set is provided in the current version of this document. More examples will be provided in a planned version of this document. Even if CMP design is more general, the proposed examples are focused on its application to CoAP. Examples of retransmissions, duplication and out-of-order handling are not present in the current version of this document, but are intended to be presented in a future version. For easier reading Seq field has always been initialized to 1. The current turn before and after the datagram is explicitly indicated using turn=A->B, where A is the turn before the datagram, and B the turn after the datagram. B=X means that no endpoint is in Castellani Expires September 8, 2011 [Page 15] Internet-Draft Constrained Messaging Protocol March 2011 turn, this happens when the session is closed. Figure 3 shows a very simple exchange, where a client reliably transmits a message to a server. C S | | | INT, M=0, Seq=1, "AAA" | turn=C->S |------------------------->| | | | EXC, M=0, Seq=1 | turn=S->X, ACK |<-------------------------| Figure 3: Single INT message, no response Figure 4 shows a typical CoAP request/immediate-response exchange, the client reliably transmits a request to a server, which sends immediately back an unreliable response. C S | | | INT, M=0, Seq=1, "AAA" | turn=C->S |------------------------->| | | | EXC, M=0, Seq=2, "BBB" | turn=S->X, ACK |<-------------------------| Figure 4: Single INT request, single EXC response Figure 5 shows a typical CoAP request/deferred-response exchange, the client reliably transmits a request to a server, which later sends reliably back a response. Castellani Expires September 8, 2011 [Page 16] Internet-Draft Constrained Messaging Protocol March 2011 C S | | | INT, M=0, Seq=1, "AAA" | turn=C->S |------------------------->| | | | EXC, M=1, Seq=1 | turn=S->S, ACK |<-------------------------| | | | INT, M=0, Seq=2, "BBB" | turn=S->C |<-------------------------| | | | EXC, M=0, Seq=2 | turn=C->X |------------------------->| Figure 5: Single INT request, deferred INT response Figure 6 shows a server sending back a multi-datagram response. C S | | | INT, M=0, Seq=1, "AAA" | turn=C->S |------------------------->| | | | PAR, M=0, Seq=2, "B" | turn=S->S, ACK |<-------------------------| | | | PAR, M=0, Seq=2 | turn=S->S, ACK |------------------------->| | | | PAR, M=0, Seq=3, "B" | turn=S->S |<-------------------------| | | | PAR, M=0, Seq=3 | turn=S->S, ACK |------------------------->| | | | INT, M=0, Seq=4, "B" | turn=S->C |<-------------------------| | | | EXC, M=0, Seq=4 | turn=C->X, ACK |------------------------->| Figure 6: Single INT request, single multi-datagram INT response Figure 7 shows a client sending a multi-datagram request. Castellani Expires September 8, 2011 [Page 17] Internet-Draft Constrained Messaging Protocol March 2011 C S | | | PAR, M=0, Seq=1, "A" | turn=C->C |------------------------->| | | | PAR, M=1, Seq=1 | turn=C->C, ACK |<-------------------------| | | | PAR, M=0, Seq=2, "A" | turn=C->C |------------------------->| | | | PAR, M=1, Seq=2 | turn=C->C, ACK |<-------------------------| | | | INT, M=0, Seq=3, "A" | turn=C->S |------------------------->| | | | EXC, M=0, Seq=4, "BBB" | turn=S->X, ACK |<-------------------------| Figure 7: Single multi-datagram INT request, single EXC response Figure 8 shows a typical CoAP observe session, the client reliably transmits a request to a server, which starts sending infrequent messages back to the client. C S | | | INT, M=0, Seq=1, "AAA" | turn=C->S |------------------------->| | | | EXC, M=1, Seq=2, "BBB" | turn=S->S, ACK |<-------------------------| | | | EXC, M=1, Seq=3, "CCC" | turn=S->S |<-------------------------| | | | EXC, M=1, Seq=4, "DDD" | turn=S->S |<-------------------------| | | | INT, M=0, Seq=2, "EEE" | turn=S->C |<-------------------------| | | | EXC, M=0, Seq=2 | turn=C->X, ACK |------------------------->| Castellani Expires September 8, 2011 [Page 18] Internet-Draft Constrained Messaging Protocol March 2011 Figure 8: Single INT request, multiple EXC or INT responses Figure 9 shows a typical CoAP multicast request/response, the client sends an unreliable request to a multicast address, all the servers bound to that address will send back an unreliable response. C S1 S2 S3 | | | | | EXC, M=0, Seq=1, "AAA" | | | turn=C->Sk |------------------------->|--->|--->| | | | | | EXC, M=0, Seq=2, "BBB" | | | turn=Sk->X |<-------------------------| | | | | | | | EXC, M=0, Seq=2, "CCC" | | | turn=Sk->X |<------------------------------| | | | | | | EXC, M=0, Seq=2, "DDD" | | | turn=Sk->X |<-----------------------------------| Figure 9: Single multicast EXC request, multiple EXC responses 15. Security considerations TBD 16. IANA considerations TBD 17. Acknowledgements Special thanks to Nicola Bui, Michele Zorzi and Mattia Gheda for the extensive discussions on this protocol, for their support and contributions. The author of this document relied upon the extensive work done by the members of CoRE working-group. Especially the work done by the editors and contributors of [I-D.ietf-core-coap], in particular the extensive analysis of issues and techniques strictly related to this document and also for the definitions this document shares with [I-D.ietf-core-coap]. Castellani Expires September 8, 2011 [Page 19] Internet-Draft Constrained Messaging Protocol March 2011 18. References 18.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-04 (work in progress), January 2011. [I-D.castellani-core-coap-overhead] Castellani, A., "CoAP overhead: protocol analysis and reduction proposals", draft-castellani-core-coap-overhead-00 (work in progress), February 2011. 18.2. Informative References [I-D.ietf-core-block] Shelby, Z. and C. Bormann, "Blockwise transfers in CoAP", draft-ietf-core-block-01 (work in progress), January 2011. [I-D.ietf-core-observe] Hartke, K. and Z. Shelby, "Observing Resources in CoAP", draft-ietf-core-observe-01 (work in progress), February 2011. [I-D.eggert-core-congestion-control] Eggert, L., "Congestion Control for the Constrained Application Protocol (CoAP)", draft-eggert-core-congestion-control-01 (work in progress), January 2011. Author's Address Angelo P. Castellani University of Padova Via G. Gradenigo 6/B Padova 35131 Italy Email: angelo@castellani.net Castellani Expires September 8, 2011 [Page 20]