Opened 13 years ago

Closed 13 years ago

#5 closed protocol enhancement (fixed)

Header improvements

Reported by: zach@… Owned by: zach@…
Priority: minor Milestone:
Component: coap Version:
Severity: - Keywords:
Cc:

Description

In addition to possible ramifications of the Sub/Not? design, there are general header optimizations still to be considered and discussed for coap-01.

  • If possible, the Method or Code field should be part of the first octet of the header. This way a simple comparison of the first octet tells you the version and method/code for an incoming header. The variable fields such as O and A would be included in the second octet along with any other flags.
  • It has been proposed (by Angelo) to move the URI to an integral part of the header instead of an option as it is so common.
  • It has also been proposed to include the Content-Type in the beginning of the payload (first octet?) instead of as an option. Currently Content-Type is 1-2 octets so it would have to be simplified in that case. Currently the Content-Type can be left out in the case of text/plain.
  • Can the option header be somewhat simplified? At least the options could be fixed-length instead of variable length. If the URI went to the base header, then there would no longer be a need for a long length field. Instead length could be limited to 32-bits e.g. as it is crazy for a constrained node to work with anything larger than that anyways.

Change History (1)

comment:1 Changed 13 years ago by zach@…

  • Resolution set to fixed
  • Status changed from new to closed

The coap-01 includes an improved and simplified header structure, was not able to integrate all ideas though. The goal is to absolutely NOT change the base and option header anymore after coap-01.

  • Single byte for indicating methods or response codes. Requires less memory to hold a header structure.
  • Improved option TLV header as per coap-misc.
  • The consensus earlier in the WG was to have flexible options for future extensibility. Thus we chose to keep URIs and content-type as options. The other extreme would have been to remove options almost alltogether.
  • The number,size and complexity of options was reduced.

The new header looks like this:

     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 |  OC   |      Code     |        Transaction ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Header Fields:

      Ver:  Version. 2-bit unsigned integer.  Indicates the version of
         CoAP.  Implementations of this specification MUST set this
         field to 1.  Other values are reserved for future versions.

      T: 2-bit unsigned integer Transaction Type field.  Indicates if
         this message is a CoAP Confirmable (0), Non-Confirmable (1),
         Acknowledgement (2) or Reset (3).

      OC:  4-bit unsigned integer Number of Options field.  Indicates if
         there are Option Headers following the base header.  If set to
         0 the payload (if any) immediately follows the base header.  If
         greater than zero the field indicates the number of options to
         immediately follow the header.  See Section 3.2 below.

      Code:  8-bit unsigned integer.  This field indicates the Method or
         Response Code of a message.  The value 0 indicates no code.
         The values 1-10 are used for Method Codes as defined in
         Table 1.  The values 11-39 are reserved for future use.  The
         values 40-255 are used for Response Codes as defined in
         Section 11.1.

      Transaction ID:  16-bit unsigned integer.  A unique Transaction ID
         assigned by the source and used to match responses.  The
         Transaction ID MUST be changed for each new request (regardless
         of the end-point) and MUST NOT be changed when retransmitting a
         request.

      _: This field is unused.  It MUST be initialized to zero by the
         sender and MUST be ignored by the receiver.

                             +--------+------+
                             | Method | Code |
                             +--------+------+
                             | GET    | 1    |
                             | POST   | 2    |
                             | PUT    | 3    |
                             | DELETE | 4    |
                             +--------+------+

                           Table 1: Method Codes


Note: See TracTickets for help on using tickets.