Hispanopedia Wiki
Articulo de referencia

Multidifusión confiable orientada a NACK

El protocolo de multidifusión confiable orientado a NACK (NORM) es un protocolo de Internet de capa de transporte diseñado para proporcionar transporte confiable en grupos de mu...

Hispanopedia WikiContenido en espanolLectura gratuita

El protocolo de multidifusión confiable orientado a NACK (NORM) es un protocolo de Internet de capa de transporte diseñado para proporcionar transporte confiable en grupos de multidifusión en redes de datos. Fue definido formalmente por el Grupo de Trabajo de Ingeniería de Internet (IETF) en la Solicitud de Comentarios (RFC) 5740 , publicada en noviembre de 2009.

NORM funciona sobre el Protocolo de Datagramas de Usuario (UDP) y garantiza una comunicación fiable mediante un mecanismo de acuse de recibo negativo (NACK) y solicitud de repetición automática selectiva (ARQ), a diferencia del enfoque de acuse de recibo positivo (ACK) que utiliza el Protocolo de Control de Transmisión (TCP) estándar. En otras palabras, los receptores que utilizan NORM solo envían retroalimentación cuando no reciben un paquete, a diferencia del modelo TCP, donde los receptores confirman la recepción de paquetes periódicamente como parte del funcionamiento del protocolo. Esto permite que NORM admita grupos de receptores a gran escala.

Para mejorar la escalabilidad, NORM también emplea codificación de borrado de paquetes mediante códigos de corrección de errores hacia adelante (FEC), junto con la supresión de la retroalimentación NACK redundante del grupo de receptores. Además, NORM puede configurarse para operar con "receptores silenciosos" que confían en su codificación de borrado de paquetes para una entrega de alta fiabilidad, funcionando así como un protocolo de difusión exclusiva. El FEC puede configurarse para usarse de forma reactiva (con receptores que envían NACK), proactiva (receptores silenciosos) o de forma híbrida, lo que permite optimizar la latencia y la sobrecarga de la red.

Además de brindar soporte para un transporte confiable, NORM también ofrece control de congestión compatible con TCP y control de flujo de extremo a extremo . A diferencia de TCP, que utiliza el mecanismo ACK para el control de congestión y el control de flujo, NORM emplea mecanismos independientes para cada uno. Esto permite una amplia variedad de configuraciones para satisfacer las diferentes necesidades de entrega de datos de las aplicaciones.

NORM también admite mecanismos de señalización adicionales para facilitar el control de sesión , el acuse de recibo positivo controlado por la aplicación y otras funciones para crear aplicaciones completas de comunicaciones de red punto a punto y de grupo que sean altamente robustas y eficientes.

Aunque NORM se desarrolló principalmente para admitir la comunicación de grupo multicast, también admite transferencias de datos unicast (punto a punto).

Fondo

En el modelo de red TCP/IP , la capa de transporte (Capa 4) es responsable del transporte fiable de datos. El protocolo TCP es el principal medio para garantizar un transporte unicast (punto a punto) fiable. TCP lo logra mediante un mecanismo ACK.

Con el mecanismo ACK, los paquetes de datos se numeran secuencialmente y el remitente no envía un paquete hasta que recibe una confirmación (ACK) del receptor de que el paquete anterior se ha recibido correctamente. Si el remitente no recibe una confirmación después de un tiempo determinado, reenvía el paquete correspondiente. El remitente continuará haciéndolo hasta que reciba una confirmación (aunque, llegado cierto punto, asumirá que la conexión se ha perdido y finalizará la sesión). Esto es similar a cuando un interlocutor asiente con la cabeza y dice "ajá" en una conversación cara a cara. (El protocolo UDP, hermano de TCP, no funciona así. UDP simplemente envía paquetes de datos a través de la red con la mejor intención posible y asume que se reciben correctamente).

Un problema inicial detectado en el mecanismo ACK de TCP fue su mal funcionamiento en comunicaciones de grupos de multidifusión grandes. En estas comunicaciones, los paquetes de datos se transmiten simultáneamente a un grupo de receptores. En grupos de multidifusión grandes, el uso de ACK puede provocar "implosiones de ACK", en las que un gran número de ACK simultáneos puede saturar al emisor. [ 1 ] Esto es similar a una sala llena de personas asintiendo con la cabeza y diciendo "ajá" mientras un orador habla.

El Protocolo de Difusión Multicast (MDP) [ 2 ] fue un intento inicial de garantizar la fiabilidad y abordar el problema de las implosiones de ACK mediante el uso de NACK. MDP empleó el acuse de recibo negativo selectivo (NACK) para mejorar la fiabilidad. Además, MDP implementó técnicas probabilísticas para suprimir los NACK redundantes en el grupo multicast (y así evitar las implosiones de NACK).

