tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7252

 
 
 

The Constrained Application Protocol (CoAP)

Part 2 of 6, p. 15 to 30
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part