Hispanopedia Wiki
Articulo de referencia

6LoWPAN

6LoWPAN ( IPv6 sobre redes inalámbricas personales de baja potencia ) [ 1 ] fue un grupo de trabajo del Grupo de Trabajo de Ingeniería de Internet (IETF). [ 2 ] Fue creado con l...

Hispanopedia WikiContenido en espanolLectura gratuita

6LoWPAN ( IPv6 sobre redes inalámbricas personales de baja potencia ) [ 1 ] fue un grupo de trabajo del Grupo de Trabajo de Ingeniería de Internet (IETF). [ 2 ] Fue creado con la intención de aplicar el Protocolo de Internet versión 6 (IPv6) incluso a los dispositivos más pequeños, [ 3 ] permitiendo que los dispositivos de baja potencia con capacidades de procesamiento limitadas participen en el Internet de las cosas . [ 1 ]

El grupo 6LoWPAN definió la encapsulación, la compresión de encabezados, el descubrimiento de vecinos y otros mecanismos que permiten que IPv6 opere sobre redes basadas en IEEE 802.15.4 . Si bien los protocolos IPv4 e IPv6 generalmente no se preocupan por las capas física y MAC sobre las que operan, los dispositivos de baja potencia y el pequeño tamaño de los paquetes definidos por IEEE 802.15.4 hacen que sea conveniente adaptarse a estas capas. [ 4 ]

La especificación base desarrollada por el grupo 6LoWPAN IETF es RFC 4944 (actualizada por RFC 6282 con compresión de encabezado, RFC 6775 con optimización de descubrimiento de vecinos , RFC 8931 con recuperación selectiva de fragmentos y con cambios menores en RFC 8025 y RFC 8066 ). El documento que plantea el problema es RFC 4919. IPv6 sobre Bluetooth Low Energy utilizando técnicas 6LoWPAN se describe en RFC 7668 .        

Áreas de aplicación

Las redes IPv6 están diseñadas para comunicaciones de radio de baja potencia, es decir, dispositivos que requieren conectividad inalámbrica con muchos otros dispositivos a velocidades de datos bajas y con un consumo energético muy limitado. Los mecanismos de compresión de encabezados del RFC 6282 se utilizan para permitir que los paquetes IPv6 viajen a través de dichas redes. 

IPv6 también se utiliza en la red eléctrica inteligente, lo que permite que los contadores inteligentes y otros dispositivos construyan una microred antes de enviar los datos al sistema de facturación mediante la red troncal IPv6. Algunas de estas redes funcionan con radios IEEE 802.15.4 y, por lo tanto, utilizan la compresión y fragmentación de encabezados especificadas en la RFC 6282.

Hilo

Thread es un estándar desarrollado por un grupo de más de cincuenta empresas para un protocolo que funciona sobre 6LoWPAN y permite la automatización del hogar . La especificación está disponible de forma gratuita desde el 24 de junio de 2022.  , pero se requiere membresía paga para implementar el protocolo. [ 5 ] [ 6 ] La versión 1.0 de la especificación se publicó el 29-10-2015. [ 5 ] El protocolo compite más directamente con Z-Wave y Zigbee IP. [ 7 ] En las comunicaciones de dispositivos IoT que utilizan el estándar Matter , Thread es una de las dos posibles capas de transporte inalámbrico.

Funciones

Como ocurre con todas las asignaciones de capa de enlace de IP, RFC4944 proporciona diversas funciones. Más allá de las diferencias habituales entre las redes L2 y L3, la asignación de la red IPv6 a la red IEEE 802.15.4 plantea desafíos de diseño adicionales (consulte RFC 4919 para obtener una descripción general). 

Adaptación del tamaño de los paquetes de las dos redes

IPv6 requiere que la unidad de transmisión máxima (MTU) del enlace sea de al menos 1280 octetos . [ 8 ] En contraste, el tamaño de trama estándar de IEEE 802.15.4 es de 127 octetos. Una sobrecarga máxima de trama de 25 octetos y una función de seguridad opcional pero altamente recomendada en la capa de enlace plantean una sobrecarga adicional de hasta 21 octetos para AES -CCM-128. Esto deja solo 81 octetos para las capas superiores. Dado que esto es mucho menor que 1280, 6LoWPAN define una capa de fragmentación y reensamblaje. Además, el encabezado IPv6 estándar tiene 40 octetos de longitud, por lo que también se define la compresión del encabezado.