MDP también utilizaba conceptos de codificación de corrección de errores hacia adelante a nivel de paquete como mecanismo de reparación. Generalmente, los paquetes de reparación de paridad codificados se enviaban en respuesta a las solicitudes de reparación de los receptores. De esta forma, no se añadía ninguna sobrecarga de protocolo adicional con respecto a los métodos de retransmisión selectiva. Además, MDP permitía configurar opcionalmente el protocolo para enviar paquetes de reparación proactivos en el bloque de transmisión de datos original.

MDP fue un predecesor directo de NORM, con un borrador inicial de IETF publicado en noviembre de 1996. [ 3 ] La Administración Nacional de Aeronáutica y del Espacio (NASA) adoptó MDP para transferencias de archivos confiables durante misiones espaciales, [ 4 ] y el Ejército de los EE. UU. lo utilizó para mensajería grupal táctica en su sistema Force Battle Command Brigade and Below (FBCB2). [ 5 ]

Se estaban desarrollando otros enfoques para la multidifusión confiable aproximadamente al mismo tiempo, [ 6 ] y en abril de 1999, el IETF creó el Grupo de Trabajo de Transporte de Multidifusión Confiable (RMTWG) para estandarizar el transporte de multidifusión confiable. [ 7 ]

El RMTWG adoptó la estrategia de desarrollar componentes básicos e instancias de protocolo. Esta estrategia evitó un protocolo único para todos los casos, lo que a su vez permitió dar cabida a la gran cantidad de aplicaciones y tipos de aplicaciones que la multidifusión confiable podía soportar.

Los bloques de construcción se definieron como “un conjunto de componentes modulares de grano grueso fácilmente separables que son comunes a múltiples protocolos junto con API abstractas que definen los métodos de acceso de un bloque de construcción y sus argumentos”. [ 7 ] Los bloques de construcción iniciales incluían acuses de recibo negativos, corrección de errores hacia adelante, un mecanismo de señalización genérico para asistencia de enrutador y protección de transporte.

Las instancias de protocolo se definieron como “especificaciones que definen la lógica de unión necesaria y la funcionalidad adicional mínima requerida para realizar un protocolo funcional a partir de uno o más bloques de construcción”. [ 7 ] Dichas especificaciones también incluirían una API abstracta que definiera la interfaz entre la implementación del protocolo y una aplicación. Se eligieron dos instancias de protocolo:

En julio de 2005, los bloques de construcción del protocolo basados ​​en NACK y la instanciación del protocolo se presentaron como “Experimentales” en el RFC 3940, y en noviembre de 2009, el “Protocolo de transporte de multidifusión confiable orientado a NACK (NORM)” fue aprobado en el RFC 5740. [ 8 ]

El RMTWG fue disuelto en septiembre de 2013. [ 9 ]

Construcciones arquitectónicas NORM

Las siguientes construcciones arquitectónicas se definen en la Sección 2 de la RFC 5740, Definición de Arquitectura. [ 10 ]

El mensaje NORM es la estructura arquitectónica fundamental de NORM. Un mensaje NORM está contenido en el campo de datos de un datagrama UDP.

Un objeto NORM hace referencia a uno de los tres tipos diferentes de datos masivos que se transportan en un mensaje NORM:

  • DATOS_OBJETO_NORMAL
  • ARCHIVO_OBJETO_NORMAL
  • FLUJO DE OBJETOS NORM

NORM_OBJECT_DATA se refiere al contenido de datos estáticos en la memoria del ordenador, mientras que NORM_OBJECT_FILE se refiere a archivos de almacenamiento del ordenador. Ambos tipos de mensajes proporcionan una transmisión fiable a bloques finitos de contenido, pero se establece una distinción para que los receptores puedan determinar qué tipo de almacenamiento asignar para el contenido de los mensajes recibidos.

NORM_OBJECT_STREAM se refiere a flujos (no finitos) de datos continuos. NORM admite el transporte fiable de datos en flujo, similar al de TCP, con la excepción de que los receptores NORM pueden unirse a la recepción del contenido del flujo sin importar el momento en que se encuentre dentro del mismo.

Una sesión NORM se refiere al intercambio de información entre dos o más hosts de red mediante NORM. Normalmente, una sesión NORM se realiza utilizando direcciones IP y números de puerto predeterminados , que suelen estar asociados a direcciones de grupo de multidifusión IP definidas antes de la sesión. Estas direcciones pueden determinarse mediante otros protocolos, como el Protocolo de Descripción de Sesión (SDP) [RFC 4566] o el Protocolo de Anuncio de Sesión (SAP) [RFC 2974]. Aunque NORM se diseñó específicamente para la comunicación de grupos de multidifusión, también admite la comunicación unicast.

