Constrained Application Protocol (CoAP) CoAP es un protocolo de aplicaciones de Internet, especificado en la RFC 7252. El protocolo sirve para la comunicación de dispositivos ’nodos’ p. ej. dispositivos embebidos que consumen poca energía (low-power) y operan en redes con pérdida de datos (lossy networks), p. ej. IPv6 sobre Low-Power Wireless Personal Area Networks (6LoWPANs). CoAP también puede utilizarse en redes basadas en Internet para comunicación móvil vía SMS. CoAP se emplea principalmente en el contexto de Internet de las Cosas (IoT) y Machine-to-Machine (M2M), ya que normalmente se transfieren datos de dispositivos/sensores de pequeño tamaño. Dado que este tipo de datos se transmite en intervalos regulares (ciclos), paquetes individuales (perdidos) no afectan significativamente a los sistemas o aplicaciones de procesamiento, como plataformas IoT que procesan y/o representan gráficamente datos de sensores (temperatura, número de revoluciones, etc.).

El grupo de trabajo ‘strained RESTful Environments’, abreviado ‘CoRE’, planea, entre otras cosas, el uso de la arquitectura REST en dispositivos embebidos (nodos). Los nodos utilizan principalmente un microcontrolador de 8 bits y disponen de poca memoria RAM y ROM.

Objetivos del protocolo

  • Crear un protocolo genérico, de modo que este pueda emplearse en aplicaciones IoT, p. ej. domótica o en aplicaciones M2M
  • Simplificación/reducción del protocolo, lo cual conllevará una disminución de la fragmentación
  • Descubrimiento integrado
  • Soporte multicast
  • Intercambios de mensajes asíncronos

Características del protocolo

  • Cumplimiento de los requisitos M2M en redes restringidas
  • [ENG] Enlace UDP con fiabilidad opcional que admite peticiones unicast y multicast
  • Intercambio asíncrono de mensajes
  • Cabecera sencilla y, por tanto, reducción de la complejidad en el análisis sintáctico
  • Soporte de identificadores de recursos uniforme (URI) y tipos de contenido
  • Soporte de proxy y almacenamiento en caché
  • [ENG] Un mapeo HTTP sin estado, que permite construir proxies que proporcionen acceso a recursos CoAP vía HTTP de manera uniforme o que interfaces HTTP sencillas se realicen alternativamente sobre CoAP.
  • Enlace con Datagram Transport Layer Security (DTLS)

El modelo de interacción de CoAP corresponde al modelo cliente/servidor de HTTP, es decir, un ‘cliente’ envía una solicitud (request) a un servidor y pide un URI. El servidor entrega entonces el recurso solicitado. A diferencia de HTTP, la comunicación se realiza por UDP.

CoAP distingue cuatro tipos distintos de mensajes

  1. Confirmable
  2. Non-confirmable
  3. Acknowledgement
  4. Reset

Debido a que CoAP utiliza el protocolo UDP, son posibles duplicados o pérdidas de datos. Por este motivo, en CoAP se implementaron los siguientes dos mecanismos:

  • [ENG] Fiabilidad de retransmisión simple tipo stop-and-wait con retroceso exponencial para mensajes Confirmable.
  • Detección de duplicados para mensajes Confirmable y Non-confirmable

Formato de mensaje CoAP

  • Ver (versión): número de versión de CoAP
  • T (Tipo): indica el tipo de mensaje (0-3): Confirmable (0), Non-confirmable (1), Acknowledgement (2) o Reset (3)
  • TKL (Token Length): indica la longitud variable del token.
  • Code: request (0), respuesta exitosa (2), respuesta de error de cliente (4), respuesta de error de servidor (5)
  • Message ID: se usa para la detección de duplicados o para el emparejamiento de mensajes
  • Options: aquí se pueden especificar números de opción, p. ej. Max-Age con el número 14 o Proxy-Uri (35). La lista completa de números de opción se puede consultar en la especificación.
  • Payload

Tamaño de paquete El tamaño máximo de paquete para la cabecera CoAP es de 1152 bytes y 1024 bytes para el payload. Un paquete CoAP no debe exceder el tamaño máximo, ya que paquetes mayores pueden causar una fragmentación indeseada. Para evitar la fragmentación IP, la transmisión de paquetes debería realizarse vía IPv6. Si se utiliza IPv4, el tamaño de los paquetes debe reducirse correspondientemente. La especificación ofrece más detalles.

Transmisión y parámetros de transmisión La transmisión se realiza de forma similar a HTTP mediante la semántica Request/Response, si bien, a diferencia de HTTP, no hay transmisión sobre una conexión existente o previa. CoAP soporta los siguientes métodos básicos, ya conocidos de HTTPS:

  • GET, p. ej. GET /status/power
  • POST
  • PUT
  • DELETE

Los métodos GET, PUT y DELETE son idempotentes. POST NO es idempotente. Las respuestas se basan en el código de solicitud del encabezado. Se distinguen los siguientes tres códigos de respuesta:

  • Éxito
  • Error de cliente
  • Error de servidor

El protocolo ofrece los siguientes parámetros de transmisión, que el usuario puede configurar según su entorno. Al modificar la configuración, hay que tener en cuenta que, por ejemplo, una reducción de ‘ACK_TIMEOUT’ a un segundo infringiría las ‘Unicast UDP Usage Guidelines for Application Designers’. Otras modificaciones podrían infringir otras directrices. Además, cambios en los parámetros anteriores en determinadas combinaciones o configuraciones tienen más efectos en la transmisión. Para garantizar una comunicación segura, se emplea ‘Datagram Transport Layer Security (DTSL)’.

Seguridad CoAP distingue los siguientes cuatro niveles de seguridad (modo):

  1. NoSec
  2. PreSharedKey - cifrado simétrico
  3. RawPublicKey - cifrado asimétrico
  4. Certificate - cifrado asimétrico vía certificado X.509

URI CoAP En CoAP, al igual que en HTTP, se distingue entre http (coap) y https (coaps). El esquema CoAP es el siguiente:

  • coap-URI = “coap:” “//” host [ “:” port ] path-abempty [ “?” query ]
  • coaps-URI = “coaps:” “//” host [ “:” port ] path-abempty [ “?” query ]

Descubrimiento de servicios El descubrimiento de servicios (Service-Discovery) se refiere al reconocimiento automático de servicios en una red informática. Para ello se utilizan protocolos de comunicación que describen cómo encontrar los servicios para que puedan comunicarse entre sí. Fundamentalmente se distinguen dos grupos de protocolos de descubrimiento de servicios (SDPs):

  1. Los servicios se registran en un servicio central (una registry) y pueden ser encontrados a través de este.
  2. Los servicios interrogan mediante broadcasting a toda la red en busca de un servicio específico y el servicio buscado o una registry responden. [wikipedia]

Una vez alojado un servidor por parte de un nodo 6LoWPAN, el servidor puede alcanzarse por los puertos 5683 y 5684 bajo DTSL. El descubrimiento (discovery) de recursos se realiza mediante un endpoint CoAP. Por ello, un endpoint debería soportar el formato CoRE Link. El formato está descrito en [RFC6690]. Para comunicarse con un servidor se puede usar el agente CoAP Copper (Cu). https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

[Especificación: https://tools.ietf.org/html/rfc7252#section-12.2]

Clientes y servidores LwM2M Quien desee crear su propio servidor o cliente puede usar la implementación de servidor y cliente OMA Lightweight M2M de LESHAN en Java.

A continuación algunos enlaces al proyecto LESHAN: https://github.com/eclipse/leshan/blob/master/README.md https://github.com/eclipse/leshan/wiki/Getting-started