Resolución de direcciones

A los nodos IPv6 se les asignan direcciones IP de 128 bits de forma jerárquica, mediante un prefijo de red de longitud arbitraria. Los dispositivos IEEE 802.15.4 pueden usar direcciones extendidas IEEE de 64 bits o, tras un evento de asociación, direcciones de 16 bits únicas dentro de una PAN. También existe un ID de PAN para un grupo de dispositivos IEEE 802.15.4 ubicados físicamente en el mismo lugar.

Diseños de dispositivos diferentes

Los dispositivos IEEE 802.15.4 tienen un tamaño limitado intencionadamente para reducir costes (lo que permite crear redes a gran escala con muchos dispositivos), disminuir el consumo de energía (lo que permite el uso de dispositivos alimentados por batería) y ofrecer flexibilidad en la instalación (por ejemplo, dispositivos pequeños para redes portátiles ). Por otro lado, los nodos cableados en el dominio IP no están sujetos a estas limitaciones; pueden ser más grandes y utilizar la red eléctrica.

Diferente enfoque en la optimización de parámetros

Los nodos IPv6 están diseñados para alcanzar altas velocidades. Los algoritmos y protocolos implementados en capas superiores (como TCP ) están optimizados para gestionar problemas típicos de red, como la congestión; sin embargo, en los dispositivos compatibles con IEEE 802.15.4, la conservación de energía y la optimización del tamaño del código siguen siendo prioritarias.

Capa de adaptación para la interoperabilidad y los formatos de paquetes.

Un mecanismo de adaptación que permita la interoperabilidad entre el dominio IPv6 y el estándar IEEE 802.15.4 puede considerarse un problema de capas. Identificar la funcionalidad de esta capa y definir nuevos formatos de paquetes, si fuera necesario, constituye un área de investigación prometedora. El RFC 4944 propone una capa de adaptación para permitir la transmisión de datagramas IPv6 sobre redes IEEE 802.15.4. 

Abordar los mecanismos de gestión

La gestión de direcciones para dispositivos que se comunican a través de los dos dominios diferentes de IPv6 e IEEE 802.15.4 es engorrosa, cuando no excesivamente compleja.

Consideraciones y protocolos de enrutamiento para topologías de malla en 6LoWPAN

El enrutamiento en sí es un problema de dos fases que se está considerando para las redes IP de baja potencia:

  • Enrutamiento de malla en el espacio de la red de área personal (PAN).
  • La capacidad de enrutamiento de paquetes entre el dominio IPv6 y el dominio PAN.

La comunidad 6LoWPAN ha propuesto varios protocolos de enrutamiento, como LOAD, [ 9 ] DYMO-LOW, [ 10 ] HI-LOW. [ 11 ] Sin embargo, actualmente solo dos protocolos de enrutamiento son legítimos para despliegues a gran escala: LOADng [ 12 ] estandarizado por la UIT bajo la recomendación ITU-T G.9903 y RPL [ 13 ] estandarizado por el grupo de trabajo ROLL de la IETF. [ 14 ]

Enrutamiento

El esquema de enrutamiento 6LoWPAN se puede llevar a cabo de dos maneras diferentes: malla por debajo y ruta por encima .

El enrutamiento en malla (mesh-under) consiste en implementar el enrutamiento en la capa de adaptación (que tiene lugar entre la capa de enlace y la capa de red del modelo OSI), mientras que el enrutamiento por encima (route-over ) realiza esta implementación en la capa de red (véase el esquema de enrutamiento 6LoWPAN). En el enrutamiento por encima , el paquete IPv6 se reconstituye en cada dispositivo intermedio para tomar la decisión de enrutamiento. Por el contrario, en el enrutamiento en malla (mesh-under) , la decisión de enrutamiento se toma a nivel de 6LoWPAN y, por lo tanto, solo con fragmentos del paquete IPv6. En este caso, el paquete IPv6 solo se reconstituye en el equipo receptor. Por lo tanto  :

  • La malla inferior permite un tiempo de transmisión más corto;
  • El enrutamiento por conmutación es más efectivo en condiciones degradadas ( pérdida de paquetes ).