Una premisa fundamental de una sesión NORM es que consistirá en un único transmisor que se comunica con un grupo de receptores. En una misma sesión NORM pueden operar varios emisores, aunque cada receptor debe mantener un estado para cada emisor.

Un nodo NORM se refiere a un nodo individual que participa en una sesión NORM. Cada nodo tiene un identificador único. Cuando un nodo transmite un mensaje NORM, este identificador se denomina source_id .

Una instancia NORM se refiere a un nodo individual dentro de un segmento continuo de una sesión NORM. Cuando un nodo se une a una sesión NORM, tiene una identificación de nodo única, así como una identificación de instancia. Si el nodo abandona la sesión por cualquier motivo y posteriormente se reincorpora, la identificación de nodo permanece igual, pero la identificación de instancia cambia. La instancia actual se denomina instance_id .

Estructura de mensajes NORM

NORM tiene dos clases generales de mensajes, mensajes de remitente y de receptor, que se definen en la Sección 4 de la RFC 5740, Formatos de mensajes NORM. [ 11 ] Los tipos de mensajes de remitente NORM son: NORM_DATA, NORM_INFO y NORM_CMD. Los tipos de mensajes de receptor NORM son: NORM_NACK, NORM_ACK y NORM_REPORT.

Todos los mensajes NORM constan de una cabecera común obligatoria, una cabecera de tipo de mensaje y una sección de datos (carga útil). Entre la cabecera y la carga útil se puede insertar un campo de extensión opcional que especifica la codificación de corrección de errores utilizada, el algoritmo de control de congestión u otra información de gestión de sesión.

Encabezado de mensaje común NORM

Todos los mensajes NORM comienzan con el siguiente encabezado común, definido en RFC 5740, Sección 4.1, Encabezado y extensión de mensaje común NORM. [ 12 ]

versión (4 bits)
El número de versión del protocolo.
tipo (4 bits)
El tipo de mensaje NORM (es decir, 1 = NORM_INFO, 2 = NORM_DATA, 3 = NORM_CMD, 4 = NORM_NACK, 5 = NORM_ACK, 6 = NORM_REPORT).
hdr_len (8 bits)
Número de palabras de 32 bits que componen la cabecera del mensaje. Esto se utiliza para identificar la adición de extensiones de cabecera. Si el valor de "hdr_len" es mayor que el valor base para el tipo de mensaje especificado, implica la presencia de una extensión de cabecera.
secuencia (16 bits)
Cumple dos funciones (dependiendo del tipo de mensaje):
  • Permite a los receptores mantener una estimación de la pérdida de paquetes para facilitar el control de la congestión.
  • Admite la protección contra ataques de repetición de mensajes NORM_NACK o NORM_NACK.
ID de origen (32 bits)
La identidad única del nodo que originó el mensaje dentro del contexto de una sesión NORM determinada.

Tipo de mensaje NORM_DATA

El mensaje NORM_DATA, definido en la sección 4.2.1 de la RFC 5740, es el tipo de mensaje más común transmitido por los remitentes NORM. [ 13 ] Los mensajes NORM_DATA contienen contenido de datos segmentado para los tipos NORM_OBJECT_DATA, NORM_OBJECT_FILE y NORM_OBJECT_STREAM.

ID de instancia (16 bits)
Una identificación única de la instancia actual de participación en la sesión NORM.
grtt (8 bits)
Estimación actual del remitente sobre el tiempo de viaje de ida y vuelta del grupo.
retroceso (4 bits)
Un valor utilizado por los receptores para determinar el valor máximo del temporizador de retroceso cuando se utilizan mecanismos de supresión de retroalimentación NORM NACK basados ​​en temporizador.
gsize (4 bits)
La estimación actual del remitente sobre el tamaño del grupo.
banderas (32 bits)
Indicadores binarios que proporcionan información para ayudar al receptor a gestionar adecuadamente la carga útil.
fec_id
El identificador de codificación FEC. Esto se describe en el documento FEC Building Block [RFC5052].
ID de transporte de objeto
Valor asignado por el remitente a los objetos NORM transmitidos, que los receptores utilizan para las transmisiones y las solicitudes de reparación. Se incrementa de forma monótona y progresiva.
fec_payload_id
Un identificador para el contenido de la carga útil NORM_DATA adjunta.
Nota 1
payload_length, payload_msg y payload_offset solo se refieren al contenido de NORM_OBJECT_STREAM.

Tipo de mensaje NORM_INFO

Los mensajes NORM_INFO, definidos en la sección 4.2.2 de la RFC 5740, permiten enviar datos opcionales fuera de banda asociados con los objetos de contenido de datos. [ 14 ] Esto permite a los receptores determinar la naturaleza del contenido correspondiente que se transmite, lo que a su vez permite el control a nivel de aplicación de la participación del nodo receptor en la sesión.

