RFC 7252
The Constrained Application Protocol (CoAP)
3. Message Format
CoAP is based on the exchange of compact messages that, by default, are transported over UDP (i.e., each CoAP message occupies the data section of one UDP datagram). CoAP may also be used over Datagram Transport Layer Security (DTLS) (see Section 9.1). It could also be used over other transports such as SMS, TCP, or SCTP, the specification of which is out of this document's scope. (UDP-lite [RFC3828] and UDP zero checksum [RFC6936] are not supported by CoAP.) CoAP messages are encoded in a simple binary format. The message format starts with a fixed-size 4-byte header. This is followed by a variable-length Token value, which can be between 0 and 8 bytes long.
Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Message Format The fields in the header are defined as follows: Version (Ver): 2-bit unsigned integer. Indicates the CoAP version number. Implementations of this specification MUST set this field to 1 (01 binary). Other values are reserved for future versions. Messages with unknown version numbers MUST be silently ignored. Type (T): 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3). The semantics of these message types are defined in Section 4. Token Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format error. Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits), documented as "c.dd" where "c" is a digit from 0 to 7 for the 3-bit subfield and "dd" are two digits from 00 to 31 for the 5-bit subfield. The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.) As a special case, Code 0.00 indicates an Empty message. In case of a request, the Code field indicates the Request Method; in case of a response, a Response Code. Possible values are maintained in the CoAP Code Registries (Section 12.1). The semantics of requests and responses are defined in Section 5.
Message ID: 16-bit unsigned integer in network byte order. Used to
detect message duplication and to match messages of type
Acknowledgement/Reset to messages of type Confirmable/Non-
confirmable. The rules for generating a Message ID and matching
messages are defined in Section 4.
The header is followed by the Token value, which may be 0 to 8 bytes,
as given by the Token Length field. The Token value is used to
correlate requests and responses. The rules for generating a Token
and correlating requests and responses are defined in Section 5.3.1.
Header and Token are followed by zero or more Options (Section 3.1).
An Option can be followed by the end of the message, by another
Option, or by the Payload Marker and the payload.
Following the header, token, and options, if any, comes the optional
payload. If present and of non-zero length, it is prefixed by a
fixed, one-byte Payload Marker (0xFF), which indicates the end of
options and the start of the payload. The payload data extends from
after the marker to the end of the UDP datagram, i.e., the Payload
Length is calculated from the datagram size. The absence of the
Payload Marker denotes a zero-length payload. The presence of a
marker followed by a zero-length payload MUST be processed as a
message format error.
Implementation Note: The byte value 0xFF may also occur within an
option length or value, so simple byte-wise scanning for 0xFF is
not a viable technique for finding the payload marker. The byte
0xFF has the meaning of a payload marker only where the beginning
of another option could occur.
3.1. Option Format
CoAP defines a number of options that can be included in a message.
Each option instance in a message specifies the Option Number of the
defined CoAP option, the length of the Option Value, and the Option
Value itself.
Instead of specifying the Option Number directly, the instances MUST
appear in order of their Option Numbers and a delta encoding is used
between them: the Option Number for each instance is calculated as
the sum of its delta and the Option Number of the preceding instance
in the message. For the first instance in a message, a preceding
option instance with Option Number zero is assumed. Multiple
instances of the same option can be included by using a delta of
zero.
Option Numbers are maintained in the "CoAP Option Numbers" registry (Section 12.2). See Section 5.4 for the semantics of the options defined in this document. 0 1 2 3 4 5 6 7 +---------------+---------------+ | | | | Option Delta | Option Length | 1 byte | | | +---------------+---------------+ \ \ / Option Delta / 0-2 bytes \ (extended) \ +-------------------------------+ \ \ / Option Length / 0-2 bytes \ (extended) \ +-------------------------------+ \ \ / / \ \ / Option Value / 0 or more bytes \ \ / / \ \ +-------------------------------+ Figure 8: Option Format The fields in an option are defined as follows: Option Delta: 4-bit unsigned integer. A value between 0 and 12 indicates the Option Delta. Three values are reserved for special constructs: 13: An 8-bit unsigned integer follows the initial byte and indicates the Option Delta minus 13. 14: A 16-bit unsigned integer in network byte order follows the initial byte and indicates the Option Delta minus 269. 15: Reserved for the Payload Marker. If the field is set to this value but the entire byte is not the payload marker, this MUST be processed as a message format error.
The resulting Option Delta is used as the difference between the
Option Number of this option and that of the previous option (or
zero for the first option). In other words, the Option Number is
calculated by simply summing the Option Delta values of this and
all previous options before it.
Option Length: 4-bit unsigned integer. A value between 0 and 12
indicates the length of the Option Value, in bytes. Three values
are reserved for special constructs:
13: An 8-bit unsigned integer precedes the Option Value and
indicates the Option Length minus 13.
14: A 16-bit unsigned integer in network byte order precedes the
Option Value and indicates the Option Length minus 269.
15: Reserved for future use. If the field is set to this value,
it MUST be processed as a message format error.
Value: A sequence of exactly Option Length bytes. The length and
format of the Option Value depend on the respective option, which
MAY define variable-length values. See Section 3.2 for the
formats used in this document; options defined in other documents
MAY make use of other option value formats.
3.2. Option Value Formats
The options defined in this document make use of the following option
value formats.
empty: A zero-length sequence of bytes.
opaque: An opaque sequence of bytes.
uint: A non-negative integer that is represented in network byte
order using the number of bytes given by the Option Length
field.
An option definition may specify a range of permissible
numbers of bytes; if it has a choice, a sender SHOULD
represent the integer with as few bytes as possible, i.e.,
without leading zero bytes. For example, the number 0 is
represented with an empty option value (a zero-length
sequence of bytes) and the number 1 by a single byte with
the numerical value of 1 (bit combination 00000001 in most
significant bit first notation). A recipient MUST be
prepared to process values with leading zero bytes.
Implementation Note: The exceptional behavior permitted
for the sender is intended for highly constrained,
templated implementations (e.g., hardware
implementations) that use fixed-size options in the
templates.
string: A Unicode string that is encoded using UTF-8 [RFC3629] in
Net-Unicode form [RFC5198].
Note that here, and in all other places where UTF-8
encoding is used in the CoAP protocol, the intention is
that the encoded strings can be directly used and compared
as opaque byte strings by CoAP protocol implementations.
There is no expectation and no need to perform
normalization within a CoAP implementation (except where
Unicode strings that are not known to be normalized are
imported from sources outside the CoAP protocol). Note
also that ASCII strings (that do not make use of special
control characters) are always valid UTF-8 Net-Unicode
strings.
4. Message Transmission
CoAP messages are exchanged asynchronously between CoAP endpoints.
They are used to transport CoAP requests and responses, the semantics
of which are defined in Section 5.
As CoAP is bound to unreliable transports such as UDP, CoAP messages
may arrive out of order, appear duplicated, or go missing without
notice. For this reason, CoAP implements a lightweight reliability
mechanism, without trying to re-create the full feature set of a
transport like TCP. It has the following features:
o Simple stop-and-wait retransmission reliability with exponential
back-off for Confirmable messages.
o Duplicate detection for both Confirmable and Non-confirmable
messages.
4.1. Messages and Endpoints
A CoAP endpoint is the source or destination of a CoAP message. The
specific definition of an endpoint depends on the transport being
used for CoAP. For the transports defined in this specification, the
endpoint is identified depending on the security mode used (see
Section 9): With no security, the endpoint is solely identified by an
IP address and a UDP port number. With other security modes, the
endpoint is identified as defined by the security mode.
There are different types of messages. The type of a message is specified by the Type field of the CoAP Header. Separate from the message type, a message may carry a request, a response, or be Empty. This is signaled by the Request/Response Code field in the CoAP Header and is relevant to the request/response model. Possible values for the field are maintained in the CoAP Code Registries (Section 12.1). An Empty message has the Code field set to 0.00. The Token Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. If there are any bytes, they MUST be processed as a message format error.4.2. Messages Transmitted Reliably
The reliable transmission of a message is initiated by marking the message as Confirmable in the CoAP header. A Confirmable message always carries either a request or response, unless it is used only to elicit a Reset message, in which case it is Empty. A recipient MUST either (a) acknowledge a Confirmable message with an Acknowledgement message or (b) reject the message if the recipient lacks context to process the message properly, including situations where the message is Empty, uses a code with a reserved class (1, 6, or 7), or has a message format error. Rejecting a Confirmable message is effected by sending a matching Reset message and otherwise ignoring it. The Acknowledgement message MUST echo the Message ID of the Confirmable message and MUST carry a response or be Empty (see Sections 5.2.1 and 5.2.2). The Reset message MUST echo the Message ID of the Confirmable message and MUST be Empty. Rejecting an Acknowledgement or Reset message (including the case where the Acknowledgement carries a request or a code with a reserved class, or the Reset message is not Empty) is effected by silently ignoring it. More generally, recipients of Acknowledgement and Reset messages MUST NOT respond with either Acknowledgement or Reset messages. The sender retransmits the Confirmable message at exponentially increasing intervals, until it receives an acknowledgement (or Reset message) or runs out of attempts. Retransmission is controlled by two things that a CoAP endpoint MUST keep track of for each Confirmable message it sends while waiting for an acknowledgement (or reset): a timeout and a retransmission counter. For a new Confirmable message, the initial timeout is set to a random duration (often not an integral number of seconds) between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see Section 4.8), and the retransmission counter is set to 0. When the timeout is triggered and the retransmission counter is less than
MAX_RETRANSMIT, the message is retransmitted, the retransmission counter is incremented, and the timeout is doubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, or if the endpoint receives a Reset message, then the attempt to transmit the message is canceled and the application process informed of failure. On the other hand, if the endpoint receives an acknowledgement in time, transmission is considered successful. This specification makes no strong requirements on the accuracy of the clocks used to implement the above binary exponential back-off algorithm. In particular, an endpoint may be late for a specific retransmission due to its sleep schedule and may catch up on the next one. However, the minimum spacing before another retransmission is ACK_TIMEOUT, and the entire sequence of (re-)transmissions MUST stay in the envelope of MAX_TRANSMIT_SPAN (see Section 4.8.2), even if that means a sender may miss an opportunity to transmit. A CoAP endpoint that sent a Confirmable message MAY give up in attempting to obtain an ACK even before the MAX_RETRANSMIT counter value is reached. For example, the application has canceled the request as it no longer needs a response, or there is some other indication that the CON message did arrive. In particular, a CoAP request message may have elicited a separate response, in which case it is clear to the requester that only the ACK was lost and a retransmission of the request would serve no purpose. However, a responder MUST NOT in turn rely on this cross-layer behavior from a requester, i.e., it MUST retain the state to create the ACK for the request, if needed, even if a Confirmable response was already acknowledged by the requester. Another reason for giving up retransmission MAY be the receipt of ICMP errors. If it is desired to take account of ICMP errors, to mitigate potential spoofing attacks, implementations SHOULD take care to check the information about the original datagram in the ICMP message, including port numbers and CoAP header information such as message type and code, Message ID, and Token; if this is not possible due to limitations of the UDP service API, ICMP errors SHOULD be ignored. Packet Too Big errors [RFC4443] ("fragmentation needed and DF set" for IPv4 [RFC0792]) cannot properly occur and SHOULD be ignored if the implementation note in Section 4.6 is followed; otherwise, they SHOULD feed into a path MTU discovery algorithm [RFC4821]. Source Quench and Time Exceeded ICMP messages SHOULD be ignored. Host, network, port, or protocol unreachable errors or parameter problem errors MAY, after appropriate vetting, be used to inform the application of a failure in sending.
4.3. Messages Transmitted without Reliability
Some messages do not require an acknowledgement. This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor where eventual success is sufficient. As a more lightweight alternative, a message can be transmitted less reliably by marking the message as Non-confirmable. A Non- confirmable message always carries either a request or response and MUST NOT be Empty. A Non-confirmable message MUST NOT be acknowledged by the recipient. A recipient MUST reject the message if it lacks context to process the message properly, including the case where the message is Empty, uses a code with a reserved class (1, 6, or 7), or has a message format error. Rejecting a Non- confirmable message MAY involve sending a matching Reset message, and apart from the Reset message the rejected message MUST be silently ignored. At the CoAP level, there is no way for the sender to detect if a Non- confirmable message was received or not. A sender MAY choose to transmit multiple copies of a Non-confirmable message within MAX_TRANSMIT_SPAN (limited by the provisions of Section 4.7, in particular, by PROBING_RATE if no response is received), or the network may duplicate the message in transit. To enable the receiver to act only once on the message, Non-confirmable messages specify a Message ID as well. (This Message ID is drawn from the same number space as the Message IDs for Confirmable messages.) Summarizing Sections 4.2 and 4.3, the four message types can be used as in Table 1. "*" means that the combination is not used in normal operation but only to elicit a Reset message ("CoAP ping"). +----------+-----+-----+-----+-----+ | | CON | NON | ACK | RST | +----------+-----+-----+-----+-----+ | Request | X | X | - | - | | Response | X | X | X | - | | Empty | * | - | X | X | +----------+-----+-----+-----+-----+ Table 1: Usage of Message Types
4.4. Message Correlation
An Acknowledgement or Reset message is related to a Confirmable message or Non-confirmable message by means of a Message ID along with additional address information of the corresponding endpoint. The Message ID is a 16-bit unsigned integer that is generated by the sender of a Confirmable or Non-confirmable message and included in the CoAP header. The Message ID MUST be echoed in the Acknowledgement or Reset message by the recipient. The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2). Implementation Note: Several implementation strategies can be employed for generating Message IDs. In the simplest case, a CoAP endpoint generates Message IDs by keeping a single Message ID variable, which is changed each time a new Confirmable or Non- confirmable message is sent, regardless of the destination address or port. Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example, per prefix or destination address. (Note that some receiving endpoints may not be able to distinguish unicast and multicast packets addressed to it, so endpoints generating Message IDs need to make sure these do not overlap.) It is strongly recommended that the initial value of the variable (e.g., on startup) be randomized, in order to make successful off-path attacks on the protocol less likely. For an Acknowledgement or Reset message to match a Confirmable or Non-confirmable message, the Message ID and source endpoint of the Acknowledgement or Reset message MUST match the Message ID and destination endpoint of the Confirmable or Non-confirmable message.4.5. Message Deduplication
A recipient might receive the same Confirmable message (as indicated by the Message ID and source endpoint) multiple times within the EXCHANGE_LIFETIME (Section 4.8.2), for example, when its Acknowledgement went missing or didn't reach the original sender before the first timeout. The recipient SHOULD acknowledge each duplicate copy of a Confirmable message using the same Acknowledgement or Reset message but SHOULD process any request or response in the message only once. This rule MAY be relaxed in case the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples for relaxed message deduplication:
o A server might relax the requirement to answer all retransmissions
of an idempotent request with the same response (Section 4.2), so
that it does not have to maintain state for Message IDs. For
example, an implementation might want to process duplicate
transmissions of a GET, PUT, or DELETE request as separate
requests if the effort incurred by duplicate processing is less
expensive than keeping track of previous responses would be.
o A constrained server might even want to relax this requirement for
certain non-idempotent requests if the application semantics make
this trade-off favorable. For example, if the result of a POST
request is just the creation of some short-lived state at the
server, it may be less expensive to incur this effort multiple
times for a request than keeping track of whether a previous
transmission of the same request already was processed.
A recipient might receive the same Non-confirmable message (as
indicated by the Message ID and source endpoint) multiple times
within NON_LIFETIME (Section 4.8.2). As a general rule that MAY be
relaxed based on the specific semantics of a message, the recipient
SHOULD silently ignore any duplicated Non-confirmable message and
SHOULD process any request or response in the message only once.
4.6. Message Size
While specific link layers make it beneficial to keep CoAP messages
small enough to fit into their link-layer packets (see Section 1),
this is a matter of implementation quality. The CoAP specification
itself provides only an upper bound to the message size. Messages
larger than an IP packet result in undesirable packet fragmentation.
A CoAP message, appropriately encapsulated, SHOULD fit within a
single IP packet (i.e., avoid IP fragmentation) and (by fitting into
one UDP payload) obviously needs to fit within a single IP datagram.
If the Path MTU is not known for a destination, an IP MTU of 1280
bytes SHOULD be assumed; if nothing is known about the size of the
headers, good upper bounds are 1152 bytes for the message size and
1024 bytes for the payload size.
Implementation Note: CoAP's choice of message size parameters works
well with IPv6 and with most of today's IPv4 paths. (However,
with IPv4, it is harder to absolutely ensure that there is no IP
fragmentation. If IPv4 support on unusual networks is a
consideration, implementations may want to limit themselves to
more conservative IPv4 datagram sizes such as 576 bytes; per
[RFC0791], the absolute minimum value of the IP MTU for IPv4 is as
low as 68 bytes, which would leave only 40 bytes minus security
overhead for a UDP payload. Implementations extremely focused on
this problem set might also set the IPv4 DF bit and perform some
form of path MTU discovery [RFC4821]; this should generally be
unnecessary in realistic use cases for CoAP, however.) A more
important kind of fragmentation in many constrained networks is
that on the adaptation layer (e.g., 6LoWPAN L2 packets are limited
to 127 bytes including various overheads); this may motivate
implementations to be frugal in their packet sizes and to move to
block-wise transfers [BLOCK] when approaching three-digit message
sizes.
Message sizes are also of considerable importance to
implementations on constrained nodes. Many implementations will
need to allocate a buffer for incoming messages. If an
implementation is too constrained to allow for allocating the
above-mentioned upper bound, it could apply the following
implementation strategy for messages not using DTLS security:
Implementations receiving a datagram into a buffer that is too
small are usually able to determine if the trailing portion of a
datagram was discarded and to retrieve the initial portion. So,
at least the CoAP header and options, if not all of the payload,
are likely to fit within the buffer. A server can thus fully
interpret a request and return a 4.13 (Request Entity Too Large;
see Section 5.9.2.9) Response Code if the payload was truncated.
A client sending an idempotent request and receiving a response
larger than would fit in the buffer can repeat the request with a
suitable value for the Block Option [BLOCK].
4.7. Congestion Control
Basic congestion control for CoAP is provided by the exponential
back-off mechanism in Section 4.2.
In order not to cause congestion, clients (including proxies) MUST
strictly limit the number of simultaneous outstanding interactions
that they maintain to a given server (including proxies) to NSTART.
An outstanding interaction is either a CON for which an ACK has not
yet been received but is still expected (message layer) or a request
for which neither a response nor an Acknowledgment message has yet
been received but is still expected (which may both occur at the same
time, counting as one outstanding interaction). The default value of
NSTART for this specification is 1.
Further congestion control optimizations and considerations are
expected in the future, may for example provide automatic
initialization of the CoAP transmission parameters defined in
Section 4.8, and thus may allow a value for NSTART greater than one.
After EXCHANGE_LIFETIME, a client stops expecting a response to a
Confirmable request for which no acknowledgment message was received.
The specific algorithm by which a client stops to "expect" a response
to a Confirmable request that was acknowledged, or to a Non-
confirmable request, is not defined. Unless this is modified by
additional congestion control optimizations, it MUST be chosen in
such a way that an endpoint does not exceed an average data rate of
PROBING_RATE in sending to another endpoint that does not respond.
Note: CoAP places the onus of congestion control mostly on the
clients. However, clients may malfunction or actually be
attackers, e.g., to perform amplification attacks (Section 11.3).
To limit the damage (to the network and to its own energy
resources), a server SHOULD implement some rate limiting for its
response transmission based on reasonable assumptions about
application requirements. This is most helpful if the rate limit
can be made effective for the misbehaving endpoints, only.
4.8. Transmission Parameters
Message transmission is controlled by the following parameters:
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| ACK_TIMEOUT | 2 seconds |
| ACK_RANDOM_FACTOR | 1.5 |
| MAX_RETRANSMIT | 4 |
| NSTART | 1 |
| DEFAULT_LEISURE | 5 seconds |
| PROBING_RATE | 1 byte/second |
+-------------------+---------------+
Table 2: CoAP Protocol Parameters
4.8.1. Changing the Parameters
The values for ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT,
NSTART, DEFAULT_LEISURE (Section 8.2), and PROBING_RATE may be
configured to values specific to the application environment
(including dynamically adjusted values); however, the configuration
method is out of scope of this document. It is RECOMMENDED that an
application environment use consistent values for these parameters;
the specific effects of operating with inconsistent values in an
application environment are outside the scope of the present
specification.
The transmission parameters have been chosen to achieve a behavior in
the presence of congestion that is safe in the Internet. If a
configuration desires to use different values, the onus is on the
configuration to ensure these congestion control properties are not violated. In particular, a decrease of ACK_TIMEOUT below 1 second would violate the guidelines of [RFC5405]. ([RTO-CONSIDER] provides some additional background.) CoAP was designed to enable implementations that do not maintain round-trip-time (RTT) measurements. However, where it is desired to decrease the ACK_TIMEOUT significantly or increase NSTART, this can only be done safely when maintaining such measurements. Configurations MUST NOT decrease ACK_TIMEOUT or increase NSTART without using mechanisms that ensure congestion control safety, either defined in the configuration or in future standards documents. ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD have a value that is sufficiently different from 1.0 to provide some protection from synchronization effects. MAX_RETRANSMIT can be freely adjusted, but a value that is too small will reduce the probability that a Confirmable message is actually received, while a larger value than given here will require further adjustments in the time values (see Section 4.8.2). If the choice of transmission parameters leads to an increase of derived time values (see Section 4.8.2), the configuration mechanism MUST ensure the adjusted value is also available to all the endpoints with which these adjusted values are to be used to communicate.4.8.2. Time Values Derived from Transmission Parameters
The combination of ACK_TIMEOUT, ACK_RANDOM_FACTOR, and MAX_RETRANSMIT influences the timing of retransmissions, which in turn influences how long certain information items need to be kept by an implementation. To be able to unambiguously reference these derived time values, we give them names as follows: o MAX_TRANSMIT_SPAN is the maximum time from the first transmission of a Confirmable message to its last retransmission. For the default transmission parameters, the value is (2+4+8+16)*1.5 = 45 seconds, or more generally: ACK_TIMEOUT * ((2 ** MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR
o MAX_TRANSMIT_WAIT is the maximum time from the first transmission
of a Confirmable message to the time when the sender gives up on
receiving an acknowledgement or reset. For the default
transmission parameters, the value is (2+4+8+16+32)*1.5 = 93
seconds, or more generally:
ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) *
ACK_RANDOM_FACTOR
In addition, some assumptions need to be made on the characteristics
of the network and the nodes.
o MAX_LATENCY is the maximum time a datagram is expected to take
from the start of its transmission to the completion of its
reception. This constant is related to the MSL (Maximum Segment
Lifetime) of [RFC0793], which is "arbitrarily defined to be 2
minutes" ([RFC0793] glossary, page 81). Note that this is not
necessarily smaller than MAX_TRANSMIT_WAIT, as MAX_LATENCY is not
intended to describe a situation when the protocol works well, but
the worst-case situation against which the protocol has to guard.
We, also arbitrarily, define MAX_LATENCY to be 100 seconds. Apart
from being reasonably realistic for the bulk of configurations as
well as close to the historic choice for TCP, this value also
allows Message ID lifetime timers to be represented in 8 bits
(when measured in seconds). In these calculations, there is no
assumption that the direction of the transmission is irrelevant
(i.e., that the network is symmetric); there is just the
assumption that the same value can reasonably be used as a maximum
value for both directions. If that is not the case, the following
calculations become only slightly more complex.
o PROCESSING_DELAY is the time a node takes to turn around a
Confirmable message into an acknowledgement. We assume the node
will attempt to send an ACK before having the sender time out, so
as a conservative assumption we set it equal to ACK_TIMEOUT.
o MAX_RTT is the maximum round-trip time, or:
(2 * MAX_LATENCY) + PROCESSING_DELAY
From these values, we can derive the following values relevant to the
protocol operation:
o EXCHANGE_LIFETIME is the time from starting to send a Confirmable
message to the time when an acknowledgement is no longer expected,
i.e., message-layer information about the message exchange can be
purged. EXCHANGE_LIFETIME includes a MAX_TRANSMIT_SPAN, a
MAX_LATENCY forward, PROCESSING_DELAY, and a MAX_LATENCY for the
way back. Note that there is no need to consider
MAX_TRANSMIT_WAIT if the configuration is chosen such that the
last waiting period (ACK_TIMEOUT * (2 ** MAX_RETRANSMIT) or the
difference between MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT) is
less than MAX_LATENCY -- which is a likely choice, as MAX_LATENCY
is a worst-case value unlikely to be met in the real world. In
this case, EXCHANGE_LIFETIME simplifies to:
MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) + PROCESSING_DELAY
or 247 seconds with the default transmission parameters.
o NON_LIFETIME is the time from sending a Non-confirmable message to
the time its Message ID can be safely reused. If multiple
transmission of a NON message is not used, its value is
MAX_LATENCY, or 100 seconds. However, a CoAP sender might send a
NON message multiple times, in particular for multicast
applications. While the period of reuse is not bounded by the
specification, an expectation of reliable detection of duplication
at the receiver is on the timescales of MAX_TRANSMIT_SPAN.
Therefore, for this purpose, it is safer to use the value:
MAX_TRANSMIT_SPAN + MAX_LATENCY
or 145 seconds with the default transmission parameters; however,
an implementation that just wants to use a single timeout value
for retiring Message IDs can safely use the larger value for
EXCHANGE_LIFETIME.
Table 3 lists the derived parameters introduced in this subsection
with their default values.
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| MAX_TRANSMIT_SPAN | 45 s |
| MAX_TRANSMIT_WAIT | 93 s |
| MAX_LATENCY | 100 s |
| PROCESSING_DELAY | 2 s |
| MAX_RTT | 202 s |
| EXCHANGE_LIFETIME | 247 s |
| NON_LIFETIME | 145 s |
+-------------------+---------------+
Table 3: Derived Protocol Parameters
(next page on part 3)