Se han propuesto versiones mejoradas de mesh-under y route-over  :

  • Malla controlada bajo  : Al analizar el contenido del encabezado del primer fragmento, el equipo puede saber qué fragmentos se esperan a continuación. Si el siguiente fragmento recibido no corresponde al fragmento esperado, el equipo solicita su reemisión;
  • Enrutamiento mejorado: Se crea un circuito virtual asociando la dirección IPv6 y el campo datagram_tag del encabezado del primer fragmento. El circuito virtual es utilizado posteriormente por todos los fragmentos que tengan el mismo datagram_tag .

Inicialmente, la comunidad 6LoWPAN desarrolló varios protocolos de enrutamiento, como LOAD, DYMO-LOW y HI-LOW.

Actualmente, solo dos protocolos son legítimos para despliegues a gran escala:

  • LOADng ( Protocolo de enrutamiento vectorial de distancia ligero bajo demanda ad hoc de próxima generación ), sucesor de LOAD, un protocolo de red mallada estandarizado por la UIT según la recomendación ITU-T G.9903. Este estándar se utiliza en particular en el programa Linky para la comunicación de contadores eléctricos.
  • RPL ( Routing Protocol for Low power and Lossy Networks , " protocolo de enrutamiento para LLN"), un protocolo route-over , estandarizado dentro del grupo de trabajo ROLL del IETF responsable de definir mecanismos de enrutamiento para LLN ( Low Power and Lossy Network , "redes de baja potencia y con pérdidas").

Descubrimiento de dispositivos y servicios

Dado que los dispositivos con capacidad IP pueden requerir la formación de redes ad hoc , será necesario conocer el estado actual de los dispositivos vecinos y los servicios que alojan. Las extensiones de descubrimiento de vecinos IPv6 son un borrador de Internet propuesto como contribución en este ámbito.

Seguridad

Los nodos IEEE 802.15.4 pueden operar en modo seguro o en modo no seguro. En la especificación se definen dos modos de seguridad para lograr diferentes objetivos de seguridad: Lista de control de acceso (ACL) y modo seguro [ 15 ].

Compresión de encabezado

El RFC 4944 define el mecanismo de compresión de encabezado IPv6 para LowPAN: LOWPAN_HC1. Incluye la compresión del encabezado UDP en 4 bytes, pero no permite la compresión de la suma de verificación . Además, restringe el rango de puertos UDP de 61616 a 61631 para comprimir este valor a 4 bits.

Esta compresión de encabezados IPv6 solo se puede aplicar a direcciones de enlace locales. Para solucionar este problema, se publicó un borrador de IETF LOWPAN_HC1g. LOWPAN_HC1g se aplica a direcciones globales para comunicaciones IP de múltiples saltos. Estos dos mecanismos de compresión (LOWPAN_HC1 y LOWPAN_HC1g) son complementarios. Por lo tanto, es necesario implementar ambos.

Actualmente, la propuesta del grupo 6LoWPAN es utilizar LOWPAN_IPHC. Este formato reemplaza a LOWPAN_HC1 y LOWPAN_HC1g. Los bytes IPHC resultan de la compresión de la cabecera IPv6. Integran principalmente información sobre la calidad del servicio (DSCP y ECN), las cabeceras siguientes, el número de saltos y las direcciones de origen/destino comprimidas.

Con LOWPAN_IPHC, la tasa de compresión depende del tipo de comunicación  :

  • Para comunicaciones a través de un enlace local, la cabecera IPv6 se puede reducir a 2 bytes (1 byte para Dispatch y 1 byte para LOWPAN_IPHC).
  • Para comunicaciones que requieren múltiples saltos IP, la cabecera se puede comprimir a 7 bytes (1 byte para Dispatch, 1 byte para LOWPAN_IPHC, 1 byte para Hop Limit, 2 bytes para Source Address y 2 bytes para Destination Address).