El contenido de NORM_INFO debe caber en la parte de la carga útil de un único mensaje NORM. Por lo tanto, se considera atómico. Un ejemplo de uso de NORM_INFO sería enviar información de tipo MIME para el contenido de datos NORM asociado. Esto permitiría a los receptores decidir sobre su participación en la sesión.

ID de instancia (16 bits)
Una identificación única de la instancia actual de participación en la sesión NORM.
grtt (8 bits)
Estimación actual del remitente sobre el tiempo de viaje de ida y vuelta del grupo.
retroceso (4 bits)
Un valor utilizado por los receptores para determinar el valor máximo del temporizador de retroceso cuando se utilizan mecanismos de supresión de retroalimentación NORM NACK basados ​​en temporizador.
gsize (4 bits)
La estimación actual del remitente sobre el tamaño del grupo.
banderas (32 bits)
Indicadores binarios que proporcionan información para ayudar al receptor a gestionar adecuadamente la carga útil.
fec_id
El identificador de codificación FEC. Esto se describe en el documento FEC Building Block [RFC5052].
ID de transporte de objeto
Valor asignado por el remitente a los objetos NORM transmitidos, que los receptores utilizan para las transmisiones y las solicitudes de reparación. Se incrementa de forma monótona y progresiva.

Tipo de mensaje NORM_CMD

Los mensajes NORM_CMD, definidos en la sección 4.2.3 de la RFC 5740, se utilizan para gestionar las sesiones NORM. [ 15 ] Estos mensajes sirven para recopilar el tiempo de ida y vuelta, reunir y enviar datos relacionados con el control de congestión, sincronizar las ventanas de reparación y notificar el estado del remitente. Existe un conjunto básico de mensajes NORM_CMD especificados y enumerados, así como una variedad de otros tipos disponibles para usos específicos de la aplicación.

ID de instancia (16 bits)
Una identificación única de la instancia actual de participación en la sesión NORM.
grtt (8 bits)
Estimación actual del remitente sobre el tiempo de viaje de ida y vuelta del grupo.
retroceso (4 bits)
Un valor utilizado por los receptores para determinar el valor máximo del temporizador de retroceso cuando se utilizan mecanismos de supresión de retroalimentación NORM NACK basados ​​en temporizador.
gsize (4 bits)
La estimación actual del remitente sobre el tamaño del grupo.
banderas (32 bits)
Indicadores binarios que proporcionan información para ayudar al receptor a gestionar adecuadamente la carga útil.
fec_id
El identificador de codificación FEC. Esto se describe en el documento FEC Building Block [RFC5052].
ID de transporte de objeto
Un valor asignado por el remitente a los objetos NormObject que se transmiten y que los receptores utilizan para las transmisiones y las solicitudes de reparación. Se incrementa de forma monótona y progresiva.
subtipo (8 bits)
Indica el tipo de comando que sigue.
Contenido de NORM_CMD
  • FLUSH  : Indica el fin temporal de la transmisión por parte del remitente. También puede utilizarse opcionalmente para obtener una confirmación de recepción fiable de un subconjunto de receptores.
  • EOT  : Indica el final permanente de la transmisión.
  • SQUELCH  : Indica la ventana de reparación actual del remitente en respuesta a NACKs fuera de rango.
  • CC  : Se utiliza para la medición del GRTT y la recopilación de información sobre el control de la congestión.
  • REPAIR_ADV  : Anuncia el estado agregado de reparación/retroalimentación del remitente para la supresión de la retroalimentación unicast de los receptores.
  • ACK_REQ  : Solicita una confirmación positiva definida por la aplicación a una lista de receptores (OPCIONAL).
  • APLICACIÓN  : Se utiliza para fines definidos por la aplicación que necesitan interrumpir o complementar temporalmente la transmisión de datos (OPCIONAL).

Tipo de mensaje NORM_NACK

Los mensajes NORM_NACK, definidos en la sección 4.3.1 de la RFC 5740, se utilizan principalmente para que los receptores soliciten la reparación del contenido del remitente. [ 16 ] Además, estos mensajes contienen campos que proporcionan información al remitente o remitentes relacionada con la recopilación de tiempos de ida y vuelta y el control de la congestión.

ID del servidor (32 bits)
El remitente NORM al que está destinado el mensaje NORM_NACK.
ID de instancia (16 bits)
Una identificación única de la instancia actual de participación en la sesión NORM.
reservado (16 bits)
Para un posible uso futuro de NORM
grtt_respuesta_sec (32 bits)
Una versión ajustada de la marca de tiempo del mensaje NORM_CMD(CC) recibido más recientemente para el remitente NORM indicado.
grtt_response_usec (32 bits)
Una versión ajustada de la marca de tiempo del mensaje NORM_CMD(CC) recibido más recientemente para el remitente NORM indicado.
Carga útil NACK
Las necesidades de reparación del receptor con respecto al remitente NORM indicadas por el campo "server_id".

