Constrained Application Protocol: Difference between revisions

Revision as of 14:18, 27 March 2012

Revision as of 19:12, 21 May 2012

Line 2:

{{context|date=August 2011}}

'''Constrained Application Protocol''' (CoAP), is an [[Application layer]] protocol that is intended for use in resource-constrained internet devices, such as [[WSN]] nodes. CoAP is designed to easily translate to [[HTTP]] for simplified integration with the web, while also meeting specialized requirements such as [[multicast]] support, very low overhead, and simplicity. <ref>Constrained Application Protocol (CoAP) draft-shelby-core-coap-09 [https://datatracker.ietf.org/doc/draft-ietf-core-coap/ https://datatracker.ietf.org/doc/draft-ietf-core-coap/Internet Draft describing Constrained Application Protocol (CoAP)]</ref><ref>"[http://hinrg.cs.jhu.edu/joomla/images/stories/IPSN_2011_koliti.pdf Integrating Wireless Sensor Networks with the Web]" , Walter, Colitti 2011</ref> . Multicast, low overhead, and simplicity are extremely important for [[Internet of Things]] (IoT) and [[Machine-to-Machine|M2M]] devices, which tend to be deeply [[Embedded system|embedded]] and have much less memory and power supply than traditional internet devices have. Therefore, efficiency is very important. CoAP can run on most devices that support [[User Datagram Protocol|UDP]] or a UDP analogue.

The Internet Engineering Task Force ([[IETF]]) Constrained [[RESTful]] environments ([[CoRE]]) Working Group has done the major standardization work for this protocol. In order to make the protocol suitable to IoT and M2M applications, various new functionalities have been added <ref>[https://datatracker.ietf.org/wg/core/ The CORE WG's IETF Area]</ref>. This protocol is still under development.

== Features ==

Line 23:

CoAP makes use of two message types, requests and responses, using a simple binary base header format. The base header may be followed by options in ICMP-style Type-Length-Value format. CoAP is by default bound to UDP and optionally to TCP as described in Section 4.

Any bytes after the headers in the packet are considered the message body if any. The length of the message body is implied by the datagram length. When bound to UDP the entire message MUST fit within a single datagram. When used with [[6LoWPAN]] as defined in [RFC4944http://tools.ietf.org/html/rfc4944 RFC 4944], messages SHOULD fit into a single 802.15.4 frame to minimize fragmentation.

== References ==