El siguiente ejemplo muestra el aumento de la carga útil en comparación con el problema original (véase la figura 1 ). En el mejor de los casos, esta carga útil es de 70 a 75 bytes. De hecho, si añadimos la información de fragmentación, como se indica en el párrafo anterior, se reducirá a 65-70 bytes en este caso.

Historia de 6LoWPAN

Los avances tecnológicos de la década de 1990 (miniaturización de la electrónica, despliegue de nuevas redes inalámbricas y sistemas embebidos) propiciaron el surgimiento de nuevas aplicaciones para redes de sensores y actuadores. Con la llegada de las tecnologías inalámbricas, las primeras soluciones utilizadas eran completamente propietarias (por ejemplo, Z-Wave o EnOcean). Con el estándar IEEE 802.15.4 (uso de sensores inalámbricos por radiofrecuencia) surgieron nuevos estándares propietarios (por ejemplo, ZigBee, WirelessHART (in) , etc.).

Cuando se pensó por primera vez en las redes de sensores inalámbricos, 6LoWPAN nació de una idea simple: ¿por qué reinventar un protocolo cuando ya tenemos IP?

2001
Geoff Mulligan propone el uso de IP en 802.15.4 para equipos tipo sensor. Aunque recibió comentarios desfavorables de varios grupos como Zigbee, otros como Internet 0 del Centro para Bits y Átomos del MIT o el grupo de trabajo ROHC (del inglés RObust Header Compression , "compresión robusta de encabezados") de la IETF mostraron interés.
2005
  • La Unión Internacional de Telecomunicaciones publica un número sobre el Internet de las Cosas que hoy en día es una referencia.
  • THEI ETF crea el grupo 6LoWPAN para trabajar específicamente en el tema de la implementación de IP en redes de sensores inalámbricas.
  • Geoff Mulligan propone utilizar el nombre Quibble para referirse a Quad Nibble (cada una de las 4 partes de una dirección IPv6).
2007
  • Maher Chebbo, miembro de la Plataforma Tecnológica Europea "Smart Grid", indica que las "redes inteligentes" eléctricas que integran "objetos inteligentes" que permiten gestionar y optimizar el consumo de electricidad son estratégicas.
  • Estados Unidos lanza un programa para apoyar el desarrollo de redes inteligentes para la modernización del sistema de transmisión y distribución de electricidad, con el fin de mantener una infraestructura eléctrica fiable y segura.
Marzo
Una primera implementación de 6LoWPAN en TinyOS publicada en la implementación de "Arch Rock Company: Primer Pack/IP".
Abril
Una primera implementación de 6LoWPAN en TinyOS está disponible en la implementación de "Sensinode Company: NanoStack v0.9.4".
Agosto
El grupo 6LoWPAN publica el RFC 4919 para garantizar la interoperabilidad de la capa de red.
Septiembre
Ahí es donde ve la luz el RFC 4944, basado en el RFC 4919. Esto debería permitir la conectividad directa a Internet de los equipos LoWPAN a través de IPv6 y reemplazar a los propietarios de protocolos de comunicación como ZigBee, que se desarrolló después de la finalización del proyecto Smart Dust.
2008
  • Las primeras pruebas demuestran que el equipamiento de una red 6LoWPAN que utiliza la UIP (micro IP) (también conocida como IPv6) cumple con los requisitos de la fase 1 de IPv6 Ready . La implementación de la pila IPv6 consume muy pocos recursos (menos de 12 KB de ROM y menos de 2 KB de RAM). Ese mismo año, Arch Rock lanzó un producto comercial IPv6/6LoWPAN que cumple con los requisitos de la fase 2 (Gold) de IPv6 Ready . Además, un experimento de cuatro semanas en un entorno real demuestra que el uso de redes 6LoWPAN es viable (tasa de entrega de mensajes del 99,98 % y latencia media por salto inferior a 62 ms).
  • El Consejo Nacional de Inteligencia de Estados Unidos ( Consejo Nacional de Inteligencia , NIC) indica que el Internet de las Cosas (IoT) es una de las tecnologías disruptivas que marcarán las tendencias hasta 2025.