Tipo de mensaje NORM_ACK

Los mensajes NORM_ACK, definidos en RFC 5740 4.3.2, se utilizan principalmente para respaldar las operaciones de control de congestión y las mediciones de tiempo de ida y vuelta. [ 17 ]

ID del servidor (32 bits)
El remitente NORM al que está destinado el mensaje NORM_ACK.
ID de instancia (16 bits)
Una identificación única de la instancia actual de participación en la sesión NORM.
tipo_ack (8 bits)
La naturaleza del mensaje NORM_ACK. Esto se corresponde directamente con el campo "ack_type" del mensaje NORM_CMD(ACK_REQ) al que se aplica este acuse de recibo.
ID de confirmación (8 bits)
Un número de secuencia permite al remitente verificar que un mensaje NORM_ACK recibido corresponde a una solicitud de acuse de recibo actual. El campo "ack_id" no se utiliza en los tipos de acuse de recibo NORM_ACK(CC) y NORM_ACK(FLUSH).
grtt_respuesta_sec (32 bits)
Una versión ajustada de la marca de tiempo del mensaje NORM_CMD(CC) recibido más recientemente para el remitente NORM indicado.
grtt_response_usec (32 bits)
Una versión ajustada de la marca de tiempo del mensaje NORM_CMD(CC) recibido más recientemente para el remitente NORM indicado.
carga útil de confirmación (si corresponde)
El formato "ack_payload" es una función de "ack_type".

Tipo de mensaje NORM_REPORT

El mensaje NORM_REPORT, tratado en la sección 4.4.1 de la RFC 5740, es un mensaje opcional. [ 18 ] El formato actualmente no está definido.

Extensiones de encabezado NORM

Las extensiones de encabezado opcionales, definidas en la Sección 4.1 de la RFC 5740, siguen al encabezado común y al encabezado específico del mensaje, y preceden a la carga útil (si la hay). [ 19 ] Las extensiones de encabezado suelen contener información relacionada con FEC base, operaciones de control de congestión y otra información de gestión de sesión. Hay dos tipos de extensiones de encabezado: de longitud variable y de longitud fija.

hetero (8 bits)
El tipo de extensión de encabezado. Para extensiones de encabezado de longitud variable, un valor entre 0 y 127 (inclusive).
hola (8 bits)
Longitud de la extensión del encabezado. Indica la longitud de toda la extensión del encabezado.
contenido de la extensión del encabezado
Varía según el propósito.

hetero (8 bits)
Tipo de extensión de encabezado. Para extensiones de encabezado de longitud fija, un valor entre 128 y 255 (inclusive).
reservado (8 bits)
Reservado para uso futuro.
Contenido de la extensión de encabezado (16 bits)
Varía según el propósito.

Operación del protocolo

Operaciones generales

El siguiente funcionamiento general del protocolo NORM se describe en la Sección 5, Operación detallada del protocolo, de la RFC 5740. [ 20 ]

1. Tras el establecimiento de una sesión NORM, el remitente segmenta un objeto NORM en una secuencia numerada ordinalmente. Estos segmentos se transmiten como mensajes NORM_DATA. Además del contenido de datos, los mensajes NORM_DATA se etiquetan con identificadores únicos e identificadores FEC. El remitente también puede enviar mensajes NORM_INFO fuera de banda asociados al contenido NORM_DATA, que permiten a los receptores determinar la naturaleza del contenido correspondiente, lo que a su vez permite el control a nivel de aplicación de la participación del nodo receptor en la sesión.

Al mismo tiempo, el remitente transmite periódicamente mensajes NORM_CMD(CC) según sea necesario para recopilar la información de retroalimentación necesaria para el control de la congestión y otras actividades de gestión de sesiones.

2. Cuando los receptores detectan contenido faltante de un remitente, pueden intentar repararlo mediante mecanismos FEC. Si la reparación no se realiza correctamente, los receptores enviarán mensajes NORM_NACK al remitente. Utilizando la información de secuencia numerada ordinalmente, los receptores especifican el contenido faltante.

3. A medida que el remitente recibe NACKs, agrupa las solicitudes de reparación y envía las reparaciones apropiadas asociadas con la información de secuencia numerada ordinalmente.

4. Cuando el remitente llega al final de una colección de solicitudes de reparación, transmite un mensaje NORM_CMD(FLUSH), que indica el final temporal de la transmisión.

En el contexto de las operaciones generales, NORM cuenta con mecanismos específicos para abordar el control de sesiones, el control de congestión, el control de flujo, la confiabilidad y la gestión de NACK.

Control de sesión

Aunque NORM no es un protocolo orientado a la conexión , como TCP, tiene características tanto orientadas a la conexión como sin conexión. [ 5 ]

