


Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
definiciones breves sobre las capas del modelo tcp/ip y otros componentes
Tipo: Ejercicios
1 / 4
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!



Capa de Red: En esta sección los autores discuten qué propiedades de los hosts y las redes asumidas actualmente por IP ya no existen en el mundo de IoT, y qué se ha hecho para adaptar IP y sus protocolos complementarios para que se ajusten al entorno de IoT. Small MTU: Los enlaces de baja energía restringidos en las redes de IoT a menudo tienen MTU muy pequeñas. La especificación IPv6 incluye dos decisiones de diseño que son problemáticas para los enlaces SmallMTU. En primer lugar, IPv6 utiliza un encabezado de longitud fija de 40 bytes con encabezados de extensión opcionales, que provocan una gran sobrecarga de protocolo para paquetes pequeños. En segundo lugar, la especificación de IPv6 requiere que todas las redes compatibles con IPv6 admitan un tamaño de MTU. Multi-link subnet: Las principales preocupaciones giran en torno al modelo de accesibilidad de “un salto” del que ya dependen muchos protocolos existentes. Primero, el reenvío a través de múltiples enlaces dentro de la subred crea problemas con el manejo de TTL / HopLimit. En las redes IP, es una práctica común limitar el alcance de la comunicación a una sola subred estableciendo el TTL / Hop-Limit en 1 o 255 y verificando que el valor permanezca igual al recibirlo. El modelo de subred multienlace romperá cualquier protocolo que siga dicha práctica porque los nodos que realizan el reenvío de IP a través de múltiples enlaces necesariamente disminuirán el valor TTL / Hop-Limit. El segundo problema es que la multidifusión con alcance de enlace no funciona en subredes de múltiples enlaces sin el soporte adecuado para el enrutamiento de multidifusión. En consecuencia, los protocolos heredados que dependen de la multidifusión con alcance de enlace también se romperán en subredes de múltiples enlaces. Multicast efficiency: La entrega de paquetes es un gran desafío para las redes de malla de IoT restringidas. Primero, la mayoría de los protocolos MAC inalámbricos deshabilitan el ACK de capa de enlace para multidifusión; en consecuencia, los paquetes perdidos no se recuperan en la capa de enlace. En segundo lugar, los receptores de multidifusión pueden experimentar una velocidad de transmisión de datos diferente debido a la coexistencia de múltiples protocolos MAC (por ejemplo, diferentes versiones de Wi-Fi) y / o la adaptación de la velocidad de la capa de enlace; por lo tanto, el remitente debe transmitir a la velocidad de enlace común más baja entre todos los receptores. En tercer lugar, los nodos de IoT pueden cambiar al modo de suspensión de vez en cuando para ahorrar energía, por lo que pueden perder algunos paquetes de multidifusión. Por último, cuando los nodos están conectados a través de una red en malla, un paquete de multidifusión debe ser reenviado a través de múltiples saltos a lo largo de muchas rutas, potencialmente despertando muchos nodos durmientes y sobrecargando el recurso de red ya escaso.
Mesh network routing. La configuración de enrutamiento es sencilla en una red en estrella donde el nodo central (por ejemplo, un nodo maestro Bluetooth) puede actuar como la puerta de enlace predeterminada para los nodos periféricos. Sin embargo, la escala de implementación de la topología inicial está limitada por la cobertura de la señal de un solo nodo central, lo que la hace inadecuada para escenarios de aplicación que cubren un área amplia. La topología de malla permite coberturas más grandes al hacer que los nodos transmitan los paquetes para cada. Capa de Transporte. La capa de transporte en la arquitectura TCP / IP proporciona control de congestión y entrega confiable, ambos implementados por TCP, el protocolo de capa de transporte dominante en Internet. las aplicaciones de IoT generalmente enfrentan una variedad de patrones de comunicación que TCP no puede soportar de manera eficiente. En primer lugar, debido a las limitaciones de energía, los dispositivos pueden entrar con frecuencia en modo de suspensión, por lo que no es factible mantener una conexión duradera en las aplicaciones de IoT. En segundo lugar, una gran cantidad de comunicación de IoT implica solo una pequeña cantidad de datos, lo que hace que la sobrecarga de establecer una conexión sea inaceptable. En tercer lugar, algunas aplicaciones (p. Ej., Activación de dispositivos) pueden tener un requisito de baja latencia, que puede no tolerar el retraso causado por el protocolo de enlace de TCP. Cuando se trabaja en redes inalámbricas con pérdidas, el mecanismo de retransmisión y entrega en orden de TCP también puede causar cabeza de línea bloqueo, que introduce retrasos innecesarios. Además, la mayoría de los protocolos MAC inalámbricos también implementan la capa de enlace solicitud de repetición automática ARQ), que puede perjudicar aún más el rendimiento de TCP si el retardo de retransmisión L2 es mayor que el TCP RTO. Capa de Aplicación. La mayoría de las aplicaciones de IoT implementan el modelo de comunicación de solicitud- respuesta orientado a recursos. Por ejemplo, las aplicaciones de monitorización solicitan datos generados por los sensores; y las aplicaciones de control solicitan operaciones sobre los objetos físicos a través de los actuadores. Estas aplicaciones se parecen a los servicios web actuales que han adoptado la arquitectura REST para la comunicación a nivel de aplicación. Descubrimiento de recursos: La solución para el descubrimiento de recursos en las redes IP tradicionales es el descubrimiento de servicios basado en DNS (DNS-SD). Sin embargo, esta solución tiene varias limitaciones para admitir aplicaciones de IoT. En primer lugar, DNS-SD tiene como objetivo apoyar el descubrimiento de servicios, donde el servicio generalmente se refiere a un programa en ejecución (por ejemplo, un servicio de impresión que se ejecuta en alguna impresora). Por el contrario, los recursos en el contexto de IoT cubren un alcance más amplio: además de los servicios, también puede referirse a
un mecanismo de almacenamiento en caché para una difusión eficiente de los datos; un mecanismo de seguridad de objetos para proteger la integridad y confidencialidad de las ADU individuales; un módulo de control de congestión que puede implementar múltiples algoritmos para diferentes entornos de red; configuración de nombres y descubrimiento de recursos para ayudar a las operaciones de la aplicación; un mecanismo de secuenciación para cortar datos grandes que no pueden caber en una sola ADU; un mecanismo de confiabilidad que admite la retransmisión y el pedido de paquetes de acuerdo con la demanda de la aplicación. Actualmente todas esas funcionalidades son implementados por los protocolos de la capa de aplicación. Sin embargo, algunas de esas funcionalidades podrían haber sido más efectivas si se hubieran trasladado a la red central. Por ejemplo, el control de la congestión podría beneficiarse de los comentarios de las capas de red y enlace para tomar decisiones más acertadas. El almacenamiento en caché podría ser más eficiente si los cachés son ubicuos dentro de la red, en lugar de depender de un almacenamiento en caché dedicado. Para utilizar el almacenamiento en caché en la red, el reenvío basado en URI, DESCANSO La seguridad de la interfaz y el objeto también debe ser compatible en la capa de red para que el contenido almacenado en caché se pueda localizar, recuperar y autenticar fácilmente. Las arquitecturas ICN como NDN [16,31] no solo brindan soporte nativo para las funcionalidades que las aplicaciones de IoT demandan intrínsecamente, sino que también abordan los desafíos de la red de capa inferior. Aplica la misma ADU en todas las capas y devuelve el control del flujo de paquetes a las aplicaciones. No tiene requisitos arti fi ciales sobre MTU mínimo; la pila simplificada en realidad reduce el tamaño de los encabezados de los paquetes. Es intrínsecamente compatible con la multidifusión, ya que el almacenamiento en caché generalizado permite que varios consumidores reutilicen los datos de manera eficiente. Su comunicación orientada a datos evita el problema de direccionamiento y enrutamiento a una gran cantidad de nodos de sensores y abre la oportunidad de enrutamiento y reenvío escalables a través de nombres de capa de aplicación. La seguridad centrada en datos evita la sobrecarga que suponen las soluciones de seguridad basadas en canales y se adapta mejor a los dispositivos de IoT con recursos limitados y conectividad intermitente. La simplicidad arquitectónica conduce a un tamaño de código más pequeño para el software de la aplicación, menor huella de energía y memoria para el dispositivo y una mejor utilización del recurso de red en comparación con la pila IoT actual basada en IP.