Julio
El IETF pone en marcha el Grupo de Trabajo ROLL.
Septiembre
La alianza IPSO (del inglés IP for Smart Objects , "IP for Smart Objects"), presidida por Geoff Mulligan, se creó para promover el uso de la propiedad intelectual en objetos inteligentes. Los objetos inteligentes son pequeños dispositivos, como interruptores, detectores o sensores.
2009
  • Las pruebas demuestran la interoperabilidad de ciertas implementaciones de 6LoWPAN (Berkeley IP, Arch Rock, SICSlowpan, Sensinode y Hitachi) que tienen sistemas operativos de código abierto ("TinyOS y Contiki") y propietarios (Sensinode y Hitachi).
  • Presentación del libro 6LoWPAN: The Wireless Embedded Internet de Zach Shelby y Carsten Bormann, uno de los dos libros de referencia sobre 6LoWPAN.
Octubre
Para desarrollar redes eléctricas inteligentes, el presidente Obama anuncia una inversión de 3.400 millones de dólares.
2010
  • Un experimento de 12 meses en diferentes entornos demuestra que la implementación de redes 6LoWPAN es viable (tasa de entrega de mensajes > 99,9 % y tasa de latencia promedio por salto < 125 ms).
  • Presentación del libro " Interconnecting Smart Objects with IP: The Next Internet" de Jean-Philippe Vasseur y Adam Dunkels, uno de los dos libros de referencia sobre 6LoWPAN.
Enero
Un estudio demuestra las importantes perspectivas económicas que ofrece el Internet de las Cosas (IoT).
Marzo
  • El IETF lanza el nuevo grupo de trabajo CORE.
  • Un informe indica que una mejor gestión de la insuficiencia cardíaca, mediante sistemas de sensores que monitorizan de forma remota el peso, la presión arterial, la frecuencia y el ritmo cardíacos, podría reducir los costes sanitarios (hospitalización y tratamiento) en mil millones de dólares anuales en Estados Unidos. Asimismo, el uso del IoT en el transporte podría reducir el número de accidentes de tráfico y, por consiguiente, ahorrar alrededor de 100 mil millones de dólares anuales.
Septiembre
Cisco compra la empresa Arch Rock (una de las líderes en aplicaciones BAC para WSN), lo que refuerza la alianza estratégica previamente firmada entre Cisco e Itron (especialista en medición para redes inteligentes).
2011
Enero
  • Se ha creado un nuevo grupo de trabajo de la IETF, LWIG (acrónimo de Light-Weight Implementation Guidance , "light implementation tips"), con el objetivo de optimizar la pila 6loWPAN (menor uso de memoria, consumo de energía y complejidad) para un mejor rendimiento de los equipos 6LoWPAN. Actualmente, este grupo de trabajo incluye a:
  • Una guía para implementar una API 6loWPAN
  • Un estudio sobre los problemas de interconexión de redes 6LoWPAN a redes IPv4, así como algunas soluciones.

Véase también