A diferencia del protocolo TCP, que se basa en la conexión, NORM no establece una sesión mediante un mecanismo de configuración (es decir, un protocolo de enlace de tres vías). En cambio, NORM utiliza números de puerto y direcciones predefinidas que tanto el emisor como el receptor deben conocer. Esto permite que los receptores se unan a sesiones NORM en curso y que se reanuden rápidamente tras una interrupción de la red.

Al mismo tiempo, los emisores y receptores de NORM mantienen un estado para garantizar una transferencia fiable, por lo que NORM no es totalmente desconectado.

Se reserva una serie de subtipos de mensajes NORM_CMD para dar soporte a los protocolos de control de sesión que puedan desarrollarse en el futuro.

Control de congestión

NORM utiliza un esquema de control de congestión compatible con TCP que le permite compartir equitativamente el ancho de banda disponible con TCP y otros protocolos de transporte. [ 5 ] Específicamente, el esquema de control de congestión de NORM utiliza un procedimiento de control de velocidad y es una adaptación del enfoque de especificación del protocolo de control de congestión de multidifusión compatible con TCP (TFMCC) descrito en RFC4654. Se ha demostrado que este enfoque funciona bien con TCP y flujos de datos de multidifusión.

El método de control de congestión TFMCC se basa en ecuaciones. Las tasas de transmisión del emisor dependen de la recopilación de estimaciones de pérdida de paquetes y tiempos de ida y vuelta, obtenidos mediante mensajes NORM_CMD(CC). Esta información permite identificar cuellos de botella y ajustar la tasa del emisor para solucionarlos.

Al igual que TCP, el esquema de control de congestión NORM asume que la pérdida de paquetes se debe a desbordamientos de búfer, por lo que el emisor reduce su velocidad de transmisión cuando la pérdida de paquetes alcanza un nivel determinado. Esto puede generar limitaciones en las redes inalámbricas, donde la pérdida de paquetes suele deberse a errores de bits o contención.

Dado que el mecanismo de control de velocidad de NORM está separado de sus otros componentes, por ejemplo, el mecanismo de confiabilidad o el mecanismo de control de flujo, puede reemplazarse con un algoritmo alternativo y las extensiones de encabezado adecuadas.

Control de flujo

NORM tiene cuatro opciones para el control de flujo, lo que permite al emisor NORM gestionar la tasa de transmisión a los receptores NORM para garantizar que estos no se saturen. [ 5 ]

1. Marca de agua explícita . Con esta opción, el remitente solicita una confirmación de recepción a un grupo específico de receptores sobre la correcta recepción de un punto designado, o marca de agua, en la transmisión actual. Si todos los receptores confirman la recepción de la marca de agua, el remitente puede continuar enviando nuevos datos.

2. Marca de agua implícita. Esta opción se basa en la ausencia de solicitudes de reparación de acuse de recibo negativo (NACK) por parte del receptor. El remitente utiliza el comando NORM_CMD(FLUSH) para alertar a los receptores sobre los NACK necesarios para cualquier reparación a través de la marca de agua indicada. A continuación, el remitente espera hasta que el vaciado se haya completado por completo. Si no se ha registrado ninguna actividad de NACK, el remitente asume que la marca de agua se ha completado y puede continuar enviando nuevos datos.

3. Control de flujo flexible basado en temporizador. Esta opción retiene los datos transmitidos y limita el avance de la ventana de reparación según el tiempo de ida y vuelta del grupo (GRTT) y la actividad NACK. Se establece un límite de tiempo mínimo y adaptable, tras el cual el remitente puede seguir enviando nuevos datos. Este límite se basa en el GRTT estimado por el remitente y la ausencia de actividad NACK.

4. Desactivación deliberada. Esta opción desactiva deliberadamente los mecanismos de control de flujo y permite que la aplicación procese la transmisión de los datos recién encolados de la mejor manera posible.

Fiabilidad

NORM garantiza un transporte fiable mediante el uso de dos esquemas de codificación de corrección de errores hacia adelante : códigos sistemáticos y códigos no sistemáticos. Estos se analizan en la RFC 5740, Sección 2, Definición de arquitectura: [ 21 ]

Mediante códigos sistemáticos, el remitente transmite bloques de contenido seguidos de bloques de FEC (Corrección de Errores Finales).

Con los códigos no sistemáticos, el remitente codifica el contenido con FEC antes de la transmisión.

Ambos esquemas de codificación FEC pueden utilizarse de forma reactiva o proactiva. En ambos casos, se puede aplicar la reparación basada en FEC, lo que permite a los receptores reparar los paquetes y, por lo tanto, reduce el número de solicitudes y transmisiones de reparación.

Escalabilidad y gestión de NACK

