Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7252

The Constrained Application Protocol (CoAP)

Pages: 112
Proposed Standard
Errata
Updated by:  7959861389749175
Part 2 of 6 – Pages 15 to 30
First   Prev   Next

Top   ToC   RFC7252 - Page 15   prevText

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.
Top   ToC   RFC7252 - Page 16
   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.
Top   ToC   RFC7252 - Page 17
   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.
Top   ToC   RFC7252 - Page 18
   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.
Top   ToC   RFC7252 - Page 19
      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.
Top   ToC   RFC7252 - Page 20
             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.
Top   ToC   RFC7252 - Page 21
   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
Top   ToC   RFC7252 - Page 22
   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.
Top   ToC   RFC7252 - Page 23

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
Top   ToC   RFC7252 - Page 24

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:
Top   ToC   RFC7252 - Page 25
   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
Top   ToC   RFC7252 - Page 26
      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.
Top   ToC   RFC7252 - Page 27
   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
Top   ToC   RFC7252 - Page 28
   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
Top   ToC   RFC7252 - Page 29
   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
Top   ToC   RFC7252 - Page 30
      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)

Next Section