Referencias

  1. 1 2 Zach Shelby y Carsten Bormann (23 de mayo de 2011). "6LoWPAN: Internet inalámbrico integrado – Parte 1: ¿Por qué 6LoWPAN?" . eetimes . John Wiley & Sons, Ltd . Recuperado el 24 de junio de 2022 .En '6LoWPAN: The Embedded Internet', Shelby y Bormann redefinen el acrónimo 6LoWPAN como "IPv6 sobre redes inalámbricas de baja potencia", argumentando que el término "Personal" ya no es relevante para esta tecnología.
  2. ↑ «IPv6 sobre WPAN de bajo consumo (6lowpan)» . IETF . Consultado el 10 de mayo de 2016 .
  3. ↑ Mulligan, Geoff, "La arquitectura 6LoWPAN" , EmNets '07: Actas del 4.º taller sobre sensores en red integrados, ACM , 2007
  4. ↑ Kushalnagar, N.; Intel Corp; Montenegro, G.; Microsoft Corporation; Schumacher, C.; Danfoss A/S (agosto de 2007). "Problemas". IPv6 sobre redes de área personal inalámbricas de baja potencia (6LoWPAN): descripción general, supuestos, planteamiento del problema y objetivos . IETF . doi : 10.17487/RFC4919 . RFC 4919. Consultado el 24 de junio de 2022 .
  5. 1 2 "Formulario de solicitud de especificación de hilo 1.1" . Grupo de hilos . Recuperado el 24 de junio de 2022 .
  6. ↑ "Beneficios de la membresía en Thread" . Grupo Thread . Consultado el 24 de junio de 2022 .
  7. ↑ Sullivan, Mark (15 de julio de 2014). "Nest, Samsung, ARM y otros lanzan el protocolo de red de automatización del hogar 'Thread'" . venturebeat.com . venture beat . Consultado el 30 de enero de 2015 .
  8. ↑ Deering, A.; Cisco; Hinden, R.; Nokia (diciembre de 1998). "Problemas con el tamaño de los paquetes". IPv6 sobre redes inalámbricas personales de baja potencia (6LoWPAN): descripción general, supuestos, planteamiento del problema y objetivos . IETF . doi : 10.17487/RFC2460 . RFC 2460. Consultado el 24 de junio de 2022. IPv6 requiere que cada enlace en Internet tenga una MTU de 1280 octetos o más.
  9. ↑ Kim, K.; Daniel Park, S.; Montenegro, G.; Yoo, S.; Kushalnagar, N. (junio de 2007). Enrutamiento vectorial de distancia bajo demanda ad hoc (LOAD) 6LoWPAN . IETF . ID draft-daniel-6lowpan-load-adhoc-routing-03 . Recuperado el 10 de mayo de 2016 .
  10. ↑ Kim, K.; Montenegro, G.; Park, S.; Chakeres, I.; Perkins, C. (junio de 2007). Enrutamiento dinámico MANET bajo demanda para 6LoWPAN (DYMO-low) . IETF . ID draft-montenegro-6lowpan-dymo-low-routing-03 . Recuperado el 10 de mayo de 2016 .
  11. ^ Kim, K.; Yoo, S.; Daniel Park, S.; Lee, J.; Mulligan, G. (junio de 2007). Enrutamiento jerárquico sobre 6LoWPAN (HiLow) . IETF . ID borrador-daniel-6lowpan-hilow-hierarchical-routing-01 . Consultado el 10 de mayo de 2016 .
  12. ↑ Clausen, T.; Colin de Verdiere, A.; Yi, J.; Niktash, A.; Igarashi, Y.; Satoh, H.; Herberg, U.; Lavenu, C.; Lys, T.; Dean, J. (enero de 2016). El protocolo de enrutamiento de vector distancia ad hoc ligero bajo demanda de próxima generación (LOADng) . IETF . ID draft-clausen-lln-loadng-14 . Consultado el 10 de mayo de 2016 .
  13. ↑ Winter, T.; Thubert, P.; Brandt, A.; Hui, J.; Kelsey, R.; Levis, P.; Pister, K.; Struik, R.; Vasseur, JP.; Alexander, R. (marzo de 2012). RPL: ​​Protocolo de enrutamiento IPv6 para redes de baja potencia y con pérdidas . IETF . doi : 10.17487/RFC6550 . RFC 6550. Consultado el 10 de mayo de 2016 .
  14. ↑ "Enrutamiento sobre redes de baja potencia y con pérdidas (roll)" . IETF . Consultado el 10 de mayo de 2016 .
  15. ↑ Park, S.; Kim, K.; Haddad, W.; Chakrabarti, S.; Laganier, J. (marzo de 2011). Análisis de seguridad de IPv6 sobre WPAN de baja potencia . IETF . ID draft-daniel-6lowpan-security-analysis-05 . Recuperado el 10 de mayo de 2016 .

Lecturas adicionales

  • Interoperabilidad de 6LoWPAN
  • Extensiones de descubrimiento de vecinos de LowPan
  • Enfoque de reenvío en serie para conectar sensores basados ​​en TinyOS a Internet IPv6
  • GLoWBAL IPv6: Una integración IPv6 adaptativa y transparente en el Internet de las Cosas Descargar
  • Estandarización del IETF en el campo del Internet de las Cosas (IoT): Un estudio (Descargar)
  • Grupo de Trabajo de Ingeniería de Internet (IETF)
  • Grupo de trabajo 6lowpan
  • 6lowpan.tzi.org