Las comunicaciones multicast orientadas a NACK son susceptibles a implosiones de NACK. Si un gran número de receptores envían NACK simultáneamente, esto podría saturar tanto al emisor como a toda la red. NORM utiliza un mecanismo de supresión de NACK, descrito en la RFC 5740, Sección 5.3, Procedimiento de NACK del receptor, para evitar implosiones de NACK. [ 22 ]

Cuando un receptor detecta que le faltan datos en las transmisiones NORM de un emisor, inicia su procedimiento NACK:

  • Se parte de la base de que uno o más receptores no han recibido esos mismos datos y que es posible que ya se haya enviado un NACK al remitente.
  • El receptor entra en un período de espera basado en un algoritmo de retroceso aleatorio. La duración de este tiempo de espera está determinada por el algoritmo "RandomBackoff" descrito en el Bloque de Construcción Multicast NACK [RFC5401], y se basa en la información que el remitente ha estado transmitiendo en los campos "grtt", "backoff" y "gsize" de sus mensajes transmitidos.
  • Durante el período de espera, el receptor continúa recibiendo y evaluando los mensajes de reparación del remitente, y suprime su propio NACK.
  • Si, al final del período de espera, el receptor no ha recibido suficiente información sobre la reparación, inicia su NACK.
  • Si la sesión NORM se desarrolla en un entorno de enrutamiento multicast, el NACK se transmite tanto al remitente como a todos los demás nodos de la red.
  • Si la sesión NORM no se está llevando a cabo en un entorno de enrutamiento multicast, el NACK se transmite al remitente, y este lo reenvía inmediatamente a todos los demás nodos de la red.

El mecanismo de supresión de NACK de NORM, combinado con su mecanismo FEC, permite que los grupos de multidifusión de NORM escalen a tamaños de grupo muy grandes manteniendo la fiabilidad.

Implementación de referencia

El Laboratorio de Investigación Naval de los Estados Unidos mantiene una implementación de referencia del protocolo NORM , disponible gratuitamente en GitHub . Esta incluye el código fuente, una guía para desarrolladores y una guía para el usuario.

Documentos RFC normativos

  • RFC 1112 - Extensiones de host para multidifusión IP, agosto de 1989 
  • RFC 2357 - Criterios del IETF para la evaluación de protocolos de transporte y aplicación de multidifusión fiables, junio de 1998 
  • RFC 2974 - Protocolo de anuncio de sesión, octubre de 2000 
  • RFC 3048 - Componentes básicos de transporte multicast confiable para la transferencia masiva de datos de uno a muchos, enero de 2001 
  • RFC 3269 - Directrices para autores sobre los bloques de construcción y la instanciación de protocolos de transporte multicast fiable (RMT), abril de 2002 
  • RFC 3453 - Uso de la corrección de errores hacia adelante (FEC) en la multidifusión confiable, diciembre de 2002 
  • RFC 3547 - El dominio de interpretación del grupo, julio de 2003 
  • RFC 3550 - RTP: Un protocolo de transporte para aplicaciones en tiempo real, julio de 2003 
  • RFC 3830 - MIKEY: Claves de Internet multimedia, agosto de 2004 
  • RFC 3940 – Protocolo de multidifusión confiable orientado al acuse de recibo negativo (NORM), noviembre de 2004 
  • RFC 4301 - Arquitectura de seguridad para el protocolo de Internet, diciembre de 2005 
  • RFC 4303 - Carga útil de seguridad encapsulada IP (ESP), diciembre de 2005 
  • RFC 4535 - GSAKMP: Protocolo de gestión de claves de asociación segura de grupo, junio de 2006 
  • RFC 4566 - SDP: Protocolo de descripción de sesión, julio de 2006 
  • RFC 4607 - Multidifusión específica de origen para IP, agosto de 2006 
  • RFC 4654 - Control de congestión de multidifusión compatible con TCP (TFMCC): Especificación del protocolo, agosto de 2006 
  • RFC 5052 - Bloque de construcción de corrección de errores hacia adelante (FEC), agosto de 2007 
  • RFC 5401 - Componentes básicos de la confirmación negativa de multidifusión (NACK), noviembre de 2008 
  • RFC 5445 - Esquemas básicos de corrección de errores hacia adelante (FEC), marzo de 2009 
  • RFC 5740 - Protocolo de transporte de multidifusión confiable orientado a NACK (NORM), noviembre de 2009 

Véase también

