Prueba de concepto sobre gestión con CORECONF

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Prueba de concepto sobre gestión con CORECONF Autor: Antonio Estévez Begines Tutor: Antonio José Estepa Alonso Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Prueba de concepto sobre gestión con CORECONF Autor: Antonio Estévez Begines Tutor: Antonio José Estepa Alonso Profesor titular Dpto. de Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 Trabajo Fin de Grado: Prueba de concepto sobre gestión con CORECONF Autor: Antonio Estévez Begines Tutor: Antonio José Estepa Alonso El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2024 El Secretario del Tribunal A mi familia A mis maestros Agradecimientos Con estas líneas pretendo agradecer el apoyo recibido por parte de todos los compañeros y amigos que he encontrado durante el transcurso de este grado, y a mi familia, en especial a mi hermana Inma por ser un constnte apoyo y estar siempre ahí. También me gustaría agradecer a todos los profesores que han participado en mi formación, tanto en los últimos años en este grado como durante toda la secundaria y primaria. Todos han aportado y han formado parte del proceso que me ha llevado hasta aquí y a ser quien soy. Por último, agradecer a mi grupo de amigos desde la infancia que año tras año siguen ahí y se siguen preocupando porque todo vaya bien. Muchas gracias a todos. 5.2.4 Interfaz de notificaciones de información 44 5.3 Modelo de datos 44 5.3.1 Objetos 44 5.3.2 Recursos 45 6 Implementación 47 6.1 Hardware 47 6.2 CORECONF. 48 6.2.1 Escenario 48 6.2.2 Servidor 48 6.2.3 Cliente 50 6.3 LwM2M 52 6.3.1 Escenario 52 6.3.2 Servidor 53 6.3.3 Cliente 54 6.3.4 Pruebas 55 7 Comparativa y conclusiones 57 7.1 Tamaño de los paquetes 57 7.2 Memoria de programa (Flash) y memoria RAM 59 7.3 Conclusiones 60 Referencias 61 Anexo A: cliente coreconf 63 ÍNDICE DE TABLAS Tabla 1. Tipos incorporados de base por YANG 27 Tabla 2. Formato del contenido de los métodos CORECONF 36 Tabla 3. Definición de un objeto LwM2M 45 Tabla 3. Definición de un recurso LwM2M 45 Tabla 4. Definición del objeto LED 55 Tabla 5. Definición de los objetos genéricos de lectura y lectura/escritura 55 Tabla 6. Comparativa del tamaño de los paquetes en peticiones de modificación 58 Tabla 7. Comparativa del tamaño de los paquetes en peticiones de obtención de datos 58 Tabla 8. Comparativa del tamaño de los paquetes en peticiones POST 59 Tabla 9. Comparativa memoria Flash y RAM 59 ÍNDICE DE FIGURAS Figura 1. Diagrama de arquitectura REST. 26 Figura 2. Nodos de datos YANG 27 Figura 3. Arquitectura CoAP 29 Figura 4. Ejemplo de petición confirmable CoAP 29 Figura 5. Repetición de petición CoAP tras un paquete perdido 30 Figura 6. Cabecera CoAP 30 Figura 7. Códigos de respuesta CoAP 31 Figura 3 . Esquema cliente y servidor CORECONF 35 Figura 4. Torre de protocolos CORECONF 35 Figura 5. Arquitectura LwM2M 41 Figura 6. Modelo de datos LwM2M 44 Figura 7. Node MCUv3 47 Figura 8. Escenario pruebas CORECONF 48 Figura 9. Ejemplo de petición con resultado OK en cliente CORECONF 51 Figura 10. Ejemplo de petición con resultado de error en cliente CORECONF 51 Figura 11. Ejemplo de petición iPATCH 51 Figura 12. Ejemplo de petición POST 52 Figura 13. Escenario pruebas LwM2M 53 Figura 14. Interfaz gráfica servidor LwM2M Leshan 54 Figura 15. Ejemplo de petición GET 56 Figura 16. Ejemplo de petición POST 56 1 INTRODUCCIÓN l avance de la tecnología y el desarrollo de nuevas aplicaciones crean nuevos retos en cuanto a los protocolos de gestión a utilizar en cada escenario. La existencia de distintas organizaciones y organismos encargados de definir estándares acaban provocando la existencia de múltiples protocolos con funcionalidades similiares. En concreto, en este TFG se abordará un estudio sobre la interfaz de gestión de redes y nodos restringidos CORECONF propuesta por el IETF y se comparará con su principal rival en el mercado actualmente, el estándar LwM2M definido por la OMA. 1.1. Problemática En 2023, se alcanzaron los 15.100 millones de dispositivos conectados en el mundo [1]. Esta cifra se espera que continúe creciendo hasta duplicarse en 2030 debido al crecimiento del IoT. Dentro de esta gran cantidad de dispositivos, nos encontramos con los llamados “dispositivos restringidos”, es decir, dispositivos con pocos recursos computacionales y pequeño tamaño. Existe una amalgama de estándares de gestión que son necesarios analizar y ver cuál es el más adecuado para este tipo de dispositivos. Los dos principales son el estándar LwM2M (definido por la OMA) y el aún en proceso de draft, CORECONF (del IETF). También encontramos otros que, aunque no son específicos para el IoT y los dispositivos restringidos, son usados como SNMP o NETCONF. 1.2. Solución a abordar CORECONF ha sido diseñado por el IETF para ser usado específicamente en nodos y redes restringidos. Su principal objetivo es dar solución a la gestión de este tipo de nodos, usando la menor cantidad de recursos y mensajes posibles. Actualmente estos borradores se actualizan cada 6 meses o menos y continúan añadiendo mejoras al mismo. Hasta su versión 10 recibió el nombre de CoMI y actualmente se encuentra en su versión 16 [2]. El IETF pretende que CORECONF se convierta en el estándar usado por la industria de este sector, ocupando el lugar en el mercado con el que se ha hecho LwM2M. En este proyecto se pretende realizar un estudio sobre el borrador de CORECONF. Esto implicará la profundización en arquitecturas y protocolos relacionados (REST, YANG, CoAP), la puesta en marcha de una implementación y el estudio y comparativa con respecto a su competidor, el protocolo LwM2M de la OMA. 1.3. Estructura del documento La estructura de este documento recogerá las tareas abordadas en la realización del trabajo: En la sección dos, se hablará del estado del arte en el que se encuentran los protocolos de gestión. E En medio de la dificultad, reside la oportunidad. - Albert Einstein- Introducción 22 En la sección tres, se abordará la base teórica con los conceptos necesarios para comprender CoMI, como la arquitectura REST, YANG y el protoclo CoAP usado en la capa inferior. En la sección cuatro, se explicará la interfaz de gestión CORECONF tomando como base el borrador 16 de la IETF. En la sección cinco, se mostrará la implementación realizada del protocolo, así como las pruebas al mismo. En la sección seis, se realizará una comparativa con LwM2M y se explicará la implementación que se ha utilzado del mismo. Por último, en la sección siete, se realizará un análisis de los resultados obtenidos de las implementaciones de ambos protocolos y se obtendrán las conclusiones de su comparativa. 2 ESTADO DEL ARTE ebido a la existencia de múltiples protocolos disponibles para la gestión, existen diversos trabajos enfocados en cuáles son apropiados para su utilización en aplicaciones IoT y en redes con nodos restringidos. Sinche et al. [3] analizan los siguientes protocolos de gestión: CMIP, SNMP, LNMP, NETCONF, RESTCONF, LwM2M, DM 2.0 y CoMI (renombrado CORECONF). El análisis se realiza a nivel característico sin realizar implementaciones. Considera a DM 2.0, LwM2M y CoMI lso tres a usar en nodos restringidos sin tene que limitar características del protocolo. También analiza la madurez de los mismos, destacando que LwM2M es el más utilizado hasta el momento y mencionando los esfuerzos que está haciendo la IETF por desarrollar un protocolo centrado en la gestión IoT que le pueda hacer competencia (CORECONF) Parmigiani y Dettmar [4] comparan los dos protocolos más utilizados en la gestión de nodos restringidos, LwM2M y MQTT. Como resultado obtienen que LwM2M consume menos energía en payloads pequeños, pero más con payloads grandes como por ejemplo durante actualizaciones de firmware. También destacan que LwM2M utiliza menos bytes en sus comunicaciones, especialmente si no se utiliza ningún tipo de capa de seguridad. Saif y Matrawy [5] comparan el rendimiento de tres protocolos utilizados para la configuración masiva de nodos IIoT: MQTT, SNMP y un protocolo que ellos mismos desarrollan con arquitectura publicador/suscriptor sobre HTTP/3. Descartan el uso de CORECONF por estar en borrador y no disponer de implementaciones opensource y a LwM2M por no poder automatizar tareas de gestión. Obtienen como resultado que su protocolo tiene un rendimiento similar al uso de MQTT y superior al de SNMP en entornos con un gran número de nodos. Bhat et al. [6 ] realizan una comparativa entre los protocolos CORECONF, NETCONF y RESTCONF en entornos de dispostivos restringidos, realizando para ello una implementaciónd de los tres protocolos. Obtienen como resultado que CORECONF es el más adecuado en términos de consumo de energía y memoria. Tomando estos trabajos como putnos de partida, teniendo en cuenta la popularida actual de LwM2M y que CORECONF parece el más indicado entre el resto a ser su competencia en entornos restringidos, este trabajo pretende compararlos no solo a nivel teórico sino también realizando implementaciones de ambos y comparar así sus prestaciones. D El buen discípulo pasa al maestro -Dicho popular- 24 3 BASE TEÓRICA n este capítulo se presentan las bases teóricas sobre las que se ha desarrollado el protocolo CORECONF. Se empieza con una introducción a la arquitectura REST en la que se basa tanto CoAP como CORECONF. A continuación, se presentan los protocolos relacionados como YANG y CoAP. Por último, se profundiza en CBOR, la codificación utilizada por CORECONF en sus comunicacioens. 3.1 REST La Transferencia de Estado Representacional (REST) es un estilo de arquitectura para sistemas hipermedia distribuidos. Fue definida en el 2000 por Roy Thomas Fielding [7] y su principal objetivo era mejorar la escalabilidad y rendimiento que ofrecían hasta ese momento otras arquitecturas (principalmente SOAP). 3.1.1 Principios de la arquitectura REST -Separación cliente-servidor: En el lado cliente, mejora la portabilidad de la interfaz de usuario, permitiendo la multiplataforma. En el lado servidor, mejora la escalabilidad al simplificar componentes y permitir la evolución por separado de las versiones clientes. -Sin estado: Cada petición del cliente debe contener toda la información necesaria para que sea entendida por el servidor o algún intermediario. Esto mejora la visibilidad, al estar toda la información incluida en la petición, la fiabilidad porque se facilita la recuperación ante fallos parciales y la escalabilidad al permitir que el servidor libere recursos más rápidamente. Como desventaja, baja el rendimiento de la red al aumentarse la cantidad de datos repetidos en una serie de peticiones. -Caché: Mejora la eficiencia de la red. Obliga a que las respuestas sean marcadas como cacheables o nocacheables según puedan ser usadas como respuesta a peticiones equivalentes. El caché mejora la eficiencia, escalabilidad y rendimiento percibido por el cliente al disminuir el número de peticiones. Por el contrario, disminuye la fiabilidad si los datos en caché difieren de los del servidor. -Interfaz uniforme. La principal característica de la arquitectura REST es la uniformidad en las interfaces de sus componentes, al definir 4 restricciones sobre ellas: la identificación de recursos, la manipulación de recursos mediante representaciones, el uso de mensajes autodescriptivos y el uso de hipermedia como motor del estado de la aplicación. Estos principios son definidos por Fielding [7] y detallados en artículos posteriores enfocados en su utilidad para el diseño de servicios web [8] y [9]. E El que resiste, gana Camilo José Cela 3.1.2 Elementos de la arquitectura REST 3.1.2.1 Elementos de datos Los componentes REST se comunican transfiriendo una representación de un recurso en un formato estandarizado que variará según la naturaleza del recurso. Un recurso es una abstracción de la información en REST, cualquier cosa que podamos nombrar puede ser un recurso. Un recurso puede variar su información con el tiempo o ser estático. El recurso no es la información en si, sino su significado, por ejemplo, en un control de versiones de código fuente el recurso “última versión” puede contener la misma información en un momento puntual que el recurso “versión 1.1”, aunque sean recursos distintos. Esta abstracción permite no tener que alterar todas las referencias al concepto cuando se produce un cambio en la información del mismo. La forma de nombrar un recurso es su identificador de recurso, generalmente será una URL o URN. Las representaciones de los recursos son secuencias de bytes más los metadatos que describen esos bytes. Una representación de un recurso indica su estado en un momento dado. El formato de los datos, conocido como media type indica al receptor de un mensaje como debe procesar los datos recibidos. Los datos de control definen el propósito del mensaje, como por ejemplo la acción que queremos realizar (GET, PUT, DELETE, etc) o el significado de una respuesta (OK, Error: no soportado, Error: no encontrado, etc). 3.1.2.2 Conectores Los conectores permiten el acceso a los recursos y transferir representaciones de los mismos. Al ser las interacciones sin estado, se evita que los conectores tengan que retener ningún tipo de información sobre el estado de la aplicación, permite procesar interacciones en paralelo y hace que toda la información que pueda influir en la reutilización de una respuesta esté presente en cada solicitud, facilitando el uso de respuestas en caché. Se definen los siguientes conectores en la arquitectura REST: -Cliente: inicia la comunicación mediante una petición. Incluye los siguientes datos:  Datos de control: indica la acción a realizar.  Identificador de recurso: recurso o servicio al que se dirige la solicitud.  Representación (opcional): para crear o modificar un recurso puede ser necesario incluir la información del mismo -Servidor: acepta peticiones para proporcionar acceso a servicios o recursos. Incluye la siguiente información en sus respuestas:  Datos de control: indica el significado de la respuesta (Ok, creado, error, no encontrado, etc).  Metadatos del recurso (opcional): detalles sobre el recurso como la fecha de creación o modificación del recurso, tamaño, tipo de contenido, identificadores, etc.  Representación (opcional): representación del estado del recurso en ese instante. -Caché: puede incluirse en la interfaz del cliente para evitar la repetición de peticiones o en servidor para evitar el proceso de generación de la respuesta. -Traductor de direcciones: traduce identificadores de recursos en direcciones de red. 3.1.2.3 Componentes Se definen 4 componentes según el papel que cumplen en las aplicaciones: -Agente de usuario: usa un conector cliente para realizar una petición y recibe la respuesta del servidor. El más común es un navegador web. -Servidor de origen: usa un conector de servidor para gestionar un espacio de nombres al que pertenece un recurso y es el responsable último de servir una respuesta a las peticiones del agente de usuario. Los detalles de la implementación de cada recurso se esconden tras la interfaz que muestra al cliente. Base teórica 32  Permitir implementaciones en equipos de bajo recursos.  Decodificar los datos sin un descriptor de esquema. El byte inicial de cada elemento contiene información sobre el tipo de elemento (con sus 3 primeros bits) e información adicional o el propio dato en si en los bits restantes. 3.4.1 Tipos principales Se definen un total de 7 tipos principales:  Tipo 0 (000): entero sin signo. Los 5 bits adicionales hacen referencia al entero, si su valor va de 0 a 23 o a la longitud adicional, siendo 24 un uint_8, 25 uint_16, 26 uint_32 y 27 uint_64. Ejemplo 3–1. Ejemplos de enteros sin signo en codificación CBOR El número 10 necesita solo un byte: 0000 1010 El 35 necesitaría de 2 bytes: 0001 1000 0010 0011  Tipo 1 (001): entero negativo. Los 5 bits adicionales hacen referencia al valor del número, si su valor va de 0 a 23 o a la longitud adicional, siendo 24 un int_8, 25 int_16, 26 int_32 y 27 int_64. Ejemplo 3–2. Ejemplos de enteros negativos en codificación CBOR El número -10 necesita solo un byte: 0010 1001 El -35 necesitaría de 2 bytes: 0011 1000 0010 0010  Tipo 2 (010): cadena de bytes. La longitud de la cadena en bytes se indica siguiendo las reglas de codificación para los enteros sin signo del tipo 0 y a continuación se añaden la propia cadena. Ejemplo 3–3. Ejemplos de cadenas de bytes en codificación CBOR Cadena de 4 bytes de longitud. Se indica directamente el número 4: 0100 0100 [cadena de 4 bytes] Cadena de 35 bytes de longitud. En el primer byte se indica que el número de la longitud necesita 1 byte (uint_8) y en el segundo byte se indica la longitud de la cadena: 0101 1000 0010 0011 [cadena de 35 bytes]  Tipo 3 (011): cadena de texto. Cadena codificada específicamente en UTF-8. El formato es idéntico al del tipo 2. Ejemplo 3–4. Ejemplos de cadenas de texto en codificación CBOR Cadena de 4 bytes. Se indica directamente el número 4: 0100 0100 [cadena de 4 bytes en UTF-8] Cadena de 35 byte. En el primer byte se indica que el número de la longitud necesita 1 byte (uint_8) y en el segundo byte se indica la longitud de la cadena: 0101 1000 0010 0011 [cadena de 35 bytes]  Tipo 4 (100): tabla, lista o secuencia. El número de elementos de la tabla se indica de manera análoga a la longitud de las cadenas de tipo 2 y a continuación se indican los elementos. Ejemplo 3–5. Ejemplos de tablas en codificación CBOR Tabla de 2 elementos: 1000 0010 [2 elementos de la tabla] Tabla de 35 elementos: 1001 1000 0010 0011 [35 elementos de la tabla]  Tipo 5 (101): mapas, diccionarios u objetos json. Los mapas se componen de parejas de elementos o tuplas clave, valor. El número de elementos del mapa se indica de manera análoga a la longitud de las cadenas de tipo 2, seguido de los elementos del mapa. Ejemplo 3–6. Ejemplos de mapas en codificación CBOR Mapa de 2 elementos: 1010 0010 [clave 1, valor 1, clave 2, valor 2] Mapa de 35 elementos: 1011 1000 0010 0011 [clave 1, valor1, clave 2, valor 2, … clave 35, valor 35]  Tipo 6 (110): etiquetas de significado adicional para los otros tipos.  Tipo 7 (111): números de punto flotante y valores sin contenido como verdadero, falso y null. El número de bytes utilizados para representar el número de punto flotante se indica como en los enteros sin signo, mientras que los valores sin contenido se indican en los 5 propios bits restantes. Ejemplo 3–7. Ejemplos valores sin contenido en CBOR Falso (20): 1111 0100 Verdadero (21): 1111 0101 Null (22): 1111 0110 4 CORECONF a Interfaz de Gestión sobre CoAP (CORECONF) es una interfaz de gestión de red orientada a redes y dispositivo de recursos limitados (baja batería, capacidad de procesmiento, etc). CORECONF utiliza CoAP para acceder a recursos especificados en YANG utilizando CBOR+yang como representación. Está siendo desarrollado por el IETF y cada 6 meses aproximadamente elaboran un nuevo borrador actualizado. El último borrador hasta la fecha es el número 16 [2] 4.1 Arquitectura CORECONF sigue una arquitectura REST, en la que se define un cliente y un servidor. El cliente realizará las peticiones y modificaciones de los recursos definidos en modulos YANG utilizando para ello CoAP. El servidor se encarga de recibir las peticiones y responder. El servidor contará con al menos un almacén de datos del que obtener y modificar los recursos implementados de los módulos YANG. Figura 8 . Esquema cliente y servidor CORECONF Figura 9. Torre de protocolos CORECONF L La simplicidad es la máxima sofisticación. - Leonardo Da Vinci - CORECONF 36 4.2 Modelo de datos El modelo de datos de CORECONF se basa en el uso de módulos YANG. En YANG se define si los objetos son de solo lectura, lectura/escritura o ejecutables (RPC). Es importante destacar que para simplificar el protocolo y facilitar su implementación en dispostitivos de recursos limitados, se realizan cambios en los identificadores YANG y se simplifican los almacenes de datos. 4.2.1 Compresión de los identificadores YANG En las especificaciones de los módulos YANG, los identificadores son cadenas de caracteres. Para reducir el tamaño de las peticiones, CORECONF utiliza sus equivalentes identificadores numéricos o SID (del inglés, YANG Schema Item iDentifier). Estos SID además son codificados en CBOR como números enteros sin signo. 4.2.2 Almacén de datos CORECONF permite la implementción de un único almacén de datos que contenga tanto datos de configuración como de operación. Esto permite además que los cambios en la configuración tengan un retraso mínimo, al tratarse igual que los datos de operación. También se contempla el uso de almacenes separados para configuración y operación siguiendo el modelo definido en la Arquitectura de Almacenes de Datos para la Gestión de Redes (NMDA) definido en la RFC8342 [19]. 4.2.3 Formato de las respuestas En la siguiente tabla se define el formato del contenido de los distintos métodos CORECONF. Método Recurso Formato del contenido Petición FETCH Almacén de datos /application/yangidentifiers+cbor-seq Respuesta FETCH Almacén de datos /application/yang-instances+cborseq Petición iPATCH Almacén de datos /application/yang-instances+cborseq Respuesta GET Notificaciones /application/yang-instances+cborseq Petición POST Rpc, acción /application/yang-data+cbor-seq Respuesta POST Rpc, acción /application/yang-data+cbor-seq Tabla 2. Formato del contenido de los métodos CORECONF Todos los formatos están basados en el formato YANG mapeado en CBOR definido por el IETF [17]. A continuación, se explican los 3 formatos: -Application/yang-data+cbor-seq: Mapa CBOR en el que las claves son los SID de los nodos de datos y los valores son los valores de los nodos de datos. -Application/yang-identifier+cbor-seq. Tabla CBOR de identificadores de instancia, codificados como enteros sin signo. Es una lista de identificadores de instancias de datos de un almacén de datos. -Application/yang-instances+cbor-seq. Tabla CBOR de mapas CBOR, cuyas claves son identificadores de 37 Prueba de concepto sobre gestión con CORECONF instancias de los nodos de datos y sus valores los valores de las instancias. Actualmente estos formatos no tienen asociado un identificador de contenido de formato CoAP. Solo está definido el formato 80 como application/cbor. 4.3 Interfaz CoAP de gestión CORECONF utiliza métodos CoAP para retirar y editar datos, realizar notificaciones y llamar a procedimientos remotos. Las diferentes posibilidades a la hora de realizar estas acciones son explicadas en los siguientes subapartados. Los recursos CoAP que implementen el protocolo CORECONF deben soportar al menos un recurso de gestión descubrible, de forma que los clientes puedan saber a qué recursos pueden acceder. Es recomendable que este recurso tenga la ruta /c. También se recomienda que los eventos tengan una ruta diferente, /s. 4.3.1 Retirada de datos Para la retirada de datos, CORECONF utiliza el método FETCH. FETCH es utilizado para obtener el valor de una o varias instancias de un nodo de datos. Las instancias a obtener se especifican en el payload del mensaje, codificando los SIDs en una secuencia CBOR. Formato de la petición: FETCH /c (Formato del contenido: application/yang-identifier+cbor-seq) Formato de la respuesta: 2.05 Contenido (Formato: application/yang-instance+cbor-seq) Ejemplo 4–1. Retirada del dato /ietf-system:system/location El SID correspondiente al identificador yang /ietf-system:system/location es el 1753. Petición: FETCH /c (Formato del contenido: application/yang-identifier+cbor-seq) {1753} Respuesta: 2.05 (Formato application/yang-instance+cbor-seq) [ 1753 : “Sevilla” ] Si se quiere incluir algún parámetro como clave para identificar un nodo de dato, se añade en la secuencia de CBOR, sustituyendo el entero por un mapa {SID (entero), clave (tipo de la clave). FETCH además permite retirar múltiples datos en una misma llamada, para ello se añaden los SIDs en la secuencia CBOR Ejemplo 4–3. Retirada de la interfaz eth0 definida en /ietf-interfaces/interface y de ietf-system/contact El SID correspondiente al identificador yang /ietf-interfaces:interface es el 1553. Si el dispositivo tiene varias interfaces le indicamos que solo queremos la información de la interfaz cuyo nombre es “eth0”. Se elige como clave el nombre ya que es la primera clave definida en el móduyo YANG para los nodos de tipo interfaz. El SID de contact es el 1741. CORECONF 38 Petición: FETCH /c/ (Formato del contenido: application/yang-identifier+cbor-seq) [ {1533, “eth0”}, // SID interface = 1533, nombre de la interfaz “eth0” 1741 // SID contact = 1741 ] Respuesta: 2.05 (application/yang-identifier+cbor-seq) { 1553 : [ { 4: “eth0”, 1: “Ethernet adaptor”, 5: 1890, 2: true, 11: 3 ], 1741, “Administrador” } 4.3.2 Edición de datos El contenido de los almacenes de datos puede ser creado, modificado y borrado. Para ellos CORECONF utiliza el método iPATCH.  Crear o reemplazar una instancia de un recurso. La instancia del nodo de datos es enviada en el payload. Se codifica en CBOR como una secuencia de mapas SID-valor. Formato: iPATCH /c (Formato: application/yang-instances+cbor-seq). 2.01 Creado 2.04 Modificado Ejemplo 4–4 . Edición del dato /ietf-system:system/location El SID correspondiente al identificador yang /ietf-system:system/location es el 1753. Petición: iPATCH /c (Formato: application/yang-instances+cbor-seq) [ {1753 : “Sevilla”} ] Respuesta: 2.04 Changed  Borrar una instancia de un recurso. La instancia del nodo de datos es enviada en el payload. Se codifica en 39 Prueba de concepto sobre gestión con CORECONF CBOR como una secuencia de mapas SID-null Formato: iPATCH /c (Formato: application/yang-instances+cbor-seq). 2.02 Borrado Ejemplo 4–5. Borrado de la instancia del objeto /ietf-system:system/location Petición: Petición: iPATCH /c (Formato: application/yang-instances+cbor-seq) [ {1753 : null} ] Respuesta: 2.02 Deleted El uso de iPATCH permite realizar varias operaciones de creación, edición y borrado en una sola petición, codificando los valores en la secuencia CBOR que forma el payload. Ejemplo 4–6. Edición de la instancia del objeto /ietf-system:system/location y borrado de /ietfsystem:system/contact El SID correspondiente al identificador yang /ietf-system:system/location es el 1753 y el identificador yang /ietfsystem:system/contact es el 1741 Petición: POST /c/Bz (Formato: applicaiton/yang-data+cbor) Petición: Petición: iPATCH /c (Formato: application/yang-instances+cbor-seq) [ {1753 : “Sevilla”}, {1741 : null} ] Respuesta: 2.04 Changed 4.3.3 Notificaciones El método GET es también utilizado para suscribirse a un flujo de notificaciones. Para ello el campo Observar debe ir a 0 y se debe especificar un recurso que permita notificaciones por parte del servidor CORECONF. Cada cuanto tiempo deben enviarse las notificaciones o bajo qué circunstancias y el cómo indicarlo se deja abierto a las implementaciones. 4.3.4 Llamadas a procedimientos remoto (RPC) En los módulos YANG se definen llamadas a procedimientos remotos o acciones, que implican una ejecución por parte del servidor. En CORECONF, se utiliza el método POST. El payload se codifica en CBOR y en el se envía el SID y los datos de entrada si son necesarios. Formato: POST /c (Formato: application/yang-instances+cbor-seq) 2.05 Content (Formato: application/yang-instances+cbor-seq) CORECONF 40 4.4 Seguridad CORECONF confía su seguridad en los mecanismos de CoAP, incluyendo DTLS para el acceso protegido a recursos, además de otros mecanismos de autenticación y autorización. Se recomienda el uso de OSCORE, método de seguridad para entornos REST con nodos restringidos definido en la RFC 8613 [20], que proporciona protección de extremo a extremo entre cliente y servidor CoAP. 41 Prueba de concepto sobre gestión con CORECONF 5 LIGHTWEIGHT M2M L OMA Lightweight Machine to Machine (LwM2M) es un protocolo para la gestión de dispositivos embebidos, sensores y en general, dispositivos emergentes en el Internet de las Cosas (IotT) [21]. El protocolo LwM2M utiliza CoAP como protocolo de transporte sobre UDP, TCP o SMS y actualmente es el principal competidor en el mercado de CORECONF [22]. En este capítulo se tratará su arquitectura y modelo de datos. 5.1 Arquitectura El protocolo LwM2M define tres tipos de entidades: el cliente LwM2M, el servidor de arranque LwM2M y el servidor LwM2M. Los clientes LwM2M se comunican con ambos tipos de servidores para permitir a los servidores LwM2M gsetionrar y monitorizar sus recursos. El servidor de arranque LwM2M se encarga de establecer los parámetros de configuración inicial de los clientes LwM2M. El servidor LwM2M gestiona y monitoriza a clientes LwM2M. LwM2M define la capa de aplicación de comunicación entre un cliente y un servidor. Los clientes suelen residir en dispositivos con recursos limitados mientras que el servidor, usado para gestionar a uno o varios clientes, suele formar parte de equipos de mayor potencia e incluso centros de datos. Un esquema de la arquitectura puede verse en la figura 4. Figura 10. Arquitectura LwM2M E I’m not like them, but i can pretend. - Nirvana - Implementación 48 48 6.2 CORECONF. 6.2.1 Escenario Para la implementación de CORECONF se utilizará el siguiente escenario: -Servidor: Node MCUv3 con distintos objetos de gestión implementados (dependiendo de la prueba). Recibirá las peticiones y responderá -Cliente: PC que ejecutará peticiones. Figura 13. Escenario pruebas CORECONF 6.2.2 Servidor Para realizar la implementación del lado servidor, se han utilizado las siguientes librerías open-source: -TinyCBOR: Escrita en C, permite crear los mapas necesarios para la codificación de los contenidos de los mensajes CoAP. -microCoAP: librería escrita en C para Arduino, que permite el envío y recepción de mensajes GET, PUT y POST, FETCH, iPATCH y PATCH del protocolo CoAP. Esta librería ha sido modificada para incluir CBOR como formato del contenido de los mensajes. Los nodos de datos implementados son los siguientes: - yang /ietf-system:system/contact. SID=1741. Cadena de lectura y escritura. Indica el contacto responsable del dispostivo. leaf contact { 49 Prueba de concepto sobre gestión con CORECONF type string; description "The administrator contact information for the system. A server implementation MAY map this leaf to the sysContact MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and sysContact. The definition of such a mechanism is outside the scope of this document."; reference "RFC 3418: Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) SNMPv2-MIB.sysContact"; } - yang /ietf-system:system/location. SID=1753. Cadena de lectura y escritura. Indica la localización del dispositivo. leaf location { type string; description "The system location. A server implementation MAY map this leaf to the sysLocation MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and sysLocation. The definition of such a mechanism is outside the scope of this document."; reference "RFC 3418: Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) SNMPv2-MIB.sysLocation"; } -/ietf-interfaces:interfaces-state/interface/ietf-ip:ipv4/address/ip. SID=1605 De lectura y escritura. Hace referencia a la ip de una interfaz del dispositivo. leaf ip { type inet:ipv4-address-no-zone; description "The IPv4 address on the interface."; } Como acciones se han definido 2 RPCs: -/ietf-system:system-restart. SID=1718. Reinicia el dispositivo. rpc system-restart { Implementación 50 50 nacm:default-deny-all; description "Request that the entire system be restarted immediately. A server SHOULD send an rpc reply to the client before restarting the system."; } -Luz: SID=9999. No está definida en ningún módulo YANG. Ha sido usada para utilizar una RPC con dato de entrada para apagar/encender la luz. Además, también se ha definido el recurso obligatorio de gestión descubrible. Generalmente llamado “.wellknown/core” en CoAP y en este caso situado en la ruta /c. En la gestión, generalmente los recursos no son modificados constantemente. Por ello se ha decidido que la forma de implementar estos objetos de gestión sea mediante la escritura y lectura de la EEPROM integrada en el Node MCU v3. Se ha limitado por ello el tamaño de las cadenas de los objetos system/location a 120 caracteres y system/contact a 20 caracteres, ocupando las posiciones 0-19 y 20-139 respectivamente. La dirección IP se almacena en las posiciones 140-143, permitiendo así mantenerla al reiniciar el dispositivo. Para obtener datos sobre la memoria de programa necesaria al implementar objetos, se ha hecho una segunda versión del servidor CORECONF con 100 contenedores iguales, cada uno conteniendo 2 hojas de tipo cadena, una de solo lectura y otra de lectura y escritura. Cada uno de los 100 contenedores tienen la siguiente definición. container test { leaf test_RW{ type string; description "Cadena de lectura y escritura”. } leaf test_RO{ type string; description "Cadena de solo lectura”. } } 6.2.3 Cliente Se ha realizado una implementación de un cliente en C (anexo A), que permite enviar peticiones CORECONF desde línea de comandos y muestra las respuestas en la terminal. El cliente recibe 3 argumentos:  opcion: Indica el tipo de petición a ejecutar. Se han implementado FETCH, iPATCH o POST.  datos: indica los recursos a los que acceder con FETCH o el recurso y su nuevo valor al usar iPATCH.  ip/ruta: identifica el recurso y máquina al que queremos acceder o modificar. 51 Prueba de concepto sobre gestión con CORECONF Figura 14. Ejemplo de petición con resultado OK en cliente CORECONF Figura 15. Ejemplo de petición con resultado de error en cliente CORECONF Para realizar la implementación, se ha hecho uso de las siguientes librerías: -libcoap: librería escrita en C que permite enviar y recibir mensajes CoAP. -cn-cbor: librería escrita en C para codificar y decodificar mensajes en CBOR. Se ha desarrollado un decodificador de respuestas CBOR que desglosa en la línea de comandos los elementos recibidos en las respuestas. En el caso de recibir un código de error, también lo muestra por pantalla. Para comprobar la correcta implementación, se han realizado peticiones FETCH, iPATCH y POST y se han capturado los paquetes intercambiados con Wireshark. Figura 16. Ejemplo de petición iPATCH Implementación 52 52 Figura 17. Ejemplo de petición POST 6.3 LwM2M Para realizar la comparación con LwM2M se ha optado por utilizar implementaciones ya existentes. 6.3.1 Escenario Para simplificar el escenario y la implementación del cliente, se ha optado por eliminar el servidor de bootstrap y utilizar solo cliente y servidor. Servidor: PC ejecutando el servidor por defecto de Leshan. Cliente: Node MCUv3 con distintos objetos de gestión implementados (según la prueba). 53 Prueba de concepto sobre gestión con CORECONF Figura 18. Escenario pruebas LwM2M 6.3.2 Servidor Como servidor se utilizará el servidor que Leshan trae como ejemplo, desarrollado en java y que cuenta con una interfaz web para acceder a los recursos. Implementación 54 54 Figura 19. Interfaz gráfica servidor LwM2M Leshan Accediendo a través del navegador, se pueden realizar las peticiones a todos los clientes registrados en el servidor LwM2M. 6.3.3 Cliente En el lado cliente se modificará una implementación de ejemplo de Eclipse Wakaama, que consiste en una implementación de LwM2M en C diseñada para ser usada en sistemas POSIX. Se han realizado modificaciones para adaptar el cliente al nodo MCUnode v3. Eclipse wakaaama registra los recursos obligatorios en LwM2M. Además, se han definido los siguientes objetos: ID Nombre Operaciones Instancias Obligatorio Tipo Rango o enumeración Unidad es Descripción 55 Prueba de concepto sobre gestión con CORECONF -Led: objeto que representa el estado del led del MCUnode. Este objeto solo contiene un recurso. Tabla 5. Definición del objeto LED En una segunda implemetación, se han implementado 100 objetos con 2 cadenas, una de lectura y otra de escritura/lectura para realizar la comparación de uso de memoria respecto al protocolo CORECONF. Los 100 objetos son iguales cambiando el ID: Tabla 6. Definición de los objetos genéricos de lectura y lectura/escritura 6.3.4 Pruebas Para comprobar la correcta implementación, se han realizado pruebas de GET, PUT y POST y se han capturado los paquetes intercambiados entre cliente y servidor utilizando Wireshark. 0 Estado R – Lectura W – Escritura Único Obligatorio Boolean, Estado del led ID Nombre Operaciones Instanc ias Obligatorio Tipo Rango o enumeración Unidades Descripción 1001 Test1R O R – Lectura Único Obligatorio String Test solo lectura 1001 Test1R W R – Lectura W - Escritura Único Obligatorio String Test lectura y escritura Implementación 56 56 Figura 20. Ejemplo de petición GET Figura 21. Ejemplo de petición POST 57 Prueba de concepto sobre gestión con CORECONF 7 COMPARATIVA Y CONCLUSIONES n este capitulo se va a realizar la comparativa entre LwM2M y CORECONF. Esta comparativa se realizará a partir de las pruebas realizadas a ambas implementaciones, teniendo en cuenta tres aspectos: tamaño de los paquetes para el envío de una misma información, uso de memoria de programa en las implementaciones y uso de memoria para datos. Teniendo en cuenta la base teórica, también se realizará una comparativa de las opciones, ventajas y desventajas que ofrecen ambos protocolos en su implementación. Por últimos se numerarán una serie de conclusiones obtenidas de estas comparativa. 7.1 Tamaño de los paquetes Para realizar la comparativa entre los tamaños de paquetes en LwM2M y CORECONF, se han utilizado un total de 7 peticiones:  3 Peticiones de modificación al objeto de localización (tipo String) con los literales: “Madrid”, “Europa/Madrid” y “Los Palacios y Villafranca/Sevilla/Andalucia/España”. Las peticiones son iPATCH para CORECONF y PUT para LwM2M  3 Peticiones de obtención de datos al objeto de localización (tipo String) que contenía los literales anteriores. En CORECONF las peticiones son FETCH y en LwM2M GET  1 Petición Post para ejecutar una llamada a procedimiento remoto (reboot). LwM2M no concreta el tipo de codificación que debe utilizar el payload de COAP, por lo que para las pruebas se han decidido usar dos de los más frecuentes: JSON y TLV. Por su parte, el payload de CORECONF será CBOR. Paquete LwM2M con codificación JSON (Bytes) LwM2M con codificación TLV (Bytes) CORECONF (Bytes) Petición para modificar el objeto Location a valor “Madrid” 114 75 66 Petición para modificar el objeto Location a valor “Europa/Madrid” 121 83 77 Petición para modificar el objeto Location a valor “Los Palacios y Villafranca/Sevilla/Andalucia/España” 159 122 117 Respuesta a la modificación 54 54 54 E Now this is not the end, it is not even the beginning of the end. But it is, perhaps, the end of the beginning -Winston Churchill- Anexo A: cliente coreconf 64 64 cbor_encoder_create_array(&encoder, &array_encoder, CborIndefiniteLength); int isid = 1; for(isid=2;isid<argc-1;isid++){ if(strchr(argv[isid],'/')!=NULL){ strcpy(name,strrchr(argv[isid],'/')+1); if(name!=NULL && strcmp(name,"")!=0){ printf("%s\n",name); len_peticion=strlen(argv[isid]); int len_name=strlen(name); len_sid=len_peticion-len_name-1; printf("len_peticion %d y len_sid %d y len_name %d\n",len_peticion,len_sid, len_name); strncpy(sid, argv[isid], len_sid); printf("%s\n",sid); //Tenemos que codificar un mapa CborEncoder parameterMap; cbor_encoder_create_map(&array_encoder, ¶meterMap, 1); cbor_encode_uint(¶meterMap, atoi(sid)); cbor_encode_text_string(¶meterMap, name, strlen(name)); cbor_encoder_close_container(&array_encoder, ¶meterMap); strcpy(name, ""); } }else{ if(tipo==IPATCH){ CborEncoder parameterMap; cbor_encoder_create_map(&array_encoder, ¶meterMap, 1); 65 Prueba de concepto sobre gestión con CORECONF cbor_encode_uint(¶meterMap, atoi(sid)); cbor_encode_null(¶meterMap); cbor_encoder_close_container(&array_encoder, ¶meterMap); }else if(tipo == FETCH || tipo == POST){ cbor_encode_uint(&array_encoder, atoi(argv[isid])); } } } cbor_encoder_close_container(&encoder, &array_encoder); buflen=cbor_encoder_get_buffer_size(&encoder,buf); //Guardamos el contenido en un archivo FILE *archivo = fopen(nombreArchivo, "wb"); if (archivo == NULL) { fprintf(stderr, "No se pudo abrir el archivo para escritura.\n"); return ""; // Terminar el programa } // Escribir el contenido de buf en el archivo size_t elementosEscritos = fwrite(buf, sizeof(uint8_t), buflen, archivo); // Cerrar el archivo fclose(archivo); printf("Datos guardados exitosamente en %s.\n", nombreArchivo); Anexo A: cliente coreconf 66 66 strcat(peticion, nombreArchivo); strcat(peticion, " -T cafe2024 coap://"); //strcat(peticion, " coap://"); strcat(peticion, argv[argc-1]); strcat(peticion, "/c"); printf("saliendo.\n"); return peticion; } static void indent(int nestingLevel) { while (nestingLevel--) puts(" "); } static void dumpbytes(const uint8_t *buf, size_t len) { while (len--) printf("%02X ", *buf++); } static CborError dumprecursive(CborValue *it, int nestingLevel) { while (!cbor_value_at_end(it)) { CborError err; CborType type = cbor_value_get_type(it); indent(nestingLevel); switch (type) { 67 Prueba de concepto sobre gestión con CORECONF case CborArrayType: case CborMapType: { // recursive type CborValue recursed; assert(cbor_value_is_container(it)); puts(type == CborArrayType ? "Array[" : "Map["); err = cbor_value_enter_container(it, &recursed); if (err) return err; // parse error err = dumprecursive(&recursed, nestingLevel + 1); if (err) return err; // parse error err = cbor_value_leave_container(it, &recursed); if (err) return err; // parse error indent(nestingLevel); puts("]"); continue; } case CborIntegerType: { int64_t val; cbor_value_get_int64(it, &val); printf("%lld", (long long)val); break; } case CborByteStringType: { uint8_t *buf; Anexo A: cliente coreconf 68 68 size_t n; err = cbor_value_dup_byte_string(it, &buf, &n, it); if (err) return err; // parse error dumpbytes(buf, n); puts(""); free(buf); continue; } case CborTextStringType: { char *buf; size_t n; err = cbor_value_dup_text_string(it, &buf, &n, it); if (err) return err; // parse error puts(buf); free(buf); continue; } case CborTagType: { CborTag tag; cbor_value_get_tag(it, &tag); printf("Tag(%lld)", (long long)tag); break; } case CborSimpleType: { 69 Prueba de concepto sobre gestión con CORECONF uint8_t type; cbor_value_get_simple_type(it, &type); printf("simple(%u)", type); break; } case CborNullType: puts("null"); break; case CborUndefinedType: puts("undefined"); break; case CborBooleanType: { bool val; cbor_value_get_boolean(it, &val); puts(val ? "true" : "false"); break; } case CborDoubleType: { double val; if (false) { float f; case CborFloatType: cbor_value_get_float(it, &f); val = f; } else { Anexo A: cliente coreconf 70 70 cbor_value_get_double(it, &val); } printf("%g", val); break; } case CborHalfFloatType: { uint16_t val; cbor_value_get_half_float(it, &val); printf("__f16(%04x)", val); break; } case CborInvalidType: assert(false); break; } err = cbor_value_advance_fixed(it); if (err) return err; } return CborNoError; } int main(int argc, char** argv){ char peticion [200]; char option[5][10]={"get","put","post","fetch","ipatch"}; char payload[100]; uint8_t inicio[30]; 71 Prueba de concepto sobre gestión con CORECONF int i; int numBytes; char base64[4]; char ip[18]; char ruta[20]; char sid[6]; int len_peticion; int len_sid; char* objeto; char* parametro; FILE *pipe; char buffer[256]; CborParser parser; CborValue iterador; if(argc==1){ printf("Uso: %s opcion [datos] ip/ruta \n",argv[0]); }else{ if(strcmp(argv[1],option[2])==0){ strcpy(peticion, "coap-client -m post -f"); strcat(peticion, devuelvePeticion(POST, argc, argv)); }else if(strcmp(argv[1],option[3])==0){ //FETCH strcpy(peticion, "coap-client -m fetch -f"); strcat(peticion, devuelvePeticion(FETCH, argc, argv)); }else if(strcmp(argv[1],option[4])==0){ Anexo A: cliente coreconf 72 72 //iPATCH strcpy(peticion, "coap-client -m ipatch -f"); strcat(peticion, devuelvePeticion(IPATCH, argc, argv)); } //Llamada a coap-client para ejecutar la peticion printf("Peticion: %s\n", peticion); pipe = popen(peticion, "r"); if (pipe == NULL) { printf("El comando ha fallado\n" ); exit(1); } while (fgets(buffer, sizeof(buffer), pipe) != NULL) { //Analizar la respuesta cbor_parser_init(buffer, 256, 0, &parser, &iterador); //Mostrarla por pantalla dumprecursive(&iterador, 0); } /* Cerrar el pipe */ pclose(pipe); } exit(0); }