Referencias

  1. ↑ PB Danzig (enero de 1994). "Control de flujo para multidifusión con búfer limitado". IEEE Transactions on Software Engineering . 20 (1): 1– 12. Bibcode : 1994ITSEn..2063751D . doi : 10.1109/32.263751 .
  2. ^ JP Macker; PB Adamson (1999). "El conjunto de herramientas del protocolo de difusión de multidifusión (MDP)". MILCOM 1999. Comunicaciones militares IEEE. Actas de la conferencia (Nº de catálogo 99CH36341) . vol. 1. págs. 626–630 . doi : 10.1109/MILCOM.1999.822759 . ISBN   0-7803-5538-5. S2CID 1742198 . 
  3. ↑ J. Macker; W. Dang (noviembre de 1996). El marco del protocolo de difusión multicast (MDP) (Informe técnico). IETF.
  4. ↑ J. Rash; E. Criscuolo; K. Hogie; R. Parise; J. Hennessy (enero de 2002). MDP: Transferencia confiable de archivos para misiones espaciales (Informe técnico). NASA.
  5. ^ JP Macker ;​ PB Adamson (diciembre de 2010). "Mensajería confiable para la comunicación táctica en grupo". 2010 - Conferencia de Comunicaciones Militares Milcom 2010 . págs. 1899-1904 . doi : 10.1109/MILCOM.2010.5680397 . ISBN  978-1-4244-8178-1.
  6. ↑ Diot, C.; Dabbous, W.; Crowcroft, J. (abril de 1997). "Comunicación multipunto: una revisión de protocolos, funciones y mecanismos" (PDF) . IEEE Journal on Selected Areas in Communications . 15 (3): 277– 290. Bibcode : 1997IJSAC..15..277D . doi : 10.1109/49.564128 .
  7. 1 2 3 "Estatuto del Grupo de Trabajo de Multidifusión Confiable del IETF" . Consultado el 22 de febrero de 2021 .
  8. ↑ "Documentos del Grupo de Trabajo de Multidifusión Confiable de la IETF" .
  9. ↑ "Historial del Grupo de Trabajo de Multidifusión Confiable de la IETF" . Consultado el 22 de febrero de 2021 .
  10. ↑ RFC 5740, Sección 2, Definición de arquitectura
  11. ↑ RFC 5740, Sección 4, Formatos de mensajes
  12. ↑ RFC 5740, Sección 4.1, Encabezado de mensaje común y extensiones de NORM
  13. ↑ RFC 5740, Sección 4.2.1, Mensaje NORM_DATA
  14. ↑ RFC 5740, Sección 4.2.2, Mensaje NORM_INFO
  15. ↑ RFC 5740, Sección 4.2.3, Mensaje NORM_CMD
  16. ↑ RFC 5740, Sección 4.3.1, Mensaje NORM_NACK
  17. ↑ RFC 5740, Sección 4.3.2, Mensaje NORM_ACK
  18. ↑ RFC 5740, Sección 4.4.1, Mensaje NORM_REPORT
  19. ↑ RFC 5740, Sección 4.1, Definición de arquitectura
  20. ↑ RFC 5740, Sección 5, Funcionamiento detallado del protocolo
  21. ↑ RFC 5740, Sección 2, Definición de arquitectura
  22. ↑ RFC 5740, Sección 5.3, Procedimiento NACK del receptor

Lecturas adicionales

  • D. Clark, D. Tennenhouse, “Consideraciones arquitectónicas para una nueva generación de protocolos”. Actas de ACM SIGCOMM, septiembre de 1990.
  • S. Floyd y V. Jacobson, "Pasarelas de detección temprana aleatoria para evitar la congestión", IEEE/ACM Transactions on Networking, vol. 1, n.º 4, agosto de 1993.
  • S. Pingali, D. Towsley, J. Kurose. “Una comparación de protocolos de multidifusión confiables iniciados por el remitente y por el receptor”. Actas de INFOCOM, San Francisco, California, octubre de 1993.
  • S. Floyd, V. Jacobson, S. McCanne, C. Liu y L. Zhang. “Un marco de multidifusión fiable para sesiones ligeras y enmarcado a nivel de aplicación”, Actas de ACMSIGCOMM, agosto de 1995.
  • J. Macker, "Transporte de multidifusión fiable y corrección de errores hacia adelante basada en borrado integrado", Actas de IEEE MILCOM 97, octubre de 1997.
  • A. Mankin, A. Romanow, S. Bradner, V. Paxson, “Criterios del IETF para la evaluación de protocolos de transporte y aplicación de multidifusión fiables”, RFC 2357, junio de 1998.
  • D. DeLucia, K. Obraczka , "Rendimiento del control de congestión de un protocolo de multidifusión fiable", Actas de la IEEE ICNP 98, agosto de 1998.
  • D. Gossink, J. Macker, "Retransmisión multicast fiable e integrada con paridad y estimación de canal", IEEE GLOBECOM 98, octubre de 1998.
  • B. Whetton y J. Conlan, "Un esquema de control de congestión basado en tasas para multidifusión confiable", Informe técnico, GlobalCast Communication, octubre de 1998.
  • Notas de transporte NORM
  • Uso del protocolo NORM (Nack Oriented Reliable Multicast) para el transporte de telemetría de naves espaciales en redes terrestres en nasa.gov